Azure Web Application Firewall Not Working, Connectivity, Rules, and Routing Fixes
Why Your Azure Web Application Firewall Is Blocking Legitimate Traffic
Here's a scenario I've seen play out dozens of times: you spend weeks getting your Azure Web Application Firewall configured, attach it to your Application Gateway, push to production, and immediately your support inbox fills up with users complaining they can't submit a form, upload a file, or log in. You check the backend. Everything's running fine. The app itself is healthy. But your Azure WAF is quietly dropping real user requests like they're attacks.
This is the single most common complaint with Azure Web Application Firewall, and it almost always comes down to one thing: the OWASP Core Rule Set is intentionally aggressive out of the box. That's not a bug. Microsoft designed it that way on purpose. The CRS rules are built to cast a wide net, and it's expected, genuinely expected, that you'll need to tune them for your specific application after initial deployment.
The problem is that Azure WAF's error messages don't tell you much from the user's perspective. A legitimate user just sees a generic 403 Forbidden page. They don't know which rule fired. They don't know why. Neither do you, unless you know exactly where to look in the logs.
What makes Azure Web Application Firewall troubleshooting harder than it should be is the anomaly scoring system. Unlike older firewall models where one rule triggers one block, Azure WAF running OWASP CRS 3.x uses cumulative scoring. Each matched rule adds points to a transaction's anomaly score. Once that score hits a threshold (typically 5 for OWASP 3.x), the entire request gets blocked, even if no single rule would have blocked it alone. So you might have three "warning" rules each contributing 3 points, and suddenly a user submitting a totally normal contact form gets a 403.
The other common culprit is WAF policy scope. Teams often configure WAF rules globally when the problem only exists at a specific URI or hostname. Then they disable rules globally to fix one false positive and accidentally weaken protection everywhere. Per-site and per-URI policies exist specifically to prevent this kind of collateral damage.
I've also seen Azure WAF connectivity issues that have nothing to do with rules at all, things like Application Gateway health probe misconfiguration, backend pool routing errors, or WAF running in Detection mode when someone expected Prevention mode behavior (or vice versa). We'll cover all of it.
The good news: once you know how to read WAF logs and understand the anomaly model, you can pinpoint and fix false positive WAF blocks in Azure in under 30 minutes. Let's get into it. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your Azure Web Application Firewall is blocking traffic right now and you need to diagnose fast, the first thing to do is switch WAF to Detection mode temporarily. This stops active blocking while keeping full logging enabled, so you can identify which rules are firing without impacting users further.
Here's how to do it from the Azure Portal:
- Go to the Azure Portal and navigate to Application Gateways.
- Select your gateway, then click Web application firewall in the left pane.
- Under Firewall mode, switch from Prevention to Detection.
- Click Save.
Now reproduce the failing request. Head to Azure Monitor > Logs, select your Application Gateway resource, and run this query against the AzureDiagnostics table:
AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where Category == "ApplicationGatewayFirewallLog"
| where TimeGenerated > ago(30m)
| project TimeGenerated, clientIp_s, requestUri_s, ruleId_s, Message, action_s, transactionId_s
| order by TimeGenerated descGroup results by transactionId_s. Every row sharing the same transaction ID belongs to the same HTTP request. Look for rows where action_s is "Matched", those are the rules that fired. The rows where action_s is "Blocked" are the mandatory evaluation rules that made the final call. The blocking rules themselves (ruleId 949110 and the correlation rule in RESPONSE-980) can't be disabled, you need to fix the upstream matched rules instead.
Once you identify the offending rule IDs, you have a clear target. Don't disable rules blindly. Instead, assess whether the match is a genuine false positive for your app's traffic patterns before taking action.
| where requestUri_s contains "/your-path" to the query. This cuts the noise dramatically in high-traffic environments where hundreds of requests per minute are flowing through the WAF, and lets you zero in on the exact transaction in seconds rather than scrolling through thousands of log rows.
Before you can fix anything, you need to confirm that Azure WAF diagnostic logs are actually flowing. I've seen teams spend an hour troubleshooting WAF behavior only to discover logging was never turned on, so they were flying completely blind.
Navigate to your Application Gateway resource in the Azure Portal. In the left pane, click Diagnostic settings under the Monitoring section. If you see "No diagnostic settings defined," that's your first problem right there.
Click + Add diagnostic setting. Give it a name. Under Logs, check the box for ApplicationGatewayFirewallLog. This is the specific log category that captures every request the WAF evaluates, matched rules, anomaly scores, blocked requests, all of it. Also check ApplicationGatewayAccessLog if you want to correlate with overall traffic patterns.
For the destination, select Send to Log Analytics workspace. Pick an existing workspace or create one in the same region. Log Analytics is the most useful destination for interactive troubleshooting because you can query the data in real time.
Click Save. There's typically a 5–10 minute delay before new logs start appearing in Log Analytics after you first enable a diagnostic setting. Don't assume it's broken if you don't see data immediately, wait 10 minutes and rerun your query.
Once logs are flowing, you should see entries in AzureDiagnostics with Category == "ApplicationGatewayFirewallLog" within a few minutes of any WAF-evaluated traffic. If you see Access logs but no Firewall logs, double-check that the WAF policy is actually associated with your listener, it's a common misconfiguration where the policy exists but isn't attached.
This step is where most people get tripped up. A single blocked request generates multiple log entries, all sharing the same transactionId, and knowing which ones matter is key.
When you look at a transaction in the WAF logs, you'll typically see entries fall into two categories based on the action_s field: Matched and Blocked.
The "Matched" entries are the rules that fired on the content of the request. Each one contributes to the anomaly score. A rule at severity "Warning" typically adds 3 points. "Critical" severity rules add 5. Once the cumulative total crosses the threshold (5 by default in OWASP 3.x), the request gets blocked.
The "Blocked" entries come from two mandatory rules that you cannot disable: the blocking evaluation rule (REQUEST-949-BLOCKING-EVALUATION.conf) and the correlation rule (RESPONSE-980-CORRELATION.conf). These aren't really rules, they're the WAF's internal scoring engine making its final call. Don't try to disable rule ID 0 or 949110. That path leads nowhere. Focus entirely on the "Matched" rules upstream of these.
In the details_data_s field of a Matched entry, you'll find exactly what triggered the rule. For example, a log entry for rule 942130 might show:
Matched Data: 1=1 found within ARGS:text1: 1=1That tells you precisely: the string 1=1 was found in the query argument text1, and it matched the SQL Tautology Detection rule. Now you know the rule ID (942130), the parameter (text1), and the matched string (1=1). That's everything you need to craft a precise exclusion or make an informed decision about disabling the rule.
Also note the ruleSetType and ruleSetVersion fields. These confirm which rule set version is active on your WAF, which matters when you're looking up rule documentation or planning upgrades from OWASP 3.0 to 3.2.
An exclusion list is almost always the right first tool when you're dealing with an Azure WAF false positive. It's more surgical than disabling a rule entirely, you're telling the WAF to skip inspection for a specific request element while keeping the rule active for everything else.
From the Azure Portal, navigate to your WAF Policy (not the Application Gateway directly, the policy). Click Managed rules in the left pane, then select the Exclusions tab.
Click + Add exclusion. You'll configure three things:
- Match variable, what part of the request to exclude. Options include
RequestArgNames,RequestHeaderNames,RequestCookieNames, and their "values" counterparts. - Operator, how to match the variable name. Use "Equals" for a specific named parameter, "Starts with" for a prefix match, or "Contains" for partial matching.
- Selector, the actual value. For our rule 942130 /
text1example, you'd set match variable toRequestArgNames, operator toEquals, and selector totext1.
You can optionally scope the exclusion to specific rule IDs using the Apply exclusion to rules option. This is important: if you leave it at "All rules," you're excluding that parameter from all WAF inspection globally. Better to scope it to just rule 942130 if that's the only one firing on it.
After saving, wait about 2 minutes for the policy to propagate, then retest the failing request. The WAF should now pass it through. You can confirm by checking the logs, you should see no Matched entry for rule 942130 on that parameter in subsequent transactions.
One important thing to understand about exclusions: they apply globally to all traffic passing through your WAF by default, not just the specific endpoint. If you need finer control, say, this exclusion should only apply to /api/search and not to your login form, you need a per-URI WAF policy, which we'll cover in the advanced section.
Sometimes an exclusion list isn't the right fit. If the false positive is widespread, say, rule 942130 is firing on legitimate search inputs across dozens of parameters in your application, crafting individual exclusions becomes impractical. In that case, and only after careful consideration, you may want to disable the rule outright.
Before you do: ask yourself whether the rule covers a real threat vector in your environment. If there's no SQL database anywhere in your stack, disabling SQL injection rules doesn't meaningfully weaken your security posture. That's a reasonable call. But if you're running a database-backed application, think hard before turning off SQLi rules. Consider whether a tighter exclusion, scoped to a specific match variable or request section, can solve it without touching the rule.
To disable a rule in the Azure Portal, navigate to your WAF Policy > Managed rules > Rules tab. Find your rule set (e.g., OWASP 3.2). Expand the rule group, for rule 942130, that's the REQUEST-942-APPLICATION-ATTACK-SQLI group. Find rule 942130 in the list and toggle its status to Disabled. Click Save.
You can also do this via Azure CLI for teams using infrastructure as code:
az network application-gateway waf-policy managed-rule rule-set add \
--policy-name MyWAFPolicy \
--resource-group MyResourceGroup \
--type OWASP \
--version 3.2 \
--rules 942130 \
--rule-group-name REQUEST-942-APPLICATION-ATTACK-SQLIAfter disabling, validate in your WAF logs that the rule no longer appears as "Matched" for the previously affected transactions. Keep a record of every rule you disable, this is important for security audits and helps you review periodically whether you can re-enable them after application changes.
Note: the two mandatory blocking rules (the anomaly score evaluation rules with rule ID 0) cannot be disabled through any mechanism. If you see documentation or community advice suggesting otherwise, it's incorrect. Those rules are core infrastructure, not configurable policy rules.
Custom rules give you precise control that the managed OWASP rule set can't offer. They run before managed rules are evaluated, which means they can short-circuit the whole anomaly scoring process, either allowing trusted traffic through without inspection, or blocking known-bad actors before they even reach the OWASP rules.
A common use case: you have a trusted internal IP range that you know is safe. You can create a custom allow rule so requests from that range bypass WAF inspection entirely, preventing false positives from your own team's testing or admin tools.
In the Azure Portal, go to WAF Policy > Custom rules > + Add custom rule. Key fields:
- Rule name, something descriptive like
AllowInternalAdminIPs - Priority, lower numbers run first. Use 1–10 for your most important allow/block rules.
- Rule type, "Match" for standard condition matching
- Match conditions, set match variable to
RemoteAddress, operator toIPMatch, and enter your IP range in CIDR notation (e.g.,10.0.0.0/8) - Action, set to
Allow
You can also use custom rules in rate limiting mode to throttle abusive clients. Set rule type to "Rate limit," define a threshold (requests per minute), and scope it to a specific URI or header pattern. This is particularly useful for protecting login endpoints from credential stuffing attacks without relying on OWASP rate-limit rules.
# PowerShell: Add a custom allow rule via Az module
$matchCondition = New-AzApplicationGatewayFirewallMatchCondition `
-MatchVariable RemoteAddr `
-Operator IPMatch `
-MatchValue "10.0.0.0/8"
$customRule = New-AzApplicationGatewayFirewallCustomRule `
-Name "AllowInternalIPs" `
-Priority 5 `
-RuleType MatchRule `
-MatchCondition $matchCondition `
-Action AllowOnce the custom rule is in place and the policy is saved, test it by sending a request from an IP in your allowed range. In the WAF logs, you should see the transaction end with an "Allow" action tied to your custom rule name, not proceed through the full managed rule evaluation chain.
Advanced Troubleshooting for Azure Web Application Firewall
Per-URI and Per-Site WAF Policies
One of the most underused features of Azure WAF is per-URI and per-site policy scoping. Most teams configure a single global WAF policy and try to make it work for every endpoint. That leads to a brutal tradeoff: either you tune rules so aggressively that some parts of the app are underprotected, or you leave rules strict and some endpoints break.
Per-site policies let you attach different WAF configurations to different listeners on the same Application Gateway. If your /api endpoints need strict SQLi protection but your /static assets don't need WAF inspection at all, you can configure that exactly. Navigate to your Application Gateway > Listeners, select the listener you want to scope, and assign a specific WAF policy to it.
Per-URI policies (path-based policies) go one level deeper. Under Rules > Path-based routing, you can associate different WAF policies with different URL path patterns. This is the right solution when you need, say, rule 942130 disabled for /search but active for /login.
Anomaly Score Threshold Tuning
If your WAF is too chatty, blocking traffic that barely exceeds the threshold, consider adjusting the anomaly score threshold. In OWASP 3.2, the default blocking threshold is 5. You can raise it (accepting more risk) or, better, identify which combination of lower-severity rules is accumulating to push legitimate traffic over the threshold.
Run this Log Analytics query to see which rule combinations most frequently co-fire on legitimate traffic:
AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Matched"
| summarize RuleCount = count(), Rules = make_set(ruleId_s) by transactionId_s
| where array_length(Rules) > 1
| order by RuleCount descThis groups all matched rules by transaction, showing you which combinations appear together most often. If you see rules 920350 and 942130 always firing together on legitimate traffic, you know exactly what to target with exclusions.
Health Probe Misconfiguration Causing 502 Errors
Sometimes what looks like a WAF problem is actually an Application Gateway health probe issue that was masked by WAF mode. If you're getting 502 Bad Gateway errors rather than 403 Forbidden, the WAF itself may not be the issue. Go to Application Gateway > Backend health and check whether your backend pool members show as "Healthy." If they show "Unknown" or "Unhealthy," the probe is failing before WAF even enters the picture.
Check your health probe configuration under Health probes. Confirm the probe path returns a 200 response from your backend. The WAF does not inspect health probe traffic, so probe failures are a routing/connectivity issue, not a WAF rules issue.
WAF in Detection vs. Prevention Mode
If you see WAF logs full of "Matched" entries but no actual traffic is being blocked, you're in Detection mode. This is intentional for initial deployment and troubleshooting, Detection logs everything but blocks nothing. Switch to Prevention mode when you're ready to enforce blocking. In Prevention mode, the anomaly score threshold applies and matched requests above the threshold are actively dropped with a 403 response.
Prevention & Best Practices for Azure Web Application Firewall
Getting Azure Web Application Firewall to a stable, well-tuned state isn't a one-time task, it's an ongoing practice. These are the habits that separate teams who spend every week firefighting WAF false positives from teams who almost never think about it.
Deploy in Detection mode first, always. When you first attach a WAF policy to a production Application Gateway, run in Detection mode for at least two weeks. Collect real traffic data. Review your WAF logs daily during that window and build your exclusion list before you ever switch to Prevention. Teams that skip this step pay for it, sometimes immediately, sometimes weeks later when a feature is deployed that happens to trigger a rule.
Keep OWASP rule sets current. OWASP CRS 3.2 has significantly fewer false positives than 3.0 for modern web applications, particularly for APIs that pass JSON payloads. If you're still on OWASP 3.0, upgrading to 3.2 may resolve false positives you've been manually working around. You can change the rule set version in WAF Policy > Managed rules > Assignment. Test the upgrade in a staging environment first.
Use Bicep or Terraform to manage WAF policies as code. Manual portal changes to WAF exclusions and custom rules are easy to lose track of. If someone makes a change and doesn't document it, you're debugging a WAF configuration you can't fully explain six months later. Store your WAF policy definitions in source control, apply them through a deployment pipeline, and treat them like application code. This also makes it trivial to roll back a bad exclusion.
Set up Azure Monitor alerts on WAF block rates. Create a metric alert on the BlockedRequests metric in Azure Monitor scoped to your Application Gateway. If blocked request volume spikes suddenly, especially outside your deployment windows, that's either an attack worth knowing about or a deployment that introduced a new WAF false positive pattern. Either way, you want to know within minutes, not after users start complaining.
Review disabled rules quarterly. Every rule you disable is a security tradeoff. Application changes happen. What was a false positive six months ago because your app didn't use SQL might now be worth re-enabling because your stack changed. Keep a living document of every disabled rule, why it was disabled, and the date. Review it quarterly and re-evaluate.
- Always run Detection mode for 2+ weeks before switching to Prevention on any new WAF policy
- Scope exclusions to specific rule IDs and request variables, never apply broad exclusions to all rules
- Use per-URI policies to apply different strictness levels to different parts of your application
- Pin WAF policy configurations in source control and deploy via pipeline, not manual portal edits
Frequently Asked Questions
Why is Azure WAF blocking my legitimate traffic with a 403 error even though my request looks normal?
Azure WAF uses an anomaly scoring model, not a simple one-rule-one-block system. Your request probably triggered multiple rules that each added points to a cumulative score, and once that score exceeded the threshold (typically 5 in OWASP 3.x), the request got blocked even if no single rule would have blocked it alone. Open your WAF logs in Azure Monitor, filter by Category == "ApplicationGatewayFirewallLog", and group results by transactionId_s. Look for all entries with action_s == "Matched", those are the rules contributing to the score. You'll find the exact matched string and parameter in the details_data_s field, which tells you exactly what to target with an exclusion.
What does the WAF log entry "Mandatory rule. Cannot be disabled. Inbound Anomaly Score Exceeded" mean?
That log entry comes from the WAF's internal scoring engine, specifically from REQUEST-949-BLOCKING-EVALUATION.conf and RESPONSE-980-CORRELATION.conf. These aren't configurable rules; they're the mechanism that makes the final block/allow decision based on the accumulated anomaly score. You can't disable them, and trying to do so through any workaround is unsupported. Your actual fix target is the upstream "Matched" rules in the same transaction, those are the ones adding points to the score. Reduce the score below the threshold by creating exclusions or disabling specific matched rules, and the mandatory blocking rules will stop firing on legitimate traffic.
My WAF is triggering rule 942130 SQL Injection on a form field that doesn't interact with a database, do I need to worry?
If there's genuinely no SQL component in your application stack at all, disabling or excluding rule 942130 for that specific field is a reasonable call, it doesn't weaken protection you actually need. The OWASP rule set is designed to be strict by default and tuned for specific environments. That said, be precise: use an exclusion scoped to the specific argument name (e.g., RequestArgNames equals text1) rather than disabling the rule globally. This way the rule still protects other parameters and endpoints. Document why you created the exclusion so future team members understand the rationale.
What's the difference between using an exclusion list vs. disabling a WAF rule entirely?
An exclusion list carves out a specific request element, a particular header name, cookie, or query parameter, from being inspected by a rule (or all rules). The rule itself stays active and continues protecting everything else. Disabling a rule turns it off completely for all traffic passing through that WAF policy. Exclusions are almost always the better choice because they're more surgical and carry less security risk. Use rule disabling only when the false positive is so pervasive, hitting dozens of parameters or endpoints, that maintaining individual exclusions becomes unmanageable. And when you do disable rules, consider whether a per-URI WAF policy can limit the scope.
How do I fix Azure WAF false positives for a specific URL path without affecting other parts of my application?
Use path-based routing with separate WAF policies assigned to different URL path rules. In your Application Gateway, go to Rules > Path-based routing and configure multiple backend path rules. Each path rule can reference a different WAF policy with its own set of exclusions and disabled rules. For example, your /api/search path might have a WAF policy with rule 942130 excluded, while your /admin path has a strict policy with all OWASP rules active. This is the cleanest way to manage different security requirements across different parts of a single application without compromise.
Can I embed or integrate Azure WAF monitoring with a PHP-based web application to get real-time block notifications?
Yes, the standard approach is to pipe Azure WAF logs from Azure Monitor into Event Hub, then consume them from your PHP application (or a middleware service) via the Event Hub SDK. Your PHP backend subscribes to the Event Hub stream and can parse WAF log events in near real time. Alternatively, set up Azure Monitor alerts on the BlockedRequests metric and route alert payloads to a webhook endpoint in your PHP app using Action Groups. This lets your app react to WAF block spikes, for example, flagging user sessions for review or triggering admin notifications, without needing direct WAF API access from the application itself.