How does Azure WAF work?

Strip away the marketing and a web application firewall is a bouncer reading every request at the door. Here is exactly what it reads, how it decides, and the part the product page will not tell you — that the rules are the easy 20 percent and tuning them is the job.

New to cloud? CAMPUX is a free, build-first course. Start here →

Azure WAF inspects every inbound HTTP request at the fronting service — Application Gateway or Front Door — before it reaches your app, evaluates it against a Microsoft-managed ruleset (the OWASP Core Rule Set), assigns an anomaly score, and blocks (Prevention mode) or logs (Detection mode) requests that cross the threshold.

That sentence is the whole mechanism in one breath, and most guides stop roughly there. The trouble is that the interesting part — and the part that decides whether your WAF protects the app or just breaks it — lives in the words "evaluates," "anomaly score," and "threshold." I have stood up Azure WAF in front of production apps more than once, and the pattern is always the same: turning it on takes an afternoon, and making it not block your own checkout page takes the following two weeks. Let me walk the request through the machine, then be honest about where the machine falls short.

Where the WAF sits

The first thing to get straight is that Azure WAF is not a standalone box you deploy. It is a policy you attach to a fronting service that already terminates your traffic. There are two of them, and which one you use changes almost nothing about how the rules behave but a lot about the blast radius:

• Application Gateway WAF is regional. It lives inside your virtual network and fronts a single region's backend — the classic pattern for an internal or single-region app.
• Front Door WAF is global, running at Microsoft's edge points of presence, so requests are filtered close to the user before they ever travel to your region. This is the one you want for a public, multi-region site.

Both terminate TLS, which is the non-negotiable prerequisite: a firewall cannot inspect what it cannot read, and an HTTPS request is opaque until it is decrypted. Because the fronting service holds the certificate and terminates the connection, the WAF gets to read the request in cleartext — method, path, headers, query string, cookies, and body — before it re-encrypts (or forwards) to your backend. If you have not yet met the two services this rides on, Front Door vs Application Gateway is the map. Everything below applies to both.

The request lifecycle, step by step

Follow a single POST to /login from the public internet through to your app. Every request takes this same path:

1. Request arrives at the edge. The client opens a connection to the Front Door or Application Gateway public endpoint, not to your app directly. Your backend's real address is never exposed.
2. TLS is terminated. The fronting service decrypts the request using the certificate it holds. Now the WAF can read the full request in plaintext.
3. Custom rules run first. Before the managed set, your own rules get a look — an IP allow/deny list, a geo-match block, a rate limit. A custom rule can short-circuit the whole thing: an explicit Allow lets a trusted IP skip the managed rules, and an explicit Block stops the request cold.
4. Managed rules evaluate. The request is run against every rule in the OWASP Core Rule Set — the SQLi patterns, the XSS patterns, the protocol checks. This is where the anomaly score gets built.
5. The anomaly score accumulates. Each managed rule that matches adds a weighted number to a running total for this request. Nothing is decided per-rule; the WAF waits until all rules have run.
6. An action is taken. If the total score meets or passes the threshold, the request is judged malicious. In Prevention mode it is blocked with a 403; in Detection mode it is waved through but written to the log.
7. The request reaches the backend. Only requests that survive all of the above are forwarded to your app. Everything the WAF did is recorded in the firewall log either way.

The WAF does not judge rule by rule. It reads the whole request, tallies the damage, and decides once at the end.

Managed rules vs custom rules

Two kinds of rules run in that pipeline, and keeping them straight is most of understanding Azure WAF.

Managed rules — the OWASP Core Rule Set

The managed set is Microsoft's Default Rule Set, built on the open-source OWASP Core Rule Set (CRS) — the same engine that sits behind ModSecurity across much of the industry. On Application Gateway you choose a CRS version (3.2 is current, with 3.1 and 3.0 still selectable); on Front Door the equivalent is the Microsoft Default Rule Set, versioned separately. These are hundreds of hand-written signatures grouped by attack class: SQL injection, cross-site scripting, remote code execution, local and remote file inclusion, PHP and Java injections, protocol violations, and scanner/bot fingerprints. You do not write or maintain any of them — Microsoft ships updates as new CRS versions, and moving to a newer version is a deliberate choice you make and test, not an automatic push. Alongside the core set, Azure offers a separate Bot Manager ruleset for known good, bad, and unknown bots.

Custom rules — the ones you own

Custom rules are yours to write, they run before the managed set, and they are match-condition-plus-action. The common shapes:

• Rate limiting. A threshold over a time window, grouped by a key — usually client IP. "More than 100 requests a minute from one IP, block it." Scope it to /login and it becomes brute-force protection without touching the rest of the site.
• Geo-match. Allow or block by the country the request resolves to. Useful when your app has no legitimate audience outside a region.
• IP allow/deny. Explicit lists — allow a partner's known egress range past the managed rules, or deny a range you have seen abuse from.
• Header, path, and method matches. Arbitrary conditions on any part of the request, combined with AND/OR, so you can encode app-specific rules the generic set never would.

How anomaly scoring actually decides

Older WAF logic blocked the instant any single rule matched. That is loud and it false-positives constantly, because plenty of harmless requests trip one pattern by accident. CRS 3.x replaced it with anomaly scoring, which is the model Azure WAF uses by default, and it is worth understanding because it explains the behaviour you will see in the logs.

Instead of deciding per rule, the WAF gives every matched rule a severity weight and adds it to a per-request total:

• Critical match → adds 5
• Error match → adds 4
• Warning match → adds 3
• Notice match → adds 2

The threshold is 5. So one Critical rule alone is enough to cross it, but it also takes only a couple of lower-severity matches stacking up to get there. When the inbound total reaches 5, the request is deemed malicious and the mode decides its fate — blocked in Prevention, logged in Detection. This is why you sometimes see a request blocked by an anomaly-score rule rather than by a named attack rule: no single signature condemned it, but the weights added up past the line. It is a more forgiving model than match-and-block, and it is still the thing most likely to catch your legitimate traffic in the crossfire, which brings us to the part the docs skip.

Why the real work is tuning, not turning it on

Here is the honest arc of every WAF deployment I have run. You attach the policy, flip on the managed rules, feel protected — and then legitimate traffic starts getting 403s. The rich-text field in your CMS contains angle brackets and trips an XSS rule. A JSON body with a SQL-ish string in a free-text comment trips an SQLi rule. A base64 blob in a cookie looks like an injection. None of it is an attack; all of it crosses the threshold.

The fix is not to weaken the ruleset wholesale — it is exclusions: telling the WAF to skip a specific rule for a specific request attribute (this header, that query-string parameter, this cookie) while leaving the rule active everywhere else. Getting exclusions right is the job. And the only way to do it safely is the discipline the product makes easy to skip:

1. Deploy in Detection mode. Never start in Prevention on a live app. Let it watch and log for a week or two without blocking anything.
2. Read the logs. Every match lands in the firewall log with the rule ID, the matched value, and the request that tripped it. This is where you separate real attacks from your own false positives.
3. Write exclusions for the false positives. Scope each one as narrowly as you can — a single rule ID against a single parameter, not "disable SQLi checks."
4. Then switch to Prevention. Now blocking is safe, because you have already found the legitimate traffic that would have been caught.

You will spend most of your WAF life in step 2, reading logs. Both Application Gateway and Front Door WAF stream their logs to a Log Analytics workspace, where you query them with KQL. A first look at what your WAF has been doing usually starts with something like:

AzureDiagnostics
| where Category == "ApplicationGatewayFirewallLog"
| where action_s == "Blocked"
| summarize hits = count() by ruleId_s, requestUri_s
| sort by hits desc

Run that after a week in Detection and the ruleId at the top of the list, firing against one of your own endpoints, is nearly always the first exclusion you need to write. That query — not the on/off switch — is the actual craft of running a WAF.

Where this sits in the bigger picture

A WAF is Layer 7 — it reads HTTP. That makes it a different tool from Azure Firewall, which filters at the network and transport layers on IPs, ports, and protocols, and the two are complements, not substitutes: Firewall decides who may reach the front door at all, the WAF reads what the ones who arrive are asking for. If you want the deeper, gateway-specific view of the same machine, Application Gateway WAF goes further into the regional setup. And once you understand that the WAF rides on a load-balancing service, the class on load balancing and traffic distribution ties the fronting service into the rest of the architecture. All of it is one exhibit in the enterprise web platform capstone, where the WAF stops being a diagram and becomes something you configure, break, and tune yourself.

Common questions