Do you need a WAF on Application Gateway? If it serves the public internet, yes
Application Gateway routes and load-balances your HTTP traffic, but it does not read the request for an attack — the WAF is the part that inspects every request against the OWASP rules and blocks the SQL injection before it reaches your database.
New to cloud? CAMPUX is a free, build-first course. Start here →
Here is the short answer. If the application behind your gateway is reachable from the public internet and it takes user input — a login form, a search box, an API that accepts JSON — you want the WAF turned on. Every public web app is being probed for the same handful of exploits around the clock, and the OWASP Top 10 has not changed shape in years: SQL injection, cross-site scripting, and a small family of common tricks account for most of what actually gets through. The WAF is a paid tier of Application Gateway that reads the request body and headers and stops those patterns at the edge, before your code ever sees them.
What the WAF adds on top of Application Gateway
A plain Application Gateway is an application delivery controller. It terminates TLS, load-balances across your backends, and routes by hostname or URL path — everything a smart Layer 7 front door should do with the envelope of the request. What it does not do is look inside for malice. The WAF is that inspection layer. Microsoft's own description is direct: a WAF deployment on Application Gateway "actively safeguards your web applications against common exploits and vulnerabilities" such as SQL injection and cross-site scripting, and it does this without modifying back-end code. You do not touch the app. You attach a WAF policy to the gateway, and every request flowing through gets read against a rule set before it is forwarded.
The attacks it actually blocks
The WAF is built on the OWASP Core Rule Set (CRS) — a maintained library of signatures for the attacks that hit real web apps. Out of the box it catches SQL injection, cross-site scripting, command injection, HTTP request smuggling and response splitting, remote file inclusion, protocol violations, and the crawlers and scanners that map your app before someone tries the door. It can inspect JSON and XML request bodies, not just the URL, which matters the moment you run an API. These come as Microsoft-managed rule sets — the OWASP CRS versions and the newer Default Rule Set — so the signatures update without you writing any of them. The point is coverage you did not have to author and do not have to maintain.
The gateway reads the envelope and decides where the request goes. The WAF opens the envelope, reads the letter, and decides whether the request is an attack.
Detection vs Prevention — and why you start in Detection
The WAF runs in one of two modes, and the difference is whether it blocks or merely watches. In Detection mode, it logs every rule match but forwards the request anyway — nothing is blocked. In Prevention mode, a matched attack is stopped cold: the client gets a 403 and the connection closes, with the block recorded in the WAF log.
New teams almost always run Detection first, and that is the right instinct. Managed rules are aggressive by design, and a real application always has some legitimate traffic that trips a signature — an auth token that looks like an injection, a form field full of code samples. If you switch straight to Prevention, you block your own users on day one. Microsoft's guidance is to run a freshly deployed WAF in Detection for a short window, read the logs, then write exclusions and custom rules for the false positives before you flip to Prevention. You tune with real traffic, then you turn on the blocking.
Modern CRS does not block on a single rule match. It uses anomaly scoring: each matched rule adds points by severity — a Critical is 5, an Error 4, a Warning 3 — and the request is blocked in Prevention mode once the total hits the threshold of 5. So one Critical match blocks on its own, while a lone Warning (3) does not. This is why reading the logs matters: a request that got through might still be one Warning away from the line, and your exclusions should be surgical, not blanket.
Custom rules, rate limiting, and bots
Managed rules are the floor, not the ceiling. You also write custom rules — match conditions on IP, geography, headers, or body — and the WAF evaluates these before the managed set, so they win. Common uses: geo-filter to allow or block traffic by country, block a specific abusive IP range, or allow-list a partner. Rate-limiting rules cap how many requests a single client can make in a window, which is how you blunt credential-stuffing and scraping without touching the app. The Bot Manager Rule Set sorts incoming bots into good, bad, and unknown — letting a verified Googlebot through while blocking malicious crawlers pulled from Microsoft's threat intelligence feed. One gateway can carry per-site policies, so a marketing page and a payments API behind the same gateway get different rules.
When you'd reach for Front Door WAF instead
Application Gateway is regional — it lives in one Azure region, in front of backends you typically keep in that region. If your users are in one geography and your app is one deployment, that is exactly right, and the same reasoning that picks a gateway over a plain load balancer applies. But if you serve a global audience and want the inspection to happen at the edge — close to users, in front of a multi-region app — the WAF also runs on Azure Front Door, which is Microsoft's global entry point. Same OWASP rule sets, same Detection/Prevention modes; the difference is where it sits. That regional-versus-global choice is the same fork covered in Front Door vs Application Gateway: pick the gateway for a regional app, Front Door for a global one.
The takeaway
The WAF is the difference between a front door that routes traffic and a front door that reads it for an attack. On Application Gateway it inspects every HTTP request against the OWASP rule sets, stops SQL injection and XSS and the common exploits before they reach your code, and gives you custom rules, rate limiting, and bot control on top. Deploy it in Detection, tune the false positives against real logs, then move to Prevention — and if the app is global rather than regional, run the same WAF on Front Door. For anything public that takes user input, turning it on is not the paranoid choice. It is the default one.
Questions people also ask
Do you need a WAF on Application Gateway?
If the app behind the gateway is reachable from the public internet and takes user input, yes. The WAF adds Layer 7 inspection of every HTTP request against OWASP managed rule sets, blocking SQL injection, cross-site scripting, and common exploits before they reach your code. For an internal-only app, you can skip it.
What is the difference between a WAF and a firewall?
A network firewall works at Layer 3 and Layer 4, filtering traffic by IP address, port, and protocol. A WAF works at Layer 7 and reads the HTTP request itself, blocking application attacks like SQL injection and cross-site scripting. They protect against different threats, so you run both, not one instead of the other.
What does the Application Gateway WAF protect against?
It runs on the OWASP Core Rule Set and the Microsoft Default Rule Set, catching SQL injection, cross-site scripting, command injection, request smuggling, remote file inclusion, and protocol violations. It inspects JSON and XML request bodies, not just the URL. You also add custom rules, rate limiting, and bot protection on top.
What is the difference between Application Gateway WAF and Front Door WAF?
Both run the same OWASP rule sets and the same Detection and Prevention modes. The difference is placement. Application Gateway WAF is regional, sitting in one Azure region in front of that region's backends. Front Door WAF is global, inspecting requests at the edge close to users in front of a multi-region app.
What is the difference between Detection and Prevention mode?
In Detection mode the WAF logs every rule match but forwards the request, so nothing is blocked. In Prevention mode a matched attack is stopped: the client gets a 403 and the connection closes. New teams run Detection first, tune the false positives against real logs, then switch to Prevention.