Our organization recently completed a migration of a primary customer-facing web application from an on-premises infrastructure to Microsoft Azure App Service. Since the migration, we are experiencing intermittent 502 (Bad Gateway) errors that correlate directly with WAF rule triggers. The WAF is Azure Front Door's managed rule set (Default Rule Set - DRS 2.1), and the backend is an Azure App Service.
The pattern is not consistent for all users or requests, which points to a potential integration mismatch between the WAF's behavior and the application's expectations or the specific Azure architecture. The errors appear in the Front Door access logs with a `BackendHealthStatus` of `Unhealthy` and a `WAFMatched` flag of `True` for the same request. Our application logs show the request never reaches the App Service when this occurs.
I have analyzed the specific rules causing the blocks (predominantly SQLI and XSS detection in the 94XXX series) and, while some look like false positives, the request patterns should be handled gracefully, not with a 502. This leads me to believe the issue is not merely a false-positive tuning problem but a more fundamental interaction between the WAF, Front Door's health probes, and the backend.
My current hypothesis centers on the following potential integration points:
* **Health Probe Sensitivity:** Azure Front Door uses health probes to determine backend availability. If a WAF block response (typically a 403) is interpreted by the health probe logic as a backend failure, it could mark the backend as unhealthy, causing subsequent legitimate requests to receive a 502.
* **Block Action Configuration:** The difference between using `Block` vs. `Log` actions for managed rules. A `Block` action may terminate the connection in a way that the gateway interprets as a failure.
* **Response Buffer or Timeout:** The WAF inspection process, combined with the App Service's own request gateway, might be exceeding a hidden timeout threshold in the Front Door stack, leading to a 502 instead of the intended 403.
I have already performed baseline configuration checks:
- Backend health probes are configured to the root path (`/`) with a 200 OK expected.
- WAF policy is in `Prevention` mode.
- No custom block response pages have been configured yet.
My specific questions for the community are:
1. Has anyone documented a proven pattern for configuring Azure Front Door WAF (specifically with App Service backends) to ensure blocked requests return a clean 403 without cascading into backend health probe failures and subsequent 502 errors?
2. Are there critical rule exclusions or adjustments to the managed rule set that are considered mandatory for App Service environments to avoid this class of issue?
3. Beyond the standard diagnostics, are there specific Azure Monitor metrics or Kusto queries for Front Door that you have found most effective in isolating WAF-induced 502s from true backend failures?
I will provide relevant anonymized configuration snippets below for reference.
**Current WAF Policy Snippet (Managed Rules):**
```json
{
"managedRules": {
"ruleSets": [
{
"ruleSetType": "Microsoft_DefaultRuleSet",
"ruleSetVersion": "2.1",
"ruleGroupOverrides": []
}
]
},
"policySettings": {
"mode": "Prevention",
"requestBodyCheck": true,
"requestBodyInspectLimitInKB": 128
}
}
```
**Front Door Route Health Probe Configuration:**
```json
{
"healthProbeSettings": {
"path": "/",
"protocol": "Https",
"intervalInSeconds": 30,
"healthProbeMethod": "HEAD"
}
}
```
connected