Web Application Firewall
The Azure Web Application Firewall inspects HTTP traffic for application-layer attacks — SQL injection, cross-site scripting, the rest of the OWASP Top 10 — and bots, blocking malicious requests before they reach the application. It is not a standalone service but a capability you attach to Application Gateway (regional) or Front Door (global edge).
Where it runs determines what it protects and how early. On Front Door, the WAF blocks attacks at the edge before they enter a region; on Application Gateway, it guards a regional web tier. Choosing the attachment point is really a choice about whether protection belongs at the global edge or the regional ingress.
Deployment
The WAF runs in one of two places. Attached to Front Door, it inspects at the global edge, stopping attacks before they reach any region and covering volumetric Layer 7 floods near the source. Attached to Application Gateway, it inspects regional traffic inside a VNet. Many architectures use the Front Door WAF as the outer layer and rely on network controls behind it.
Managed Rule Sets
Microsoft-managed rule sets, based on the OWASP Core Rule Set, encode protection against common attack classes and update as new threats emerge — so you inherit current coverage without writing rules. Bot-protection rule sets classify and filter known good and bad bots. Managed rules are the foundation; you tune around them rather than building from scratch.
Custom Rules
Custom rules add organization-specific controls: rate limiting to blunt brute-force and scraping, geo-filtering to block or allow regions, and match rules on headers, URIs, or IPs. Rate limiting in particular is the practical defense against credential-stuffing and Layer 7 abuse that managed signatures do not catch.
Detection and Prevention
The WAF runs in detection mode (log matches only) or prevention mode (block them). The disciplined rollout is to run in detection first, review what would have been blocked, tune away false positives, then switch to prevention. A WAF left in detection mode indefinitely provides visibility but no protection — a common and dangerous misconfiguration.
- Leaving the WAF in detection mode indefinitely and believing it is blocking — detection only logs; prevention blocks.
- Skipping the tuning pass, so prevention mode blocks legitimate traffic and the WAF gets disabled in a panic.
- Attaching the WAF to Application Gateway only, leaving global edge floods to reach a region when Front Door's WAF would stop them sooner.
- Relying on managed rules alone with no rate limiting, leaving credential-stuffing and scraping unaddressed.
- Leaving origins reachable directly so attackers bypass the WAF entirely by going around the edge.
- Never reviewing WAF logs, so emerging attack patterns and false positives both go unnoticed.
- Enable Microsoft-managed (OWASP CRS) rule sets as the baseline and keep them updated.
- Roll out in detection mode, tune away false positives, then switch to prevention.
- Add rate limiting and geo-filtering as custom rules for brute-force, scraping, and region control.
- Put the WAF on Front Door for global edge protection, optionally with Application Gateway's WAF regionally.
- Lock origins to accept traffic only from the WAF front end so it cannot be bypassed.
- Review WAF logs regularly for emerging attacks and false positives.
Knowledge Check
A WAF has been enabled for weeks but no attacks are ever blocked. What is the most likely cause?
- It is in detection mode, which only logs — prevention mode is required to block
- The Microsoft-managed OWASP CRS rule sets are disabled by default on a new WAF policy
- The WAF is unable to inspect any encrypted HTTPS request traffic at all
- A custom rate-limiting rule is silently overriding all of the managed signature rules
Why attach the WAF to Front Door rather than only Application Gateway?
- Front Door inspects at the global edge, stopping attacks and L7 floods before they reach any region
- Application Gateway is simply unable to run a WAF of any kind at all
- Front Door is the only one of the two options that supports the Microsoft-managed OWASP rule sets at all
- Edge WAFs on Front Door do not require any detection-mode tuning pass beforehand
Which control best addresses credential-stuffing that managed signatures miss?
- A custom rate-limiting rule
- Switching managed rules from CRS to bot protection only
- Disabling prevention mode on the WAF
- Geo-filtering all inbound traffic globally
You got correct