Resolve Front Door WAF association scope before testing a rate-limit rule

Source facts

Microsoft’s rate-limit configuration guidance distinguishes profile, domain and route associations. When multiple scopes apply, route-level policy takes precedence over domain-level policy, which takes precedence over profile-level policy.

A Front Door security policy associates the WAF policy with the chosen scope. Existing associations do not need to be recreated for WAF policy edits: updates apply automatically, subject to the effective policy precedence for each request. Microsoft Learn.

Applicability

Identify the actual Front Door tier, domain, route and applicable security-policy associations. Keep policy selection separate from the rate threshold and request-match conditions inside that policy.

DSE recommendation

DSE recommends recording the effective policy beside each rate-limit test case. If a profile-level change appears ineffective, inspect more specific associations before raising the threshold or recreating security policies. Have the application owner approve any change in scope so a route-specific exception does not silently redefine protection for neighboring traffic.

Verification

Use a controlled low-impact test path and verify which policy is associated at each relevant scope. Compare expected and observed handling for the selected route and a neighboring route with a different association. Inspect effective scope behavior before moving a policy into prevention mode. Retain the association map with results instead of treating one successful request sequence as proof of profile-wide enforcement.

Official references

Microsoft Learn: Configure a WAF Rate-Limit Rule for Azure Front Door. Source retrieved September 9, 2026.