How to Tune Azure Application Gateway WAF

2026-07-29T09:30:00+10:00

An Azure WAF false positive usually arrives as a 403 and a complaint.

Treat the 403 as the start of the investigation. The firewall log identifies the rule, the relevant part of the request and the policy that applied.

Put new policies into Detection mode

Use Detection mode while introducing a WAF policy, upgrading its managed ruleset or placing an existing application behind Application Gateway. The WAF records rule matches while every request continues to the application.

Microsoft suggests reviewing one to two weeks of traffic before returning the policy to Prevention mode. Plan and supervise that period because attacks also continue to the application. Microsoft documents this rollout in its Application Gateway WAF troubleshooting guide.

Before changing the mode, save the complete policySettings block:

az network application-gateway waf-policy show \
    --name "$WAF_POLICY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --query policySettings \
    --output json

The Azure CLI command az network application-gateway waf-policy policy-setting update rewrites the policy settings. Microsoft warns that omitting --request-body-check silently resets the setting to false. Supply the current value when switching modes, then read the policy back and verify it. The warning and corrected commands appear in Microsoft’s current troubleshooting procedure.

For a policy that already inspects request bodies:

az network application-gateway waf-policy policy-setting update \
    --policy-name "$WAF_POLICY_NAME" \
    --resource-group "$RESOURCE_GROUP" \
    --state Enabled \
    --mode Detection \
    --request-body-check true

Use the value returned by the first command.

Send the firewall log to Log Analytics

Application Gateway produces access and firewall logs through Azure Monitor. Microsoft recommends the resource-specific Log Analytics tables for new diagnostic settings. WAF events then appear in AGWFirewallLogs; the older Azure Diagnostics mode writes them to AzureDiagnostics. Microsoft explains both collection modes and recommends the resource-specific tables.

Check which table receives your data before borrowing a query from another subscription.

For a resource-specific table, start here:

AGWFirewallLogs
| where TimeGenerated > ago(7d)
| where Action in ("Detected", "Matched")
| summarize
    Events = count(),
    Requests = dcount(TransactionId),
    Paths = make_set(RequestUri, 20)
  by RuleId, Message, PolicyScope, PolicyScopeName
| order by Events desc

For a workspace using the older shared table:

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where action_s in ("Detected", "Matched")
| summarize
    Events = count(),
    Requests = dcount(transactionId_s),
    Paths = make_set(requestUri_s, 20)
  by ruleId_s, ruleGroup_s
| order by Events desc

The current AGWFirewallLogs schema records the policy ID, policy scope and transaction ID. The transaction ID joins several rule events produced by one request.

Open the highest-volume group first. Inspect several transactions and compare each rule message with the input the application expects.

Find the field that caused the match

Suppose rule 942100 appears on POST /api/messages. The endpoint accepts customer support text, and messages containing database errors trigger the SQL injection rule.

The general WAF tuning guide explains how to classify the match. The Azure log supplies the rule, field and policy.

Confirm four things before adding an exception:

the same field causes the repeated matches;
the application expects free text in that field;
the requests complete normally in Detection mode;
other fields on the endpoint still need SQL injection inspection.

The development team supplies the application context behind the WAF event. Ask how the field is parsed, validated, stored and rendered. Keep the request examples needed for the investigation, then remove any customer content from the exception record.

Exclude one field from one rule

Azure exclusion lists remove selected request attributes from managed-rule inspection while the WAF evaluates the rest of the request. Application Gateway v2 can exclude request headers, cookies, form fields, JSON entities and query-string arguments. Exclusions can apply globally or to selected managed rules. Microsoft’s exclusion-list guide describes the supported fields and per-rule configuration.

For the message example, select RequestArgValues with the selector message, then limit the exclusion to rule 942100 in the deployed CRS or DRS version. Replay the original request and a second request that places SQL injection text in another field. The support message should pass. The second field should still trigger the rule.

Azure now skips message for rule 942100 and inspects the other request fields.

Per-rule exclusions require the next-generation WAF engine with CRS 3.2, DRS 2.1 or a later ruleset. Microsoft currently recommends DRS 2.2. A global exclusion applies across the web application covered by the policy, so reserve it for a field that has the same meaning everywhere. Microsoft lists these version requirements and exclusion behaviour in the Application Gateway WAF documentation.

Give one site or path its own policy

A policy-level exclusion may cover more applications than the exception requires.

Application Gateway can associate WAF policies globally, with a listener, or with a path-based rule. The most specific policy takes precedence. A listener policy can therefore tune one hostname, while a path policy can tune one URL area. Microsoft documents global, per-site and per-URI policy associations.

Use that layout when message is free text on /api/messages and a structured identifier elsewhere. Put the exclusion in the policy attached to the relevant path. Other listeners and paths keep their existing policy.

Record the association alongside the exception. A future routing change can move traffic under a different policy without changing the exception itself.

Use request exceptions to skip a rule

Azure Application Gateway WAF also has request exceptions. They match a request attribute such as a URI, header or client address, then bypass a selected rule, rule group or ruleset for the matching request.

Use a request exception when one rule cannot inspect any part of a known request safely. The selected rule stops evaluating the matching request, so describe the inspection removed and limit the exception to that rule where possible.

As of July 2026, Application Gateway WAF request exceptions are in preview. They require Application Gateway v2 and the next-generation engine with CRS 3.2, DRS 2.1 or later. Each WAF policy supports up to 60 exceptions, subject to gateway and per-exception limits. Confirm availability, deployment tooling and support expectations before using them in production. Microsoft publishes the current status, supported scopes and limits on the request-exceptions page.

An Allow rule bypasses the managed WAF

When that rule matches, Azure skips the managed DRS, CRS and Bot Protection rulesets for the request. HTTP DDoS rules still run. Microsoft documents the exact consequence of a custom Allow action.

Reserve an Allow rule for a tightly defined, trusted integration. Every matching request bypasses DRS, CRS and Bot Protection, including requests sent after an allowed client is compromised.

Write the trust assumption into the rule description and the exception register. Include the owner, source, listener or path, expiry or review date, and the protections that remain.

Return to Prevention mode

Run the Detection policy until ordinary traffic and important manual flows produce no unexplained matches. Include login, password reset, checkout, file upload, API writes, administration and scheduled integrations.

Then:

save the current policy settings;
change the mode to Prevention while preserving requestBodyCheck;
read the policy back;
replay the requests used during tuning;
monitor Blocked events and 403 responses;
keep a quick rollback procedure ready.

Enable Prevention in stages when separate listeners or applications have different risk. The first application may be clean while a monthly import on the second has never appeared in the logs.

Recheck the same Log Analytics groups after application releases and managed-ruleset upgrades. A new field, content type or route changes what the WAF sees. Record the request, excluded field and owning policy for every exception.

Peakhour.IO - Application Gateway