What is Azure WAF? Azure's web application firewall, explained

Everyone reaches for "Azure WAF" like it's a box you deploy. It isn't. It's a feature you switch on in front of something else — and the interesting questions are which something else, which mode, and what it costs.

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

Azure WAF is a managed web application firewall policy you attach to a fronting service — Azure Application Gateway (regional), Azure Front Door (global edge), or Azure CDN — that inspects HTTP and HTTPS requests for OWASP-style attacks like SQL injection and cross-site scripting using Microsoft-managed rule sets, in detection or prevention mode. It is not a network firewall. Azure Firewall, the layer 3–4 network firewall, is a different product entirely.

I have watched more than one team open a ticket that just says "turn on Azure WAF", go looking for the WAF resource in the portal, and come back confused because there isn't one. There is no single thing called Azure WAF that you create and point at your app. What exists is a firewall engine baked into three fronting services, plus a policy resource that tells it how to behave. Once that clicks, the whole feature stops being mysterious and becomes a set of small, concrete choices.

Does Azure have a WAF? Yes, but it lives inside other services

Azure absolutely has a web application firewall. The reason it feels slippery is that Microsoft ships it as an add-on to services whose main job is to sit in front of your app and route traffic. A WAF only makes sense at a chokepoint where every request passes through, so Azure bolted it onto the services that already are that chokepoint. You don't buy the firewall; you enable it on the doorway your traffic already uses.

The pattern to hold onto: Application Gateway is regional and lives in your virtual network; Front Door is global and lives at the edge. If your app is internal or region-bound, or you need layer 7 routing to backends you control, Application Gateway is usually the answer. If your app faces the public internet and serves users around the world, Front Door's edge WAF inspects requests before they ever cross into your region.

Two practical footnotes. The attachments are not interchangeable: each host has its own WAF engine and its own policy resource type, so a policy built for Application Gateway cannot be attached to Front Door. Even the managed rule sets differ by name — Application Gateway runs the OWASP Core Rule Set lineage, while Front Door runs Microsoft's Default Rule Set. Same idea, separate implementations and version numbers. And on the CDN specifically: Microsoft has been consolidating its edge products onto Front Door, and the classic CDN offerings have been on a retirement path. If you are starting fresh and want a firewall at the content edge, Front Door is the door Microsoft points you to.

What Azure WAF does

A web application firewall inspects HTTP and HTTPS traffic — layer 7, the application layer — and blocks requests that look like attacks against a web app. That is a different job from a network firewall, which filters on IP addresses and ports without ever reading the request body. The WAF reads the request: the URL, the headers, the query string, the form fields, the JSON payload. It is looking for the shapes of known web attacks.

In practice it catches SQL injection, cross-site scripting, command injection, path traversal, and the broad catalogue the OWASP community has documented over the years. Microsoft ships the detection logic as a managed rule set, so you do not write the injection signatures yourself; you subscribe to Microsoft's and they update them as new attack patterns emerge. That "managed" part is the whole value: a small team gets a rule set maintained by people who watch these attacks full time.

What is an Azure WAF policy?

The policy is the piece that trips people up second, right after they get past "there's no WAF resource." The policy is the resource: a standalone Azure object holding every setting the firewall uses, which you attach to a fronting service to make it take effect. Think of it as the firewall's brain, kept separate from the body so you can reuse and version it. A single policy carries managed rules (the Microsoft-maintained core set, with a version you pick and individual rules you can disable or scope), custom rules evaluated before the managed set, the mode, and exclusions and overrides for the inevitable false positives.

You create the policy once and associate it with an Application Gateway listener or a Front Door endpoint. One policy can front several listeners, which is how you keep a consistent posture across apps without redefining rules each time.

Managed rules vs custom rules

The two rule types answer different questions. Managed rules answer "is this request a known web attack?" — you inherit Microsoft's judgment and their maintenance. Custom rules answer "do I want to allow, block, or rate-limit this specific traffic?" — your judgment, your business logic. Most real policies use both: the managed set does the heavy lifting on attack signatures, and a handful of custom rules handle IP allow-lists, geo-blocking and rate limits specific to your app. Keep custom rules few and well-commented, because they run first and a sloppy one can quietly undo the managed protection behind it.

There is a third set worth knowing: bot protection. Both WAF engines offer a managed bot rule set that sorts traffic into known good bots (search crawlers you want), known bad ones (scrapers and scanners you don't), and the unverified middle. It is a separate toggle, and for a public site it is usually worth switching on, since a lot of the junk in your logs is bots rather than attacks.

Prevention mode vs detection mode

Every WAF policy runs in one of two modes, and it is a single dropdown, which makes it look like a trivial toggle. It is not. It is the difference between a WAF that observes and one that enforces.

Both modes run the exact same machinery. A request comes in, the WAF evaluates it against the managed rule set and any custom rules, and works out whether it looks malicious. Up to that point the modes are identical — same rules, same scoring, same verdict written to the log. The split is only in the final act. In detection mode the WAF records its verdict and forwards the request to your backend anyway. In prevention mode it acts: a request that crosses the line is blocked, typically with a 403, and never touches your backend.

So detection is a security camera that only films. Prevention is the camera wired to a lock on the door. You want the lock. The reason you do not fit the lock on day one is that you have not yet learned which of your own customers it will accidentally shut out.

How the WAF decides: the anomaly score

Here is the part most people miss, and it changes how you read the logs. On the OWASP Core Rule Set, a single rule matching does not automatically block the request. The rule set uses anomaly scoring, which works like a demerit system: each rule that matches adds points to a running score for that request, weighted by the rule's severity. The common weights are critical 5, error 4, warning 3, notice 2, and the WAF compares the total against a threshold, 5 by default. Because one critical match is worth 5 and the threshold is 5, a single strong signal is enough to trip it, while a scatter of low-severity notices has to accumulate before the WAF cares.

Treat those exact numbers with suspicion and the model as settled. The point values, the threshold, and even whether your policy runs in this anomaly-scoring style are all rule-set-version dependent, and Microsoft has shipped several versions. The idea — matches add up, the request is actioned when the sum crosses a line — holds across versions. Confirm the specific weights against whatever version your policy has deployed before you quote them to an auditor.

One rule matching is a data point, not a verdict. The WAF blocks on the sum, not the single hit.

This matters practically: when you read detection-mode logs you are not looking for one damning rule. You are looking at which requests crossed the threshold and which rules stacked up to push them there. A legitimate request that trips three separate low-severity pattern rules can cross the line just as surely as a real attack that trips one critical rule, and telling those two apart is the entire job of the tuning phase.

The migration path: detection first, then prevention

1. Deploy in detection mode. WAF in front of the app, rule set enabled, mode set to detection. Nothing is blocked yet — you are only turning on the camera.
2. Read the logs against real traffic. Let it observe a representative stretch of genuine usage, a full business cycle rather than ten minutes. Find every request that hit the threshold. Some will be real attacks, which is good, leave them. Some will be your own customers doing normal things.
3. Add exclusions for the false positives. For each legitimate request the WAF flagged, find the rule ID and the field that tripped it, and write a scoped exclusion — that specific field from that specific rule, never the whole rule set. Precision here is the whole game. Re-test after each change.
4. Switch to prevention. Only once the logs are clean of false positives. Now the requests you have confirmed are hostile get blocked, and the ones you have confirmed are legitimate sail through.

If that shape rings a bell, it should. It is the same move as audit-then-deny in Azure Policy: run in audit to see what it would flag, fix what was legitimately non-compliant, then promote to deny. Detection is audit. Prevention is deny. Watch before you enforce, so that when you enforce you already know exactly what you are enforcing on.

Why a WAF blocks legitimate traffic

When prevention mode starts throwing 403s at real users, the cause is almost always a false positive from the managed rules rather than a real threat. The rules are pattern-matchers, and modern apps send a lot of traffic that looks, to a pattern-matcher, exactly like an attack. A JSON request body with nested quotes. A base64 blob in a header. HTML pasted into a comment field. A product search for O'Brien that reads like the start of an injection. Each can trip a rule, add anomaly points, and if enough stack, cross the threshold.

The wrong response is the off switch. The right response is the tuning loop: open the logs, find the specific rule IDs that fired on the legitimate request, and add a narrow exclusion for that field or rule. Every other rule keeps enforcing at full strength and you carve out only the pattern that was hurting you.

Azure WAF vs Azure Firewall — not the same thing

This is the confusion that causes actual security gaps. Azure Firewall is a network firewall filtering at layers 3 and 4 — IP addresses, ports, protocols — across a virtual network. It decides which machines can talk to which, and never reads the contents of a web request. Azure WAF works at layer 7, reading the actual HTTP request to catch web attacks. One guards the network perimeter and internal segmentation; the other guards the application's front door. Picking one because you think it covers the other is how a workload ends up with a locked network and a wide-open app, or the reverse. Most secure designs run both. The full breakdown is in Azure Firewall vs WAF.

What Azure WAF costs

You never pay for "Azure WAF" as its own line item. The cost arrives through whichever service the policy is attached to, and the billing shape differs between them. That structure is the durable part; the rates move, so price your own case in the Azure Pricing Calculator rather than trusting any blog's snapshot, this one included.

• On Application Gateway, using the WAF means running the WAF v2 SKU, which bills a fixed hourly gateway charge plus capacity units that scale with connections, throughput and rule processing. The firewall is folded into that SKU rather than metered separately — you pay for a bigger gateway, not a WAF add-on, and there is no per-request line. Microsoft renders these two rates dynamically on the pricing page, so the calculator is the only honest source for your region.
• On Front Door, the tier decides the shape. Premium bundles the managed rule sets and bot protection into its base price; Standard supports custom rules but not the managed sets. Classic Front Door and classic CDN metered the WAF explicitly, and those published rates give a useful sense of the meter names: about $5 per policy per month, $1 per custom rule per month, $20 per month for the default managed rule set, and per-request charges of roughly $0.60 per million requests against custom rules or $1 per million against the managed rule set.

The practical consequence: on Application Gateway the WAF cost is mostly a step up in gateway size, and the fixed hourly charge dominates for a small app whether anyone visits or not. On Front Door it is mostly a tier decision, and at high volume the per-request line takes over. Either way, price the fronting service and the WAF together, because that is how the bill will read. A single-region app with steady traffic usually lands cheaper behind an Application Gateway; a global or spiky low-volume site usually lands cheaper behind Front Door, especially if you wanted the edge routing anyway.

So which one do you enable?

Start from where your app lives. If it is internet-facing and global, Front Door WAF puts inspection at the edge, close to your users, before traffic reaches your region. If your app is regional, internal, or needs layer 7 routing to backends inside your virtual network, Application Gateway WAF is the fit. Whichever you choose, the mechanics are the same: create a policy, choose the managed rule set, add the few custom rules your app needs, launch in detection, tune, then move to prevention. The service you attach it to changes the scope; the policy stays the shape you already understand.

Common questions

What is Azure WAF?

Azure WAF is Microsoft's managed web application firewall. It is delivered as a WAF policy you attach to a fronting service — Application Gateway, Front Door, or Azure CDN — and it inspects HTTP and HTTPS requests for web attacks like SQL injection and cross-site scripting, using Microsoft-managed rule sets, in either detection or prevention mode.

Is Azure WAF a separate product?

No. There is no line item called "Azure WAF" that you deploy on its own. It is a feature you turn on for a fronting service and configure through a WAF policy. You always run it in front of a specific service; it never sits alone.

What is the difference between detection and prevention mode in Azure WAF?

Detection mode evaluates every request against the rules and logs what it would have done, but lets the request through either way. Prevention mode does the same evaluation and then acts, blocking requests that breach the rules. Same rules, same scoring; the only difference is whether the WAF enforces or merely watches. Run detection first to see what enforcement would catch, then switch to prevention once the logs are clean of false positives.

What is the anomaly score in Azure WAF?

On the OWASP Core Rule Set the WAF does not block on a single rule match. Each matched rule adds points to a per-request anomaly score based on severity — commonly critical 5, error 4, warning 3, notice 2 — and when the total crosses the threshold, 5 by default, the request is actioned in prevention mode or logged in detection mode. Exact weights and threshold are rule-set-version dependent, so confirm against the version you have deployed.

Should I run Azure WAF in prevention mode?

Yes, that is the goal, because detection mode blocks nothing. But do not start there. Deploy in detection first, read the logs for a representative period of real traffic, add exclusions for the false positives, and only then switch. Going straight to prevention on untuned managed rules is the reliable way to break legitimate traffic and get the whole WAF disabled in a panic, which leaves you worse off than a tuned WAF in detection.

Why is Azure WAF blocking legitimate requests?

Almost always a false positive from the managed pattern rules. Modern apps send traffic that looks like an attack to a pattern-matcher: JSON bodies with nested quotes, base64 in headers, HTML pasted into a comment field, a search for a name with an apostrophe. Each can add anomaly points until the request crosses the threshold. The fix is a narrow exclusion for the specific rule and field, found in the WAF logs, not disabling the rule set.

Where can you attach an Azure WAF policy?

Three places: an Application Gateway v2 (regional, inside your virtual network), an Azure Front Door profile (global, at Microsoft's edge), or Azure CDN. Each host has its own WAF engine and policy resource type, so a policy built for one cannot be attached to another.

Is Azure WAF the same as Azure Firewall?

No. Azure Firewall is a network firewall filtering at layers 3 and 4 — IP addresses, ports, protocols — across a virtual network. Azure WAF inspects HTTP and HTTPS traffic at layer 7 to block web attacks. They protect different layers and most secure designs run both.

How much does Azure WAF cost?

There is no single price; you pay through the service you attach the policy to. On Application Gateway the WAF is part of the WAF v2 SKU, billed as gateway hours plus capacity units with no per-request line, and the fixed hourly charge dominates for small apps. On Front Door it is a tier decision, with Premium bundling the managed rule sets, while classic profiles metered per policy, per rule, and per million requests inspected. Price the fronting service and the WAF together in the Azure Pricing Calculator.