Skip to main content

Article

Azure Front Door WAF: How to Find Why a Request Was Blocked

09/29/2026

Azure Front Door’s Web Application Firewall can block malicious traffic before it reaches your application. But when legitimate traffic receives a 403 or an integration suddenly stops working, the important question is:

Did the WAF block it, and if so, which rule caused the block?

Azure Log Analytics can usually answer that quickly.

Start With Actual WAF Blocks

If Azure Front Door diagnostic logs are being sent to a Log Analytics workspace using AzureDiagnostics, start with:

AzureDiagnostics
| where Category =~ "FrontDoorWebApplicationFirewallLog"
| where action_s =~ "Block"
| project
    TimeGenerated,
    ClientIP = clientIP_s,
    RequestURL = requestUri_s,
    Rule = ruleName_s,
    Action = action_s,
    TrackingReference = trackingReference_s
| order by TimeGenerated desc

Using =~ makes the comparison case-insensitive. This avoids missing matching records because of capitalization differences.

Run only the code inside each query block. Do not paste article headings or explanatory text into Log Analytics. Set the time range to include when the request occurred. If your workspace contains logs from multiple Front Door profiles, narrow the query to the relevant resource.

The results give you the basic information needed to investigate:

  • When the request occurred
  • Which URL was requested
  • Which WAF rule recorded the block
  • The client IP
  • Azure’s tracking reference

The user agent is available in the Front Door access log for the setup used here. Use the tracking reference to look up the matching access-log entry, as shown below.

Find Blocks for One URL

When troubleshooting a specific API endpoint, feed, form or page, narrow the results:

AzureDiagnostics
| where Category =~ "FrontDoorWebApplicationFirewallLog"
| where action_s =~ "Block"
| where requestUri_s contains "/api/"
| project
    TimeGenerated,
    ClientIP = clientIP_s,
    RequestURL = requestUri_s,
    Rule = ruleName_s,
    Action = action_s,
    TrackingReference = trackingReference_s
| order by TimeGenerated desc

Replace /api/ with the portion of the URL you need to investigate.

This is especially useful when an application uses several APIs and you don’t want unrelated WAF activity obscuring the results.

Count Blocks by Rule

If you want to determine which WAF rules are responsible for most blocking log entries:

AzureDiagnostics
| where Category =~ "FrontDoorWebApplicationFirewallLog"
| where action_s =~ "Block"
| summarize BlockCount = count() by Rule = ruleName_s
| order by BlockCount desc

This query counts WAF log rows with a blocking action, grouped by rule. Treat BlockCount as a count of blocking log entries rather than a guaranteed count of unique requests.

This is useful when tuning a WAF policy because one problematic managed or custom rule can become immediately obvious.

A high number of blocks does not automatically mean the rule should be disabled. First determine what traffic is triggering it.

Correlate the Request With the Access Log

One of the most useful Azure Front Door fields is trackingReference_s.

Azure assigns a tracking reference to a request, allowing activity for that request to be correlated between Front Door logs. The tracking reference is also exposed through the X-Azure-Ref response header.

Copy the TrackingReference value from the WAF query results above. Replace PASTE-TRACKING-REFERENCE-HERE with that exact value, keeping the quotation marks:

let Ref = "PASTE-TRACKING-REFERENCE-HERE";
AzureDiagnostics
| where Category in~ (
    "FrontDoorAccessLog",
    "FrontDoorWebApplicationFirewallLog"
)
| where trackingReference_s == Ref
| order by TimeGenerated asc

The first line stores the value in a variable named Ref. The query then uses trackingReference_s == Ref to find log entries with the same tracking reference.

For example, if the value you copied were example-reference-123, the first line would be:

let Ref = "example-reference-123";

That value is only an illustration. Use the actual tracking reference from your logs.

Run the entire query together, including the let Ref line and its ending semicolon. Set the Log Analytics time range to include when the request occurred.

Both access logs and WAF logs must be enabled and sent to the workspace to retrieve both types of records. If only one type appears, check the diagnostic settings, selected time range and whether the relevant logs have arrived.

This can help establish whether a suspicious HTTP response corresponds to an actual WAF event rather than an application, origin or connectivity problem.

Find the User Agent for the Request

To retrieve the user agent, use the same tracking reference to search the Front Door access log:

let Ref = "PASTE-TRACKING-REFERENCE-HERE";
AzureDiagnostics
| where Category =~ "FrontDoorAccessLog"
| where trackingReference_s == Ref
| project
    TimeGenerated,
    UserAgent = userAgent_s,
    TrackingReference = trackingReference_s
| order by TimeGenerated asc

Replace the placeholder with the same value used in the correlation query. Run this query separately, including its own let Ref line.

This lets you inspect the user agent associated with the access-log entry instead of expecting it to be populated in the WAF log. A user-agent string is supplied by the client and can be spoofed, so use it as supporting information rather than proof of identity.

A 403 Doesn’t Automatically Mean WAF

This distinction matters.

Seeing an HTTP 403 in the Front Door access log does not by itself prove that the WAF generated it. Applications and origins can also return 403 responses.

Check the WAF log for a corresponding blocking event.

That is one reason the tracking reference is so useful: it provides a much stronger connection between the access request and WAF activity than relying on HTTP status alone.

Before Changing the WAF Rule

Once you’ve identified a blocking rule, determine:

  1. What URL triggered it?
  2. What client or application generated the request?
  3. Is the traffic legitimate?
  4. Is the rule managed or custom?
  5. Can the exception be limited to the affected request instead of disabling protection more broadly?

The objective shouldn’t be to eliminate WAF blocks.

The objective is to allow legitimate application traffic while continuing to block unwanted traffic.

Need Help With Azure Front Door?

AZTANDC works with Azure Front Door, WAF configuration, application troubleshooting, security and web infrastructure. When an application problem crosses the boundary between the website, CDN, firewall and origin, we can help isolate where the failure is actually occurring.