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.

Azure Web Application Firewall (WAF) is a family of service-specific protections for HTTP/S applications. The main options are WAF on Application Gateway for regional ingress and on Azure Front Door for global edge ingress. Microsoft also documents WAF for Application Gateway for Containers, and WAF on Azure CDN is currently a preview path. The products share a purpose, but their policies, rule sets, and feature support differ. WAF inspects web requests for common attack patterns; it is not the same control as Azure Firewall, which protects network traffic.

A request to "turn on Azure WAF" is incomplete until you know which fronting service will inspect the traffic. There is no single WAF engine with one policy that works identically across every Azure host. Choose the service from the workload's ingress and deployment shape, then configure that service's WAF policy and verify the rule-set and mode it actually supports.

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 durable distinction is deployment scope: Application Gateway is regional and lives in your virtual network; Front Door is global and operates at the edge. Pick based on origin reachability, network placement, user geography, required features, and operating cost—not on the word "WAF" alone. A public audience by itself does not require a global edge service.

These products are not interchangeable: each host has service-specific policy resources and capabilities. Application Gateway supports Microsoft-managed rule sets based on OWASP CRS; Front Door has its own rule-set names and tier-dependent feature support. Treat any shared terminology as a starting point, then verify the exact host, tier, and rule-set version in the documentation before configuring it. Azure CDN WAF is documented as preview; do not treat it as a general-purpose replacement for Front Door.

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 happens to a request?

The fronting service receives the connection and applies its TLS and routing configuration. The WAF policy then evaluates the request using the rules enabled for that host. A matching rule can log, allow, or block according to the rule action and the policy mode; in Detection mode, matches are logged without blocking, while Prevention mode enforces configured blocking actions. Requests allowed through continue to the configured origin. The exact order and available actions vary by service and rule set, so don't assume one provider's request flow describes every Azure WAF.

1. Receive: the request reaches the configured edge or regional gateway.
2. Inspect: enabled managed and custom rules evaluate supported parts of the request.
3. Act: the rule action and Detection or Prevention mode determine whether the event is logged, allowed, or blocked.
4. Forward: traffic permitted by the policy proceeds toward the configured origin.

What is an Azure WAF policy?

The policy stores the settings the host's WAF uses: managed rules, custom rules, the mode, and supported exclusions or overrides for false positives. The resource type, attachment scope, available actions, and evaluation order depend on the service. An Application Gateway policy and a Front Door policy are not interchangeable.

Associate the policy using the scopes supported by its host. Application Gateway, Front Door, and Application Gateway for Containers have different deployment models, so check the matching service documentation before reusing a configuration pattern.

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 custom rules add application-specific conditions such as IP allow-lists, geo-blocking, or rate limits. Keep them few and well-commented; processing order and the effect of an allow action depend on the host service.

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

Application Gateway and Front Door policies expose Detection and Prevention modes. The names make the setting look like a trivial toggle; it is the difference between observing matching traffic and enforcing configured blocking actions.

For a given WAF service and policy, Detection and Prevention use the configured rules; the mode determines whether matching activity is observed or enforced. In Detection mode, matching rules are logged without blocking the request. In Prevention mode, configured blocking actions are enforced, typically returning a 403. Rule evaluation, scoring, and actions differ by product and rule set, so consult the matching service documentation rather than assuming all Azure WAF hosts behave identically.

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.

• Application Gateway: WAF capability is associated with the WAF tier/SKU and its gateway capacity charges. Model the gateway and expected capacity together.
• Front Door: managed-rule availability and other WAF features depend on the profile tier; price the profile and traffic using the current calculator.
• Other hosts: Application Gateway for Containers and Azure CDN have their own product and preview terms. Confirm current availability and billing before estimating.

Rates, tiers, and included features change. Compare the complete ingress design—including traffic, origin connectivity, resilience, and rule-set needs—in the Azure Pricing Calculator. This article intentionally avoids fixed dollar examples that could go stale or imply a universal cheapest option.

So which one do you enable?

Choose from the workload outward. Consider Front Door for global edge ingress; consider Application Gateway when regional Layer 7 routing and virtual-network placement fit; consider Application Gateway for Containers for supported Kubernetes Gateway API workloads. Then compare the required rule sets, policy scope, origin path, logging, operating cost, and false-positive risk. Start with Detection where supported, inspect real logs, tune narrowly, and use Prevention when the policy is ready to enforce. See when an Application Gateway WAF fits for the regional decision.

Common questions

What is Azure WAF?

Azure Web Application Firewall is a set of service-specific protections configured with WAF policies. Current Microsoft documentation covers Application Gateway, Application Gateway for Containers, and Azure Front Door; Azure CDN WAF is documented as a preview. Capabilities and rule sets differ by host.

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?

Where these modes are supported, Detection logs matching activity without blocking the request; Prevention enforces configured blocking actions. The available rules and exact evaluation behavior depend on the host service and rule set. Start in Detection, review representative traffic, tune false positives, and move to Prevention when the policy is ready to enforce.

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?

Microsoft documents WAF for Application Gateway, Application Gateway for Containers, and Azure Front Door; WAF for Azure CDN is currently listed as preview. These are service-specific implementations with different policy resources and capabilities. Check the current documentation for availability before selecting a host.

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. Charges and included WAF features depend on the host service, SKU or profile tier, region, and traffic. Price the complete ingress design in the Azure Pricing Calculator; avoid applying historical classic-service rates to a new deployment.

Every class is open to read. A free account saves your progress. Azure resources used for labs may incur charges.