When should you use a WAF on Azure Application Gateway?

Application Gateway routes HTTP traffic; its WAF capability adds policy-based inspection for common web attacks. The right choice depends on exposure, origin design, required protections, and the cost of false positives.

Start with a WAF for an internet-facing web application unless a documented threat model or architecture calls for a different control. Microsoft recommends WAF for public-facing applications, but adding a gateway is not a checkbox: verify that traffic cannot bypass the protected entry point, choose a supported WAF policy and managed rules, account for false positives and operating cost, and keep application-level security controls in place. For private-only workloads, decide from the actual exposure and requirements rather than applying a public-ingress default.

Application Gateway is not automatically a WAF

Application Gateway is a regional Layer 7 load balancer. The WAF is an optional capability: choose the supported WAF_v2 SKU and configure a WAF policy. A Standard_v2 gateway still routes and load-balances web traffic, but it does not provide Application Gateway WAF inspection. Microsoft retired the v1 SKUs in April 2026, so current deployments should be reviewed against the v2 documentation.

What the WAF adds on top of Application Gateway

A plain Standard_v2 Application Gateway is an application delivery controller. It terminates TLS, load-balances across backends, and routes by hostname or URL path. WAF_v2 adds the WAF capability, configured through a policy associated with the gateway, listener, or supported route scope. Microsoft-managed rules can detect common exploit patterns, and custom rules let operators define additional conditions. The gateway and WAF policy must be configured so protected requests pass through the intended inspection path.

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.

Custom rules, rate limiting, and bots

Managed rules are a baseline, not a substitute for application-specific controls. Custom rules can match conditions such as IP, geography, headers, or paths, and may support rate limits or other actions depending on the host service. Evaluation order, actions, bot features, and policy scope differ between Application Gateway and Front Door; consult the service-specific documentation before relying on a rule to override another. Keep each exception narrow and test it against the actual traffic path.

When you'd reach for Front Door WAF instead

Application Gateway is regional — it runs in one Azure region and can connect to backends in the network topology you configure. If regional Layer 7 routing fits, its WAF may be the right ingress control. For a global edge entry point, evaluate Azure Front Door instead. Both products offer WAF policies, but their rule sets, tiers, and features differ; check the current support matrix before assuming configuration parity. The service choice is covered in Front Door vs Application Gateway.

The takeaway

A WAF adds a useful managed inspection layer, not a guarantee. Confirm that requests cannot bypass the gateway, review the managed rules and policy scope, start in Detection, tune against representative traffic, and move to Prevention when the policy is ready to enforce. Keep authorization, validation, and secure coding in the application. For global ingress, compare Front Door's WAF capabilities and tier separately rather than assuming it uses an identical policy.

Questions people also ask

Do you need a WAF on Application Gateway?

For an internet-facing web application, Microsoft recommends a WAF as part of the ingress design. Confirm that the gateway is the enforced path to the origin, select a supported managed rule set, tune false positives, and include the cost and operational work in the decision. Private-only applications should be assessed against their actual exposure and requirements.

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 offer service-specific WAF policies and Detection/Prevention behavior, but the available managed rule sets and features vary by product and tier. Application Gateway WAF is regional and integrated with a virtual network; Front Door WAF inspects traffic at Microsoft's global edge. Compare the current product documentation before choosing based on rules or features.

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.

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