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 question is which something else.

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

Azure WAF is not a standalone product — it is a managed web application firewall you enable on a fronting service (Azure Application Gateway, Azure Front Door, or Azure CDN), configured through a WAF policy and running Microsoft-managed OWASP rulesets that block common web attacks. The honest catch: the real decision isn't whether to use it, but where it runs — regional Application Gateway or global Front Door.

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.

That doorway can be one of three services. Which one you pick changes where the firewall physically runs, how far the inspection sits from your users, and where your TLS gets terminated. This is the choice the question "what is Azure WAF" is really asking about, even when the person asking doesn't know it yet.

The three places Azure WAF runs

Here is the whole map. Every Azure WAF deployment is one of these three, and the difference between them is scope — regional versus global versus content-edge — not the firewall rules themselves, which are broadly the same Microsoft-managed OWASP core.

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. The CDN option is the narrowest — it's the WAF for a content-delivery front end rather than a full application front end.

The rules are nearly the same in all three. What differs is where the firewall stands — inside your region, or out at the edge in front of it.

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 that means it catches things like SQL injection (someone smuggling database commands into a form field), cross-site scripting (injecting a script that runs in another user's browser), command injection, path traversal, and the broad catalogue the OWASP community has catalogued over the years. Microsoft ships the detection logic as a managed rule set — you don't write the SQL-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 WAF policy is the piece that trips people up second, right after they get past "there's no WAF resource." The policy is the resource. It's a standalone Azure object that holds every setting the firewall uses, and you attach it 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 WAF policy carries:

• Managed rules. The Microsoft-maintained OWASP core rule set. You pick a version and, optionally, turn individual rules off or set exclusions where a rule keeps flagging legitimate traffic.
• Custom rules. Your own rules, evaluated before the managed set. These are how you do things the OWASP core doesn't — block or allow specific IP ranges, geo-filter by country, rate-limit a noisy endpoint, or match on a header your app cares about.
• Mode. Prevention or detection — covered next, and it matters more than any single rule.
• Exclusions and overrides. The escape hatches for the inevitable false positives, so a legitimate request that happens to look like an attack still gets through.

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 security posture across apps without redefining rules each time.

Managed rules vs custom rules

The two rule types answer two 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 that are specific to your app. A useful habit is to keep custom rules few and well-commented, because they run first and a sloppy one can quietly undo the managed protection behind it.

Prevention mode vs detection mode

Every WAF policy runs in one of two modes, and the difference is simply whether the firewall acts or just watches.

Detection mode logs a matching request but lets it through. Nothing is blocked. It exists so you can turn the WAF on against real traffic, watch what it would have blocked, and tune out false positives before they break anything. Prevention mode blocks matching requests outright. This is the mode that protects you; detection alone protects nothing.

The standard playbook is to launch in detection mode, run it for a week or two against production traffic, read the logs, add exclusions for the legitimate requests it flagged, and then flip to prevention once you trust it. (There's a deeper piece on tuning these modes and reading WAF logs, if you want to go further than this overview.) The trap — and I've seen it in real environments — is a WAF left in detection mode indefinitely, quietly logging attacks it was never configured to stop.

Azure WAF vs Azure Firewall — not the same thing

This is the confusion that causes actual security gaps, so it's worth being blunt. Azure Firewall and Azure WAF are different products protecting different layers, and most secure designs run both.

Azure Firewall is a network firewall. It filters traffic at Layers 3 and 4 — IP addresses, ports, protocols — across a virtual network. It decides which machines can talk to which, and on what ports. It never reads the contents of a web request. Azure WAF works at Layer 7, reading the actual HTTP request to catch web attacks like injection and cross-site scripting. One guards the network perimeter and internal segmentation; the other guards the application's front door against malicious requests. 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. If you want the full breakdown, I wrote a dedicated comparison: Azure Firewall vs WAF. It's also worth understanding how network security groups fit alongside the firewall, which the NSG vs Azure Firewall piece covers.

So which one do you enable?

Start from where your app lives. If it's internet-facing and global, Front Door WAF puts inspection at the edge, close to your users, before traffic reaches your region — and it comes with a comparison worth reading between Front Door and Application Gateway if you're weighing the two fronting services. If your app is regional, internal, or needs Layer 7 routing to backends inside your virtual network, Application Gateway WAF is the fit, and the Application Gateway WAF deep-dive walks through setting it up. If you're only choosing a load balancer and haven't decided you need Layer 7 at all, the load balancer vs Application Gateway comparison is the right starting point — a WAF only rides on the Layer 7 services.

Whichever you choose, the mechanics are the same: create a WAF 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