Azure WAF: add an OWASP/CRS exclusion without weakening all protection

A WAF exclusion should be a precise correction, not a quick way to make a block disappear. When an OWASP/CRS rule blocks a legitimate flow, the temptation is to disable the whole rule. That is rarely the right first choice. An overly broad exclusion can remove useful protection from the entire application to solve one problematic parameter.

The scenario here starts from an already qualified false positive: a WAF rule blocks a known field on a precise endpoint, the application team confirms the content is expected, and the security team accepts a limited exception. The goal is to translate that decision into Azure WAF configuration without weakening the policy unnecessarily.

Running use case: allow comment without opening the whole form

In the partner portal partner.example.com, KQL analysis isolated rule 942100 on /partner/comment. The comment field is free text, bounded by the application and stored as a string. Other form fields such as partnerId, caseId or priority should not be excluded from WAF inspection.

The change decision is intentionally narrow: do not disable the SQLi rule, do not exclude the whole request body, and do not lower protection for the site. The exception should apply only to the argument name comment, for the affected rule, in the partner portal policy.

Define exactly what must be excluded

Before opening the portal or CLI, write down the target. An exclusion has several dimensions: policy, listener or application, rule, rule group, request variable, match operator and justification.

Exclusion decision
Policy: wafpol-app-prod
Application: partner portal
Rule: 942100
Group: REQUEST-942-APPLICATION-ATTACK-SQLI
Variable: RequestArgNames
Selector: comment
Justification: free-text field can contain legitimate SQL keywords
Duration: review after application fix or quarterly review

If this form cannot be filled in, the exclusion is probably premature. Either the field is not identified, the rule is not understood, or the risk has not been accepted.

Prefer a per-rule exclusion

When the ruleset supports it, a per-rule exclusion is safer than a global exclusion. It says that a field should not be evaluated by one rule or group, instead of removing that field from all WAF inspection. That difference matters.

Global exclusion
The field is ignored by all rules in the global scope
Wider risk

Group-level exclusion
The field is ignored by a group of rules
Intermediate risk

Per-rule exclusion
The field is ignored only for the targeted rule
More limited and easier to justify

The goal is to keep as much protection around the payload as possible. A text field may trigger one SQLi rule without needing to be ignored by XSS, protocol enforcement or other controls.

Example with Azure CLI

Exact syntax depends on ruleset version and policy type, but the intent stays the same: add an exclusion on a request variable and attach it to a ruleset, group and optionally a specific rule.

RG=rg-network-prod
POLICY=wafpol-app-prod

az network application-gateway waf-policy managed-rule exclusion rule-set add --resource-group $RG --policy-name $POLICY --match-variable RequestArgNames --selector-match-operator Equals --selector comment --rule-set-type OWASP --rule-set-version 3.2 --rule-group-name REQUEST-942-APPLICATION-ATTACK-SQLI --rules 942100

This command illustrates the shape. Before applying it, verify the ruleset actually used by the policy and whether per-rule exclusions are available in that context. If infrastructure is managed as code, configuration should follow that standard.

Validate after the change

An exclusion is not validated only by asking the user to retry. Verify that the legitimate journey passes, that the rule no longer blocks this precise case, and that other protections remain active. The test must include a clear time window in Log Analytics.

let startTime = datetime(2026-05-27 15:00:00);
AzureDiagnostics
| where TimeGenerated > startTime
| where Category == "ApplicationGatewayFirewallLog"
| where requestUri_s has "/partner/comment"
| summarize events=count() by action_s, ruleId_s, message_s
| order by events desc

If events disappear completely, that is not automatically good. It may mean the exclusion is too broad. The goal is to stop blocking the false positive, not to make all WAF activity invisible on that route.

For the partner portal, expected validation is more precise: the partner can submit a comment containing a SQL-looking fragment, rule 942100 no longer blocks the comment field, but an obvious injection attempt in partnerId or caseId is still detected. That negative test proves the exclusion did not weaken the whole form.

Functional validation
Submit a legitimate comment containing SELECT or WHERE
Expected result: form accepted

Security validation
Inject a suspicious value in partnerId or caseId in a test environment
Expected result: WAF still detects or blocks according to policy

Log validation
Check /partner/comment after the change
Expected result: no more 942100 block on RequestArgNames=comment, other rules remain visible

Plan rollback

An exclusion must be removable. Document the inverse change or its infrastructure-as-code equivalent. Also state removal conditions: application fix, payload change, ruleset upgrade, new security analysis.

Rollback
Remove the exclusion on RequestArgNames Equals comment for rule 942100
Monitor blocks on /partner/comment for 30 minutes
Notify the application team if the false positive reappears

Review conditions
Form evolution
OWASP/CRS or DRS version change
Security incident on the same endpoint
Periodic WAF exclusion review

Without rollback, the exclusion becomes permanent by default. That is rarely desirable.

Conclusion

Adding an OWASP/CRS exclusion in Azure WAF should be the outcome of an analysis, not the starting point. A good exclusion is specific: one policy, one rule, one group, one variable, one selector and one justification.

The security principle is simple: remove as little as possible, for as short a time as possible, with evidence before and after. That is how a false positive can be fixed without turning the WAF policy into a collection of global exceptions that cannot be defended.