Azure WAF Exceptions for Application Gateway and Front Door Go GA

We have had the same conversation with three different clients this year: a WAF policy in Prevention mode blocks a legitimate partner integration, someone panics, and the fastest fix on hand is a broad custom Allow rule on the partner's IP range. It works. It also quietly turns off the Default Rule Set, the Core Rule Set, and Bot Protection for every request from that source. Nobody remembers to narrow it six months later.

Microsoft shipped a better tool for this exact situation. On October 8, 2026, Azure announced general availability of Exceptions in WAF for Azure Application Gateway and Azure Front Door. If you have been waiting for a way to carve out a false positive without turning off inspection for an entire source, this is it.

What actually shipped

The GA announcement covers exceptions for WAF policies on both Azure Application Gateway and Azure Front Door. Exceptions let you bypass WAF evaluation for specific, narrowly defined traffic, scoped to a rule, a rule group, or an entire managed ruleset, rather than disabling protection for a whole request or a whole source.

Microsoft's own description of the feature: "In some cases, WAF might block requests that are safe and expected for your application. Exception lists allow you to bypass WAF inspection for specific requests."

The Front Door-specific mechanics are documented in Azure Front Door WAF exceptions list. Two prerequisites matter before you touch this feature: exceptions only work on the next-generation WAF engine, and your managed ruleset has to be running DRS 2.1 or later. If you are still on an older DRS version, upgrade first.

Exceptions, exclusions, and Allow rules are not the same tool

This is where most teams get it wrong, so it is worth being precise.

Exclusions skip inspection of one element inside a request, like a cookie or a header value, while the rest of the request is still fully inspected. The documented example: a session cookie with random characters that keeps tripping SQL injection detection. You exclude the cookie value; everything else in the request still gets checked.

Custom rules with an Allow action bypass DRS, CRS, and Bot Protection entirely for anything matching the rule. Microsoft is blunt about this: "This bypass is absolute for these rulesets and can't be changed or selectively applied. Once the Allow action is triggered, none of these rulesets evaluate the request." The HTTP DDoS protection ruleset keeps running regardless, but that is the only thing still watching. Use this only when you fully trust the source.

Exceptions sit in between. They bypass inspection only for the specific rules, rule groups, or ruleset you name, not everything. And unlike the Allow rule, exceptions can be applied to DRS, CRS, Bot Protection, and even the HTTP DDoS ruleset. That last part surprised me the first time I read it: you can carve an exception out of DDoS protection logic too, which is not something the blunt Allow rule lets you do selectively.

Our read, as a matter of judgement: if you are reaching for a custom Allow rule to fix a false positive on one or two rules, you are almost always better served by an exception. Save the Allow rule for traffic you trust completely, like an internal health check source or a fully vetted partner.

Scoping an exception correctly

An exception needs three things: the ruleset or rule group it applies to, the scope within that (entire ruleset, a rule group, or specific rule IDs), and the request attribute that identifies the traffic to skip.

Supported match attributes, per the Learn documentation:

• Request URI
• Remote IP address
• Request header name and value

Match operators: Equals, Starts with, Ends with, Contains, and IP Match (for the remote address case).

Microsoft's own guidance on how narrow to go: "Always make exceptions as narrow as possible. Broad exceptions might unintentionally expose your application to attacks. Whenever possible, use per-rule exceptions."

That advice lines up with what we have seen in the field. The most common mistake is scoping an exception to an entire managed ruleset when the actual false positive only touches one SQL injection rule. Narrow it to the rule group, or better, the specific rule ID, and you keep inspection running on everything else in that category.

There are hard limits to design around, documented for Front Door WAF policies:

• Up to 60 exceptions per WAF policy.
• Up to 60 exceptions total across all WAF policies associated with a single Front Door, calculated as a sum.
• Within a single exception: up to 600 IP addresses, or 10 URIs, or 10 request headers.

Those limits push you toward consolidation. Don't write ten separate exceptions for ten partner IPs when one exception with up to 600 addresses covers the same ground.

A worked example

The documentation walks through a concrete case: you don't want WAF to inspect requests to /login.php and /logout.php when it evaluates SQL injection rules. Here is roughly how that exception is structured, following the portal flow (Managed rules → Exceptions tab → Add exceptions, selecting the DRS version, then the scope):

// Exception on Microsoft_DefaultRuleSet_2.1
// Scope: rule group (SQL injection protection)
// Narrow further with rules: [<specific rule IDs>] if you only need
// to exempt one or two signatures, not the whole SQLI group

appliesTo: "Microsoft_DefaultRuleSet_2.1"
ruleGroupName: "SQLI"
matchVariable: "RequestUri"
operator: "StartsWith"
values: ["/login.php", "/logout.php"]

Walk through the portal steps as documented: open the WAF policy, go to Managed rules, open the Exceptions tab, select Add exceptions, pick the DRS ruleset and scope, configure the match variable and operator, then save. The Exceptions tab shows you the new entry once it is applied.

Reading the anomaly score before you write the exception

Before you reach for an exception, check whether you actually understand why the request is getting blocked. DRS 2.0 and later use anomaly scoring, not a single-rule block. Each matched rule contributes to a numeric score based on severity: Critical adds 5, Error adds 4, Warning adds 3, Notice adds 2. Once a request's accumulated score hits 5 or more, the WAF acts on it, and the action (Block, Log, or Redirect) is whatever you configured for the anomaly score threshold.

That matters for scoping. A single Critical match is enough to trigger the full anomaly score action by itself. A Warning match alone is not. If your "false positive" is actually three Warning-level matches stacking up to a Block, a narrow exception on one rule might not fix the behavior, because the other two rules will still push the score over threshold. Pull the WAF logs first, see which rule IDs are actually firing and at what severity, then scope the exception to match. Guessing wastes a change cycle.

This is the same discipline we bring to broader detection engineering work: don't suppress a signal until you know exactly what it is telling you and what else depends on it firing.

Next steps

If you are running Azure Application Gateway or Front Door WAF policies and want help auditing existing Allow rules and exclusions against this GA exceptions model, get in touch.