Web Application Firewall (WAF)
Protect web applications with WAF on Application Gateway and Front Door — managed rules, custom rules, detection vs prevention mode, and how WAF complements Azure Firewall.
Web Application Firewall (WAF)
WAF protects web applications from common exploits like SQL injection, cross-site scripting (XSS), and other OWASP Top 10 vulnerabilities. It’s the Layer 7 complement to Azure Firewall’s Layer 3/4 protection.
🎬 Video coming soon
Web Application Firewall (WAF)
Web Application Firewall (WAF)
~11:00WAF is a bodyguard for your web applications — it checks every HTTP request for malicious patterns like SQL injection and cross-site scripting. Azure Firewall protects your network. WAF protects your web apps. They’re complementary.
WAF on Application Gateway vs Front Door
| Feature | WAF on Application Gateway | WAF on Front Door |
|---|---|---|
| Scope | Regional (per Application Gateway) | Global (at edge PoPs worldwide) |
| Rule set | OWASP CRS 3.2, 3.1, 3.0, 2.2.9 | Default Rule Set (DRS) 2.1, 2.0, 1.1 |
| Custom rules | Yes | Yes |
| Managed rules | Yes (OWASP Core Rule Set) | Yes (DRS — Premium tier only) |
| Bot protection | Limited | Yes (Premium tier) |
| Geo-filtering | Via custom rules | Built-in |
| Rate limiting | Via custom rules | Built-in |
| Per-site policies | Yes (per listener) | Yes (per route) |
| Best for | Regional web apps, internal applications | Global web apps, CDN-fronted applications |
Exam Tip: On Front Door, managed WAF rules (DRS) and bot protection require the Premium tier. Standard Front Door only gets custom WAF rules. On Application Gateway, WAF is available as a WAF v2 SKU (no separate tier needed).
Detection vs Prevention Mode
| Mode | Behaviour | When to Use |
|---|---|---|
| Detection | Logs attacks but does NOT block them. Traffic passes through. | Initial deployment — learn what gets flagged. |
| Prevention | Logs AND blocks attacks. Malicious requests get a 403 Forbidden. | Production — after tuning false positives. |
Best practice workflow:
- Deploy in Detection mode — let WAF log for 1-2 weeks
- Monitor logs — identify false positives (legitimate traffic flagged as attacks)
- Create exclusions — for specific request headers, cookies, or body fields that trigger false positives
- Switch to Prevention mode — WAF now blocks actual attacks while allowing legitimate traffic
- Continuously monitor — new false positives may appear as application changes
Exam Tip — False Positive Management: The exam tests that you know the recommended workflow. Don’t deploy straight to Prevention mode — you’ll block legitimate users. Detection first, exclusions, then Prevention.
WAF False Positive Management
False positives are the biggest operational challenge with WAF. Here is how to handle them without weakening your protection:
1. Per-field exclusions (preferred): Exclude specific request headers, cookies, or body fields from a specific rule. Example: exclude the “comment” form field from SQL injection rule 942130. This is the most targeted fix.
2. Custom allow rules: Create a custom rule to allow traffic from known-good sources (monitoring IPs, partner APIs) before managed rules evaluate it. Custom rules process first.
3. Per-rule disabling: Disable a specific managed rule ID that causes persistent false positives. Only disable the individual rule, never an entire rule group.
4. Never disable the entire WAF: If you have too many false positives, the fix is better exclusions and custom rules — not turning WAF off. Switching back to Detection mode temporarily while you tune is acceptable.
WAF Policies
A WAF policy is a standalone resource containing all WAF configuration:
Components of a WAF policy:
| Component | Purpose |
|---|---|
| Managed rules | Pre-built rule sets from Microsoft (OWASP CRS or DRS). Enable/disable individual rule groups. |
| Custom rules | Your own rules based on IP, geo, rate limiting, or request attributes. Processed before managed rules. |
| Exclusions | Specific request fields to exclude from rule evaluation (fix false positives). |
| Mode | Detection or Prevention. |
| Policy settings | Request body inspection, file upload size limits, etc. |
Custom rules are processed before managed rules. This means your custom Allow rules can whitelist traffic before managed rules would block it.
Associating WAF Policies
| Platform | Association Level |
|---|---|
| Application Gateway | Per gateway (global), per listener (per-site), or per URL path map |
| Front Door | Per endpoint (global) or per route (per-site) |
A more specific association overrides a broader one. A per-listener policy overrides the per-gateway policy for that listener’s traffic.
Custom Rules — Common Patterns
Block specific IPs or countries: Block requests from IP ranges known for abuse, or restrict access to specific countries for compliance.
Rate limiting: Limit the number of requests per client IP within a time window. Prevents brute-force and scraping attacks.
- Set threshold (e.g., 100 requests per minute per IP)
- Action: Block, Log, or custom response
Allow known-good traffic: Whitelist specific IPs (e.g., monitoring services, partner APIs) so managed rules don’t block them.
Azure Firewall vs WAF — They’re Complementary
| Feature | Azure Firewall | WAF |
|---|---|---|
| Layer | Layer 3/4 (+ limited L7 with FQDN) | Layer 7 (HTTP/HTTPS only) |
| Scope | All traffic (TCP, UDP, ICMP, HTTP) | HTTP/HTTPS only |
| OWASP protection | No | Yes — core capability |
| SQL injection / XSS | No | Yes |
| FQDN filtering | Yes | Not the primary purpose |
| IDPS | Premium only | No (different attack types) |
| Deployment | Hub VNet / VWAN hub | On Application Gateway or Front Door |
| Relationship | Network-level firewall | Application-level firewall |
They work together: Azure Firewall filters network traffic (block bad IPs, restrict outbound, FQDN filtering). WAF protects web applications from application-layer attacks (SQL injection, XSS, OWASP). Deploy both in enterprise architectures.
🔒 Aisha’s defence-in-depth:
Internet → Front Door WAF (global, blocks OWASP attacks)
→ Azure Firewall (hub, filters network traffic)
→ Application Gateway WAF (regional, additional rules)
→ Backend VMs
Key Takeaways
- WAF on Application Gateway: regional, OWASP CRS
- WAF on Front Door: global at edge, DRS (Premium only for managed rules)
- Always deploy Detection mode first, then Prevention after tuning
- Custom rules process before managed rules
- Azure Firewall and WAF are complementary — use both for defence-in-depth
Test Your Knowledge
Sam deploys WAF in Prevention mode immediately. Customers report they can't submit forms on his website. What went wrong?
Aisha needs both network-level filtering and OWASP protection for her web applications. What should she deploy?
Congratulations! 🎉
You’ve completed all 26 modules of the AZ-700 study guide. You’ve covered:
- Domain 1: Virtual Networks, IP addressing, DNS, routing, peering, monitoring, and DDoS protection
- Domain 2: Site-to-Site VPN, Point-to-Site VPN, ExpressRoute, Virtual WAN, and hybrid connectivity design
- Domain 3: Load Balancer, Traffic Manager, Application Gateway, Front Door, and the load balancing decision matrix
- Domain 4: Private Link, private endpoints, DNS for private endpoints, and service endpoints
- Domain 5: NSGs, ASGs, flow logs, Azure Firewall, Firewall Manager, and WAF
What’s next:
- Review the flashcards and quizzes — aim for 100% on all quiz questions
- Practice with hands-on labs in your Azure subscription
- Take practice exams to identify weak areas
- Revisit modules where you scored lowest on practice exams
You’ve got this! 💪