Azure Front Door’s Web Application Firewall has always had a scoping problem. You could associate a WAF policy with a custom domain, and that was mostly it. One policy per domain, which sounds fine until you run a real Front Door profile with a dozen domains behind it and every team wants different rules. The fix arrived this week in public preview: WAF policies can now attach at the profile level and the route level.
What changed
Previously, WAF association on Front Door was domain-centric. If five applications shared one profile, each custom domain needed its own policy or they shared one. Route-level protection for a specific path, like a login endpoint or a payment flow, was not something you could express cleanly.
The preview adds two new association scopes. A profile-level policy acts as the broad baseline across everything in the profile. A route-level policy attaches to individual routes within an endpoint, which is where the interesting use cases live.
When multiple scopes apply to a single request, the most specific one wins. Microsoft’s documentation lays out the precedence: route-level policy, then domain-level, then profile-level. That ordering matters. It means you can put shared controls like a managed rule set and rate limiting at the profile scope, then override with stricter rules only where they’re needed.
Why this is useful in practice
The obvious pattern: baseline protection everywhere, strict rules on sensitive paths. A profile-level policy with the default managed rule set covers all routes. Then a route-level policy on the login route with stricter bot protection, or tighter rate limits on the payment route. Before this preview you’d be duplicating policies per domain or bending your architecture to fit the WAF model.
It also cleans up policy sprawl. One profile-level policy replaces the copy-pasted per-domain policies that drift apart over time. Anyone who has audited a Front Door deployment and found three slightly different versions of the same baseline rules knows the pain.
The IaC angle
For anyone managing Front Door with Bicep or Terraform, this lands through the Microsoft.Cdn API. The 2026-04-01-preview API version adds an isProfileLevel boolean on the WAF security policy parameters and a routes array on the policy association, alongside the existing domains and patternsToMatch fields. New examples for SecurityPolicies_Create and SecurityPolicies_Patch show the request shapes.
Two cautions if you’re planning to adopt this early. First, it’s a preview API version, so treat it as such in regulated environments and don’t rush it into production templates. Second, be explicit about intent. If a deployment succeeds but the association shape is ambiguous between profile and route scoping, you can end up with coverage gaps that only show up when a request hits the wrong scope. Read the GET response back after every change and add assertions on route IDs and policy scope to your IaC tests.
How it compares to Application Gateway
Application Gateway has had this kind of granularity for a while. Its WAF policies attach at global, listener, and path-rule scope, and the same most-specific-wins precedence applies. Front Door catching up here removes one of the remaining reasons to prefer Application Gateway scoping for global workloads. The two still serve different layers. Front Door inspects at the edge, before traffic crosses the Azure backbone. Application Gateway sits regionally, inline with Layer 7 load balancing. Teams running the layered pattern, Front Door in front and Application Gateway behind, can now mirror their scoping strategy at both layers instead of using different models.
Getting started
If you only use domain and path-based WAF associations today, nothing breaks. Your current API version keeps working. The interesting migration path is for profiles with mixed sensitivity: keep the shared baseline at profile scope, add route-level policies for the paths that need different treatment, and test in a non-production profile first. Validate actual traffic behavior, not just the JSON payload, since the whole point is what the WAF does to real requests.
For Azure Front Door Premium this is the strongest version of the feature, since managed rule sets and bot protection are Premium-only. Standard tier gets custom rules, which still benefits from the scoping flexibility but without the managed rule sets.
Public preview means the usual caveats: no SLA backing, and the API contract can shift before general availability. If your WAF setup is simple and stable, there’s no urgency. If you’ve been fighting the one-policy-per-domain model with workarounds, this preview is worth testing this week. The update landed on the Azure Updates feed on September 2.
The feature announcement is on the Azure Updates page for Front Door WAF profile and route level policies, and Microsoft Learn’s Front Door WAF documentation now describes the three-scope model with precedence rules.
What to watch
The main open question is whether Terraform’s azurerm provider picks up the new association model quickly or whether teams will need the azapi resource to use route references. If you’re on Bicep with the standard resource types, the preview API version is selectable directly. Either way, the model change is small, but it touches the security path for everything behind Front Door, so test deliberately.