Module 02 — Introduction to Azure WAF¶

What Is Azure Web Application Firewall?¶

Azure Web Application Firewall (WAF) is a cloud-native, fully managed Layer 7 security service that provides centralized protection for web applications against common exploits and vulnerabilities. It inspects every inbound HTTP and HTTPS request in real time, evaluates it against a set of managed and custom rules, and either allows, blocks, logs, or redirects the traffic based on the policy you define.

How It Works¶

Azure WAF operates as a reverse proxy — it sits inline between the client and your backend application. Every request must pass through the WAF before it reaches your application code. This architecture means:

1. All traffic is inspected. There is no way for a client to bypass the WAF and reach the backend directly (assuming proper network configuration with Private Link or NSG restrictions).
2. Responses can also be inspected. While the primary focus is on inbound requests, WAF logs capture response codes and latency, which are critical for detecting successful attacks.
3. TLS termination is handled upstream. Application Gateway or Front Door terminates the TLS connection, and the WAF inspects the decrypted HTTP content. The connection to the backend can be re-encrypted.

What Gets Inspected¶

Azure WAF evaluates multiple parts of every HTTP request:

Inline vs. Out-of-Band¶

Azure WAF is an inline (synchronous) security control. Every request is inspected before it is forwarded. This differs from out-of-band solutions that analyze copies of traffic asynchronously. Inline inspection introduces a small amount of latency (typically 1–3 ms) but guarantees that malicious requests are blocked in real time, before they reach the application.

Where Can You Deploy Azure WAF?¶

Azure WAF is not a standalone service — it is a capability attached to one of several Azure application delivery platforms. Each platform serves a different architectural pattern, and the WAF feature set varies slightly across them.

Platform Comparison¶

Capability	Application Gateway v2	Front Door Premium	App GW for Containers	CDN (Preview)
Scope	Regional	Global	Regional (K8s)	Global
DRS 2.1 managed rules				CRS 3.x only
Custom rules				Limited
Bot protection
JavaScript Challenge
Rate limiting
Geo-filtering
Per-site policies		(per-endpoint)
Next-Gen Engine
WAF Insights
Private Link origins
Copilot for Security
Max request body	2 MB (Next-Gen)	2 MB (Next-Gen)	2 MB (Next-Gen)	128 KB

Choosing the Right Platform¶

Architecture Diagram¶

The following diagram shows the three primary deployment options and how traffic flows from clients to backends:

flowchart TB
    Internet((Internet))

    subgraph "Global — Azure Front Door Premium"
        FD[Front Door + WAF Policy]
    end

    subgraph "Regional — Application Gateway v2"
        AGW[App Gateway + WAF Policy]
    end

    subgraph "Kubernetes — App GW for Containers"
        AGC[AGC + WAF Policy]
        AKS[AKS Cluster]
    end

    Internet --> FD
    Internet --> AGW
    Internet --> AGC

    FD --> AppService[App Service / VM / AKS]
    AGW --> VM[VM Scale Set / App Service]
    AGC --> AKS

    style FD fill:#0078d4,color:#fff
    style AGW fill:#0078d4,color:#fff
    style AGC fill:#0078d4,color:#fff

Key Features (2026)¶

Azure WAF has evolved significantly. The 2026 feature set includes both mature capabilities and recent innovations. This section explains each feature in detail.

DRS 2.1+ Managed Rules¶

The Default Rule Set (DRS) is Microsoft's curated collection of WAF rules, evolved from the OWASP Core Rule Set (CRS). DRS 2.1 includes over 300 rules organized into rule groups that cover SQL injection, cross-site scripting, local file inclusion, remote code execution, protocol violations, and more.

DRS goes beyond the open-source CRS by adding Microsoft Threat Intelligence (MSTIC) rules — signatures derived from Microsoft's global threat intelligence network that protect against actively exploited zero-day vulnerabilities (for example, Log4Shell, Spring4Shell, and MOVEit). These rules are updated automatically by Microsoft without any customer action.

Bot Protection¶

Azure WAF integrates with the Microsoft Threat Intelligence bot feed to classify traffic as good bots (search engines, monitoring services), bad bots (scrapers, credential stuffers), and unknown bots. You can configure per-category actions: allow, block, log, or redirect.

Bot protection is especially effective against:

• Credential stuffing — Automated login attempts using stolen password databases.
• Content scraping — Bots that harvest pricing, inventory, or proprietary content.
• Inventory hoarding — Bots that add items to shopping carts to deplete stock.

See Module 07 for configuration details.

JavaScript Challenge¶

The JavaScript Challenge is a client-side verification mechanism that distinguishes real browsers from headless automation tools. When enabled, Azure WAF serves a small JavaScript snippet that the client must execute. Legitimate browsers execute it transparently; simple bots that do not run JavaScript are blocked.

JavaScript Challenge is particularly useful for protecting:

• Login and registration pages.
• API endpoints that should only be accessed from browser-based SPAs.
• High-value transaction pages (checkout, payment).

Rate Limiting¶

Azure WAF supports conditional rate limiting that restricts the number of requests a client can send within a configurable time window. Rate-limit rules can group traffic by:

• Client IP address (including X-Forwarded-For header for clients behind proxies).
• Socket address (the direct connection IP).
• Geo-location of the client.
• Custom match conditions (URI path, header value, etc.).

When the threshold is exceeded, requests are blocked or logged for the remainder of the window. Rate limiting is essential for mitigating brute-force attacks, API abuse, and application-layer DDoS.

Geo-Filtering¶

Geo-filtering rules allow you to restrict or allow traffic based on the country/region of the client's IP address. This is useful for regulatory compliance (restricting access to specific jurisdictions) and for reducing the attack surface by blocking traffic from regions where you have no legitimate users.

# Azure CLI — Create a custom rule that blocks traffic from two countries
az network front-door waf-policy custom-rule create \
  --policy-name myWafPolicy \
  --resource-group myRG \
  --name BlockCountries \
  --priority 100 \
  --rule-type MatchRule \
  --action Block \
  --match-condition "RemoteAddr GeoMatch CN RU"

Custom Rules Engine¶

Beyond managed rules, Azure WAF provides a powerful custom rules engine that lets you define your own match conditions and actions. Custom rules are evaluated before managed rules, giving you fine-grained control over traffic that the managed rules might not cover.

Custom rules support:

• Match variables: IP address, URI, query string, headers, cookies, request body, geo-location.
• Operators: Equals, contains, regex, begins with, ends with, greater than, less than, geo-match, IP match.
• Actions: Allow, block, log, redirect, JavaScript Challenge.
• Grouping: Up to 10 match conditions per rule, combined with AND logic.

See Module 06 for advanced custom-rule patterns.

Next-Gen WAF Engine¶

The Next-Gen WAF Engine is a ground-up rewrite of the Azure WAF processing engine, delivering up to 8× faster rule evaluation compared to the classic engine. Key improvements include:

Feature	Classic Engine	Next-Gen Engine
Rule evaluation speed	Baseline	Up to 8× faster
Max request body inspection	128 KB	2 MB
Max file upload	100 MB	4 GB
Engine architecture	ModSecurity-based	Azure-native, optimized
DRS 2.1 support

WAF Insights¶

WAF Insights is an interactive dashboard built into the Azure Portal that provides visual analytics for WAF activity: top triggered rules, top blocked requests by URI, geographic distribution of attacks, and trend analysis over time. WAF Insights eliminates the need to write KQL queries for common monitoring scenarios.

Copilot for Security Integration¶

Azure WAF integrates with Microsoft Copilot for Security, allowing SOC analysts to investigate WAF alerts using natural-language prompts. Example prompts:

• "Show me the top SQL injection attempts blocked by my WAF in the last 24 hours."
• "Summarize the WAF activity for the /api/login endpoint this week."
• "Are there any new attack patterns targeting my application?"

See Module 13 for Copilot configuration and prompt engineering.

Azure WAF Benefits¶

Protection Benefits¶

Azure WAF provides layered, always-on protection that adapts to emerging threats:

• Out-of-the-box OWASP Top 10 coverage — DRS 2.1 managed rules protect against the most critical web application risks without any custom configuration.
• Zero-day protection via MSTIC — Microsoft's global threat intelligence network pushes rule updates within hours of a new vulnerability being disclosed. Customers are protected before they even know about the threat.
• Bot management — ML-based classification distinguishes good bots from malicious automation, protecting login pages, APIs, and high-value transaction flows.
• DDoS integration — Azure WAF works alongside Azure DDoS Protection to mitigate both volumetric (Layer 3/4) and application-layer (Layer 7) denial-of-service attacks.

Operational Benefits¶

Beyond security, Azure WAF simplifies operations:

• Centralized management — A single WAF policy can protect multiple backends across Application Gateway listeners or Front Door endpoints.
• Azure Monitor integration — WAF diagnostic logs, metrics, and alerts flow natively into Azure Monitor, Log Analytics, and Event Hubs.
• Sentinel SOAR — WAF alerts can trigger automated playbooks in Microsoft Sentinel, enabling auto-remediation workflows such as IP banning or incident escalation.
• Azure Policy governance — Enforce WAF deployment standards across subscriptions using built-in and custom Azure Policy definitions.
• Infrastructure as Code — WAF policies can be fully defined in Bicep, ARM templates, or Terraform, enabling GitOps workflows and repeatable deployments.

# Create a WAF policy with DRS 2.1
az network application-gateway waf-policy create \
  --name myWafPolicy \
  --resource-group myRG \
  --type OWASP \
  --version 2.1

# Create a WAF policy with DRS 2.1
New-AzApplicationGatewayFirewallPolicy `
  -Name "myWafPolicy" `
  -ResourceGroupName "myRG" `
  -ManagedRule (
    New-AzApplicationGatewayFirewallPolicyManagedRule `
      -RuleSet (
        New-AzApplicationGatewayFirewallPolicyManagedRuleSet `
          -RuleSetType "Microsoft_DefaultRuleSet" `
          -RuleSetVersion "2.1"
      )
  )

Application Delivery Product Suite¶

Azure WAF does not operate in isolation. It is part of a broader application delivery and network security product suite that provides multi-layer protection. Understanding how these services complement each other is essential for designing a secure architecture.

Product Comparison¶

Service	Layer	Primary Function	WAF Capability	When to Use
Azure Front Door Premium	7	Global load balancing, CDN, WAF	Built-in	Public-facing apps with global users
Application Gateway v2	7	Regional load balancing, WAF	Built-in	Regional apps, private endpoints
App GW for Containers	7	Kubernetes-native L7 LB, WAF	Built-in	AKS workloads
Azure Firewall Premium	3/4	Network filtering, IDPS, TLS inspection		East-west traffic, outbound filtering
DDoS Network Protection	3/4	Volumetric DDoS mitigation		All public-facing workloads
DDoS IP Protection	3/4	Per-IP DDoS mitigation		Smaller deployments, per-IP billing
Azure CDN	7	Content delivery, basic WAF	Preview	Static content acceleration

How They Work Together¶

In a well-architected Azure deployment, these services form concentric rings of protection:

flowchart LR
    Client([Client]) --> DDoS["DDoS Protection<br/>(Layer 3/4)"]
    DDoS --> FD["Front Door + WAF<br/>(Layer 7 — Global)"]
    FD --> AFW["Azure Firewall<br/>(Layer 3/4 — VNet)"]
    AFW --> AGW["App Gateway + WAF<br/>(Layer 7 — Regional)"]
    AGW --> App["Web Application"]

    style FD fill:#0078d4,color:#fff
    style AGW fill:#0078d4,color:#fff
    style DDoS fill:#e83e8c,color:#fff
    style AFW fill:#ff8c00,color:#fff

1. DDoS Protection absorbs volumetric attacks at the network edge.
2. Front Door WAF inspects Layer 7 traffic globally and routes it to the nearest healthy region.
3. Azure Firewall filters east-west traffic within the VNet and applies FQDN-based outbound rules.
4. Application Gateway WAF provides a second Layer 7 inspection point at the regional level (defense in depth).

ModSecurity Heritage¶

A Brief History¶

Azure WAF's rule engine traces its lineage back to ModSecurity, the open-source WAF engine originally created for the Apache HTTP Server in 2002. ModSecurity introduced the concept of a programmable rule language for inspecting HTTP traffic, and the OWASP Core Rule Set (CRS) became the de facto standard set of detection rules.

When Microsoft built Azure WAF, it adopted the ModSecurity engine and CRS as the foundation. This gave Azure WAF immediate access to a battle-tested rule set with broad community support.

From CRS to DRS¶

Over time, Microsoft enhanced the rule set with proprietary additions:

DRS 2.1 is the recommended rule set for all new deployments. It retains backward compatibility with CRS rule IDs where applicable, but adds Microsoft-managed rules that are updated automatically based on global threat intelligence.

Next-Gen Engine: Beyond ModSecurity¶

The Next-Gen WAF Engine (announced in 2024 and generally available in 2025) replaces the ModSecurity-based processing pipeline with an Azure-native engine built from the ground up for performance and extensibility. While DRS rules are still defined in a CRS-compatible format, the evaluation engine is completely new — delivering up to 8× faster rule processing and support for larger request bodies.

Azure WAF vs. Azure Firewall¶

One of the most common questions in Azure networking is: "Do I need Azure WAF, Azure Firewall, or both?" The answer depends on the traffic you need to protect and the layer at which you need to inspect it.

Detailed Comparison¶

Aspect	Azure WAF	Azure Firewall Premium
OSI Layer	Layer 7 (HTTP/HTTPS)	Layer 3/4 (Network), with L7 IDPS
Traffic Direction	North-south (inbound web traffic)	North-south & east-west (all network traffic)
Deployment	Attached to App GW, Front Door, or AGC	Standalone in a hub VNet
Inspection Target	HTTP requests: URI, headers, body, cookies	IP packets: source/dest IP, port, protocol
Rule Types	OWASP/DRS managed rules, custom rules, bot rules	Network rules, application rules (FQDN), NAT rules
TLS Inspection	Performed by upstream platform (App GW / FD)	Built-in TLS inspection for outbound traffic
Threat Intelligence	MSTIC rules for web exploits	MSTIC feed for known malicious IPs/domains
IDPS	Not applicable (application-layer focus)	Signature-based IDPS with 67,000+ signatures
Bot Protection	Built-in	Not applicable
Rate Limiting	Per-rule configuration	Not applicable
Geo-Filtering	Country-based rules	Not applicable
Use Case	Protect web apps from OWASP Top 10, bots, DDoS L7	Segment VNets, filter outbound, FQDN control

When to Use Each¶

Related Labs¶

• LAB 01 — Deploy a WAF Policy on Application Gateway

Key Takeaways¶

References¶

• Azure WAF Overview — Microsoft Learn
• Azure WAF on Application Gateway — Microsoft Learn
• Azure WAF on Front Door — Microsoft Learn
• Azure WAF on App GW for Containers — Microsoft Learn
• Azure Firewall Overview — Microsoft Learn
• DDoS Protection Overview — Microsoft Learn
• OWASP ModSecurity Core Rule Set
• What's New in Azure WAF — Microsoft Learn