Module 09 — Azure WAF on Front Door Premium¶

1 — What Is Azure Front Door?¶

Azure Front Door is a global, Anycast-based application delivery network that combines content caching, dynamic site acceleration, intelligent routing, and built-in security services into a single managed platform.

When a user sends a request, DNS resolution returns the IP address of the nearest Microsoft POP. Because Front Door uses Anycast, every POP advertises the same IP range, and BGP automatically steers the user to the geographically closest location. The POP terminates the TLS connection, evaluates WAF rules, serves cached content if possible, and—only when necessary—forwards the request to the origin over Microsoft's private backbone.

This architecture gives you three immediate benefits:

1. Lower latency — TLS handshake and WAF inspection happen at the edge, not at your data centre.
2. Higher resilience — attacks are absorbed across the global edge network before they can concentrate on a single origin.
3. Simpler operations — one Front Door profile can route to origins in multiple Azure regions, on-premises data centres, or even other cloud providers.

2 — Front Door Tiers: Standard vs Premium¶

Azure Front Door is offered in two tiers. The choice of tier directly determines which WAF capabilities are available.

Capability	Standard	Premium
Global load balancing & failover
SSL offload & custom domains
Static content caching
Dynamic site acceleration
WAF — custom rules
WAF — managed rules (DRS 2.1)
WAF — bot protection managed rule set
WAF — JavaScript Challenge action
Private Link to origins
Enhanced analytics & reports

Upgrading from Standard to Premium is supported as a non-disruptive operation and is now generally available.

3 — How WAF Works at the Edge¶

The single most important concept to understand about Front Door WAF is where inspection happens. Unlike a regional WAF on Application Gateway, Front Door WAF evaluates every request at the POP closest to the client. This means an attacker in São Paulo is blocked in São Paulo, and the malicious traffic never traverses the transatlantic backbone toward your origin in West Europe.

flowchart LR
    Client(["👤 Client"]) -->|"DNS → Anycast IP"| POP["🌐 Nearest POP<br/>(1 of 180+)"]
    POP -->|"① TLS termination<br/>② WAF evaluation"| Decision{Pass?}
    Decision -->|"✅ Allowed"| Backbone["Microsoft<br/>backbone"]
    Decision -->|"❌ Blocked / Redirect"| Client
    Backbone --> Origin["🖥️ Origin<br/>server"]

Evaluation order inside the POP:

1. Custom rules are evaluated first, in priority order (lowest number = highest priority).
2. Rate-limit rules are evaluated next.
3. Bot protection managed rules follow.
4. Managed rules (DRS 2.1) are evaluated last, using anomaly scoring.

If any rule triggers a terminating action (Block, Redirect, JSChallenge), evaluation stops and the configured response is returned to the client immediately.

4 — Creating and Associating a WAF Policy¶

A WAF policy on Front Door is an independent Azure resource of type Microsoft.Network/FrontDoorWebApplicationFirewallPolicies. You create the policy, configure its rules, and then associate it with one or more Front Door endpoints or custom domains through a security policy resource.

Creating a WAF policy¶

# Create a resource group (if not already present)
az group create \
  --name rg-waf-workshop \
  --location eastus2

# Create a WAF policy for Front Door Premium in Detection mode
az network front-door waf-policy create \
  --name wafpolicyFrontDoor \
  --resource-group rg-waf-workshop \
  --sku Premium_AzureFrontDoor \
  --mode Detection \
  --redirect-url "https://www.contoso.com/blocked.html"

# Create WAF policy for Front Door Premium
New-AzFrontDoorWafPolicy `
  -Name "wafpolicyFrontDoor" `
  -ResourceGroupName "rg-waf-workshop" `
  -Sku "Premium_AzureFrontDoor" `
  -Mode "Detection" `
  -RedirectUrl "https://www.contoso.com/blocked.html"

Adding managed rules (DRS 2.1)¶

# Add DRS 2.1 managed rule set
az network front-door waf-policy managed-rules add \
  --policy-name wafpolicyFrontDoor \
  --resource-group rg-waf-workshop \
  --type Microsoft_DefaultRuleSet \
  --version 2.1 \
  --action Block

# Add bot protection managed rule set
az network front-door waf-policy managed-rules add \
  --policy-name wafpolicyFrontDoor \
  --resource-group rg-waf-workshop \
  --type Microsoft_BotManagerRuleSet \
  --version 1.1 \
  --action Block

# Add DRS 2.1 managed rule set
$drs = New-AzFrontDoorWafManagedRuleObject `
  -Type "Microsoft_DefaultRuleSet" `
  -Version "2.1"

# Add bot protection managed rule set
$bot = New-AzFrontDoorWafManagedRuleObject `
  -Type "Microsoft_BotManagerRuleSet" `
  -Version "1.1"

# Update the policy with both rule sets
Update-AzFrontDoorWafPolicy `
  -Name "wafpolicyFrontDoor" `
  -ResourceGroupName "rg-waf-workshop" `
  -ManagedRule $drs, $bot

Associating the WAF policy with a Front Door endpoint¶

After the policy exists, you link it to your Front Door profile through a security policy. A security policy binds a WAF policy to one or more domains (endpoints or custom domains).

# Get the WAF policy resource ID
WAF_ID=$(az network front-door waf-policy show \
  --name wafpolicyFrontDoor \
  --resource-group rg-waf-workshop \
  --query id -o tsv)

# Create a security policy that binds the WAF to an endpoint
az afd security-policy create \
  --profile-name myFrontDoor \
  --resource-group rg-waf-workshop \
  --security-policy-name secpol-waf \
  --domains /subscriptions/<sub>/resourceGroups/rg-waf-workshop/providers/Microsoft.Cdn/profiles/myFrontDoor/afdEndpoints/myEndpoint \
  --waf-policy $WAF_ID

5 — Key WAF Capabilities on Front Door¶

5.1 DRS 2.1 Managed Rules¶

The Default Rule Set 2.1 provides protection against the OWASP Top-10 categories including SQL injection, cross-site scripting, local file inclusion, remote code execution, and protocol violations. It also includes Microsoft Threat Intelligence Collection rules that leverage Microsoft's global threat-intelligence feeds to block known-malicious IP addresses and zero-day attack patterns.

DRS 2.1 uses anomaly scoring. Each rule that matches adds a severity-based score (Critical = 5, Error = 4, Warning = 3, Notice = 2). The request is only blocked when the cumulative score meets or exceeds the anomaly score threshold, which defaults to 5. This dramatically reduces false positives compared with the legacy "block-on-first-match" mode of DRS 1.x.

5.2 Bot Protection¶

The Bot Manager Rule Set classifies bots into three categories: good bots (e.g., Googlebot), bad bots (known scrapers and attack tools), and unknown bots. You can configure different actions for each category—for example, allow good bots, block bad bots, and issue a JavaScript Challenge to unknown bots.

5.3 JavaScript Challenge (JSChallenge)¶

The JavaScript Challenge action is exclusive to Front Door Premium. When triggered, Front Door returns a small JavaScript snippet that a real browser executes automatically and transparently. Automated bots that cannot execute JavaScript are blocked. Unlike a CAPTCHA, the JS Challenge is invisible to the end user and does not degrade the user experience.

5.4 Custom Rules¶

Custom rules let you define match conditions on virtually any part of the HTTP request: IP address, geo-location, URI path, query string, request headers, cookies, HTTP method, and request body. Each custom rule has a priority (0–999) and an action. Conditions can be combined with logical AND/OR operators.

5.5 Rate Limiting¶

Rate-limit rules are a special type of custom rule. You define a match condition, a time window (1 or 5 minutes), and a threshold (the maximum number of requests). When a client exceeds the threshold, the configured action applies for the remainder of the window. Rate limiting on Front Door is applied per POP, which means a globally distributed attacker may exceed the effective limit by the number of POPs involved.

5.6 Geo-Filtering¶

Geo-filtering custom rules let you allow or block traffic based on the originating country/region code. Front Door resolves the client IP to a country using its own GeoIP database. This is useful for compliance scenarios where an application must not be accessible from certain jurisdictions.

5.7 Redirect Action¶

The Redirect action is unique to Front Door WAF—it is not available on Application Gateway. When a rule triggers a redirect, Front Door returns an HTTP 302 response pointing the client to a URL that you specify (the redirectUrl property on the policy). This is ideal for directing blocked users to a custom "access denied" page or a CAPTCHA challenge hosted on a separate domain.

5.8 Anomaly Scoring¶

As described above, DRS 2.1 uses anomaly scoring with a configurable threshold. You can lower the threshold (e.g., to 3) for stricter security or raise it (e.g., to 10) to reduce false positives while you tune exclusions. Microsoft recommends starting at the default of 5.

6 — Origin Lockdown¶

Origin lockdown ensures that your backend accepts traffic only from Azure Front Door. There are three complementary methods, and Microsoft recommends combining at least two.

Method 1 — Front Door Service Tag on App Service Access Restrictions¶

If your origin is an Azure App Service, you can configure access restrictions to allow only the AzureFrontDoor.Backend service tag.

# Add an access restriction rule that allows only Front Door traffic
az webapp config access-restriction add \
  --name myWebApp \
  --resource-group rg-waf-workshop \
  --priority 100 \
  --rule-name "AllowFrontDoor" \
  --service-tag AzureFrontDoor.Backend \
  --action Allow \
  --http-header x-azure-fdid=<your-front-door-id>

The --http-header x-azure-fdid filter is crucial. Without it, any Azure Front Door instance—not just yours—could reach the backend, because all Front Door profiles share the same service tag IP ranges.

Method 2 — NSG Rules with Front Door IP Ranges¶

For VM-based or AKS-based origins behind a load balancer, use a Network Security Group (NSG) rule with the AzureFrontDoor.Backend service tag.

# Create an NSG rule allowing only Front Door backend IPs
az network nsg rule create \
  --nsg-name myOriginNSG \
  --resource-group rg-waf-workshop \
  --name AllowFrontDoor \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --destination-port-ranges 80 443 \
  --source-address-prefixes AzureFrontDoor.Backend

Method 3 — X-Azure-FDID Header Validation¶

Every request that Front Door sends to the origin includes an X-Azure-FDID header containing the unique identifier of the Front Door profile. You can validate this header at your web server, application code, or reverse proxy.

# Retrieve your Front Door profile ID
az afd profile show \
  --profile-name myFrontDoor \
  --resource-group rg-waf-workshop \
  --query frontDoorId -o tsv

An example NGINX validation snippet:

# Block requests that are not from our Front Door instance
if ($http_x_azure_fdid != "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx") {
    return 403;
}

Method 4 — Private Link (Strongest)¶

Front Door Premium supports Private Link connections to App Service, Storage, Azure Functions, and internal load balancers. When Private Link is configured, the origin has no public endpoint at all—traffic flows entirely over the Microsoft backbone. This is the strongest form of origin lockdown because there is no public IP for an attacker to target.

# Enable Private Link origin in Front Door
az afd origin create \
  --profile-name myFrontDoor \
  --resource-group rg-waf-workshop \
  --origin-group-name myOriginGroup \
  --origin-name myPrivateOrigin \
  --host-name mywebapp.azurewebsites.net \
  --enable-private-link true \
  --private-link-location eastus2 \
  --private-link-resource /subscriptions/<sub>/resourceGroups/rg-waf-workshop/providers/Microsoft.Web/sites/myWebApp \
  --private-link-request-message "Front Door Private Link"

7 — WAF Actions on Front Door¶

Front Door WAF supports a richer set of actions than Application Gateway WAF. Understanding each action is key to designing effective policies.

The Redirect action is unique to Front Door and does not exist on Application Gateway. It is especially useful for directing users to a branded "you have been blocked" page hosted on a separate static site, rather than showing a generic 403 page.

The AnomalyScoring action is the default for individual managed rules under DRS 2.1. It does not block or log by itself; instead, it increments the anomaly score. The final block decision is made only when the cumulative score meets the threshold.

8 — Front Door WAF vs Application Gateway WAF¶

The following table provides a detailed comparison to help you choose the right WAF platform for a given workload.

9 — When to Use Front Door WAF¶

Front Door WAF is the right choice when your scenario matches one or more of the following patterns:

• Public-facing web applications — the origin must be accessible from the internet, and you want Layer-7 protection before traffic reaches it.
• Global user base — your audience is geographically distributed, and you need low-latency TLS termination and WAF inspection at the edge.
• CDN + WAF combined — you need content caching and application security in a single service, without managing separate CDN and WAF resources.
• Multi-region backends — you have origins in two or more Azure regions and need global failover with health probing.
• DDoS protection at the edge — Front Door's Anycast architecture and global capacity provide inherent volumetric DDoS mitigation without a separate DDoS Protection plan.
• Bot mitigation with JavaScript Challenge — you need transparent, user-friendly bot detection that does not require CAPTCHAs.
• Compliance-driven geo-filtering — you need to restrict access by country at the network edge, before any traffic reaches your data sovereignty boundary.

Related Labs¶

Key Takeaways¶

1. Azure Front Door is a global, Anycast-based platform that evaluates WAF rules at 180+ edge locations before traffic reaches your origin.
2. The Premium tier is required for managed rules (DRS 2.1), bot protection, and JavaScript Challenge—Standard only supports custom rules.
3. WAF evaluation order is: custom rules → rate-limit rules → bot protection → managed rules (DRS 2.1 with anomaly scoring).
4. Origin lockdown is essential. Use at least two methods: service tag/NSG restrictions plus X-Azure-FDID header validation—or use Private Link for the strongest guarantee.
5. Front Door WAF offers Redirect and JSChallenge actions that are not available on Application Gateway WAF.
6. For high-security global applications, consider a layered architecture with Front Door WAF at the edge and Application Gateway WAF in the region.

References¶

• What is Azure Front Door?
• Azure Web Application Firewall on Azure Front Door
• WAF policy settings for Front Door
• Tutorial: Create a WAF policy on Azure Front Door
• DRS rule sets for Front Door
• Bot protection on Azure Front Door
• Secure your origin with Private Link in Azure Front Door Premium
• Azure Front Door — Standard vs Premium tier comparison