One Azure Front Door profile can now run a different WAF policy on every route

The old rule was simple and stupid: one WAF policy per Front Door endpoint. If your marketing site wanted lenient rules and your payments API wanted OWASP plus bot protection with aggressive rate limits, you either crammed both behind one compromise policy or you stood up a second Front Door profile. Most teams picked the second option, which is how you end up with four Front Door profiles, four sets of custom domains, and a WAF ruleset nobody remembers editing.

As of today’s public preview, that’s over. Azure Front Door now lets you associate a WAF policy at the profile level — a baseline that applies to every route — and then override it at the route level for a specific app. One profile, one set of domains, per-route enforcement. This is the config most people thought they already had.

The obvious pattern falls right out of it. Attach a baseline managed OWASP policy to the profile so nothing ships without coverage. Then override the /api/* route with a stricter policy: tighter rate limiting, bot manager set to block instead of log, and whatever custom rules your API actually needs. Leave /marketing/* on the permissive baseline so a marketing team’s campaign query strings don’t trip a SQLi rule at 2am. The most specific association wins for its route; the baseline covers the gaps. Note the word wins — a route override replaces the baseline for that route, it doesn’t stack on top of it. There’s no nesting, no compounding of two rulesets on the same request. Plan for replacement, not inheritance.

On availability: this is a Standard and Premium feature, with the usual caveat that managed rulesets and bot protection are Premium-tier only — a permissive custom-rule baseline works on Standard, but the strict OWASP-plus-bot override you want on /api pulls you into Premium. And “which regions” is a bit of a trick question here: Front Door WAF is a global resource enforced at the edge, not a regional deployment you pick from a dropdown. The preview turns on for the service, not per region. What you should verify against the update note before you architect around it is the boring stuff the announcement is thin on — any cap on associations per profile, and confirmation of the replace-not-nest behavior above. Treat those as unconfirmed until the docs say otherwise.

Where it lives in the portal trips people up because there are two places. You author the WAF policy itself under Web Application Firewall policies (its own resource), and you associate it — to the profile or to specific routes — from the Front Door profile under Settings > Security policies. Same split in IaC: a Microsoft.Network/frontDoorWebApplicationFirewallPolicies resource for the ruleset, a Microsoft.Cdn/profiles/securityPolicies resource for the binding. Here’s both halves of the pattern — baseline first, then the override:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

// Pin the current preview apiVersion before deploying — check:
//   az provider show -n Microsoft.Cdn --query "resourceTypes[?resourceType=='profiles/securityPolicies'].apiVersions"
​
// 1. Baseline: managed OWASP across every route on the profile.
resource baselineWaf 'Microsoft.Cdn/profiles/securityPolicies@2024-02-01' = {
  parent: frontDoorProfile
  name: 'profile-baseline-waf'
  properties: {
    parameters: {
      type: 'WebApplicationFirewall'
      wafPolicy: { id: baselineWafPolicy.id }
      associations: [
        {
          patternsToMatch: [ '/*' ]
          domains: [ { id: endpoint.id } ]
        }
      ]
    }
  }
}
​
// 2. Override: stricter policy scoped to the API route only.
resource apiWaf 'Microsoft.Cdn/profiles/securityPolicies@2024-02-01' = {
  parent: frontDoorProfile
  name: 'api-strict-waf'
  properties: {
    parameters: {
      type: 'WebApplicationFirewall'
      wafPolicy: { id: strictWafPolicy.id } // OWASP + bot + rate limit
      associations: [
        {
          patternsToMatch: [ '/api/*' ]
          domains: [ { id: endpoint.id } ]
        }
      ]
    }
  }
}

Never deploy this blind. Run the plan first:

1
2
3

az deployment group what-if \
  --resource-group rg-frontdoor \
  --template-file frontdoor-waf.bicep

Now the part the announcement won’t dwell on. The blast radius got better and worse at the same time. Better, because a fat-fingered rate limit on the API route no longer takes down the marketing site — the failure is scoped to one route. Worse, because a scoped failure is a quiet failure. Break the whole profile and every alert in the building fires. Break one route and you get a slow trickle of 403s on /api while your uptime dashboard stays a cheerful green, and you find out from a customer three hours later. Test overrides in a staging endpoint or a canary route before they touch production traffic, and watch WAF metrics per route, not per profile.

Two more things before you rearchitect. This is public preview — no production SLA, and the association schema can still change under you, so don’t bet a compliance deadline on it. And granularity isn’t free: managed rulesets and bot protection are Premium-tier features, and it’s worth checking the per-request evaluation and cost implications on the Front Door pricing page before you scatter a dozen policies across one profile to feel tidy.

The consolidation win is real. Fewer profiles, fewer domains, one place to reason about coverage. Just remember that the same change that shrinks your infrastructure also shrinks the size of the thing that can quietly go wrong.