This chapter covers Azure Web Application Firewall (WAF), a critical security service that protects web applications from common exploits like SQL injection and cross-site scripting. For the SC-900 exam, understanding WAF is part of Objective 3.4, which focuses on Azure security solutions. Approximately 5-10% of exam questions touch on WAF, often in scenarios comparing it to other security services like Azure Firewall or Network Security Groups. You will need to know what WAF protects against, how it integrates with Azure Front Door and Application Gateway, and its key features like OWASP rulesets and bot protection.
Jump to a section
Imagine a nightclub that has a standard security guard (like a network firewall) who checks IDs and ensures no one is carrying weapons. But the club also has a specialized bouncer at the VIP entrance (the WAF) who knows the specific dance moves and dress code of the VIP section. This bouncer examines every guest's behavior: if someone tries to sneak in a fake VIP pass (SQL injection), the bouncer recognizes the pattern because the pass has the wrong watermark and font. If a guest tries to flood the dance floor by repeatedly entering and exiting (DDoS), the bouncer counts the frequency and blocks them after 10 attempts per minute. The bouncer also checks for oversized handbags that might hide a camera (large request bodies) and inspects the guest's shoes for hidden compartments (malicious headers). Unlike the standard guard who only looks at the ID and bag, the bouncer understands the context of the VIP area—the expected behavior of legitimate guests. If the bouncer sees a guest trying to use a password that matches a known breached password list (credential stuffing), the bouncer stops them immediately. The bouncer's rules are updated weekly by the club manager (security team) based on new threats. This specialized bouncer doesn't replace the standard guard; they work together to provide layered security.
What is Azure Web Application Firewall (WAF)?
Azure Web Application Firewall (WAF) is a cloud-native service that provides centralized protection for web applications against common exploits and vulnerabilities. It is part of the Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN) services. WAF inspects incoming HTTP/HTTPS traffic at the application layer (Layer 7 of the OSI model) and applies a set of rules to block or allow requests based on their content. The primary purpose is to defend against attacks like SQL injection, cross-site scripting (XSS), session hijacking, and OWASP Top 10 threats.
How WAF Works Internally
When a client sends an HTTP request to a web application protected by WAF, the request first reaches the WAF endpoint (e.g., Application Gateway or Front Door). WAF intercepts the request before it reaches the backend web server. The WAF engine performs the following steps:
Request Parsing: The WAF parses the HTTP request, including headers, body, cookies, and query strings. It decodes URL-encoded payloads and normalizes data to detect evasion techniques.
Rule Evaluation: WAF evaluates the request against a set of rules. These rules are grouped into rule sets, such as the OWASP Core Rule Set (CRS) or Microsoft's own managed rule sets. Each rule has a severity level (e.g., Critical, High, Medium, Low) and an action (e.g., Block, Allow, Log, Anomaly Scoring).
Anomaly Scoring (if enabled): Instead of blocking on the first match, WAF can use anomaly scoring. Each rule match adds a score. If the total score exceeds a threshold (default 5), the request is blocked. This reduces false positives.
Action Execution: Based on the rule evaluation, WAF takes the configured action: Block (returns 403 Forbidden), Allow (passes request to backend), Log (logs the request but allows it), or Anomaly Scoring (increments score).
Response Inspection: WAF can also inspect responses from the backend to prevent data leakage or block malicious content.
Key Components and Defaults
OWASP Core Rule Set (CRS): Version 3.2 (default) includes rules for SQLi, XSS, PHP injection, etc. Microsoft also provides Managed Rule Sets that are updated automatically.
Rule Actions:
Allow: Request passes through.
Block: Request is blocked with 403 Forbidden.
Log: Request is logged but allowed.
Anomaly Scoring: Request is scored; if total exceeds threshold (default 5), it is blocked.
WAF Policy: A collection of rules and settings. You can create custom rules (e.g., block IP addresses, geo-filter) or use managed rules.
Rate Limiting: Limits the number of requests from a single IP within a time window (e.g., 100 requests per 5 minutes). Default is disabled; you must configure.
Bot Protection: Uses Microsoft’s Threat Intelligence to detect and block malicious bots. Can be set to Allow, Block, or Log.
Logging: WAF logs are sent to Azure Monitor, Log Analytics, or Storage. You can view blocked requests, matched rules, and anomaly scores.
Configuration and Verification
WAF is configured via Azure Portal, PowerShell, CLI, or ARM templates. To enable WAF on an Application Gateway:
New-AzApplicationGatewayWebApplicationFirewallConfiguration -Enabled $true -FirewallMode Prevention -RuleSetType "OWASP" -RuleSetVersion "3.2"To create a WAF policy:
az network application-gateway waf-policy create --name MyWAFPolicy --resource-group MyRG --type OWASP --version 3.2Verification: Use Get-AzApplicationGatewayWafPolicy to check policy details. For logging, query Azure Monitor:
AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS" and OperationName == "ApplicationGatewayFirewall"
| project TimeGenerated, Message, RuleSetType, RuleGroup, RuleIdInteraction with Related Technologies
Azure Firewall: Operates at Layer 3-4 and Layer 7 (for TLS inspection). WAF is Layer 7 only. They complement each other: Azure Firewall provides network segmentation and filtering, while WAF protects the application layer.
Network Security Groups (NSGs): Operate at Layer 3-4. NSGs filter traffic at the subnet or NIC level. WAF is applied at the application level.
Azure DDoS Protection: Mitigates volumetric DDoS attacks at the network layer. WAF can handle application-layer DDoS (e.g., HTTP flood) with rate limiting.
Azure Front Door: Global load balancer with built-in WAF. WAF policies can be associated with Front Door endpoints to protect against web exploits.
Specific Values and Defaults
WAF Mode: Detection (log only) or Prevention (block). Default is Detection.
Anomaly Scoring Threshold: Default is 5. Range: 0-20.
Rate Limit Default: Not set; you must define the threshold and interval (e.g., 100 requests per 5 minutes).
OWASP CRS Version: Default 3.2; older versions like 3.0 or 2.2.9 are available.
Managed Rule Sets: Microsoft_DefaultRuleSet (version 1.0), Microsoft_BotManagerRuleSet (version 1.0).
Custom Rules: Up to 100 custom rules per policy.
TLS/SSL: WAF supports TLS 1.2 and 1.3; older versions are deprecated.
Exam-Relevant Details
WAF can be deployed with Azure Application Gateway (regional), Azure Front Door (global), or Azure CDN (edge).
WAF is not a standalone service; it is always attached to one of these services.
The OWASP CRS is the default rule set; Microsoft Managed Rules are newer and auto-updated.
Bot Protection is a separate rule set; it is not part of OWASP.
Geo-filtering is available via custom rules (e.g., block all traffic except from US).
Rate limiting is configured in custom rules, not in the default rule set.
WAF logs contain RuleId, Message, Action, and ClientIp.
Client sends HTTP request
A client (browser or API consumer) sends an HTTP request to the web application's public endpoint, which is fronted by Azure Application Gateway with WAF enabled. The request includes headers, cookies, query strings, and possibly a body (e.g., POST data). The request reaches the Application Gateway's frontend IP address on port 80 or 443. If HTTPS, TLS termination occurs at the gateway.
WAF intercepts and parses request
The WAF engine receives the request before it is forwarded to the backend. It parses the raw HTTP stream, decoding URL-encoded parameters, normalizing path traversal attempts (e.g., `../`), and extracting headers like `User-Agent` and `Cookie`. It also decompresses request bodies if needed (e.g., gzip). The parser handles multipart form data and JSON payloads.
Evaluate against managed rules
The parsed request is evaluated against the OWASP Core Rule Set (version 3.2 by default). Each rule checks for patterns indicating SQL injection (e.g., `' OR 1=1--`), cross-site scripting (e.g., `<script>` tags), or other exploits. Rules have severity levels: Critical (score 10), High (score 5), Medium (score 3), Low (score 1). If a rule matches, the action depends on the WAF mode: in Detection mode, it logs the match; in Prevention mode, it may block or apply anomaly scoring.
Anomaly scoring calculation
If anomaly scoring is enabled (default in Prevention mode), each matched rule adds its severity score to a cumulative total for that request. The default threshold is 5. For example, if one Critical rule (score 10) matches, the total exceeds 5 and the request is blocked. If two Low rules (score 1 each) match, total is 2, which is below threshold, so the request is allowed but logged. The anomaly score resets after each request.
Action execution and response
Based on the evaluation, WAF takes action: if blocked, it returns a 403 Forbidden response to the client with a default message (customizable). If allowed, the request is forwarded to the backend web server. WAF can also inspect the response from the backend (e.g., to block sensitive data in the body). All actions are logged to Azure Monitor with details like RuleId, ClientIp, and Action taken.
In my experience as a cloud security engineer, I've deployed Azure WAF in several enterprise scenarios. One common use case is protecting an e-commerce website hosted on Azure VMs behind Application Gateway. The site was experiencing SQL injection attempts via the search box. We enabled WAF in Prevention mode with OWASP CRS 3.2 and set anomaly scoring threshold to 5. Within the first week, WAF blocked over 200 malicious requests while allowing legitimate traffic. However, we encountered false positives: a legitimate user had a username containing "OR" which triggered a SQLi rule. We created a custom exclusion rule for that specific parameter to whitelist it.
Another scenario is a global SaaS application using Azure Front Door with WAF. The company needed to block traffic from certain countries due to licensing restrictions. We used custom rules with geo-filtering to block all requests from outside the US and EU. Additionally, we enabled bot protection to block known malicious bots from scraping pricing data. The rate limiting feature was configured to allow 1000 requests per IP per hour to prevent credential stuffing. Performance considerations: WAF adds minimal latency (under 1ms per request) but can impact throughput if rules are too complex. We monitored CPU usage on Application Gateway to ensure it stayed below 80%.
A common misconfiguration I've seen is leaving WAF in Detection mode in production. This logs attacks but does not block them, giving a false sense of security. Another mistake is not updating managed rule sets; Microsoft releases updates automatically only if you enable them. Finally, forgetting to configure logging: without logs, you cannot tune rules or investigate incidents. I always recommend enabling logs to Log Analytics and setting up alerts for blocked requests.
For SC-900 Objective 3.4, the exam tests your understanding of what WAF is, what it protects against, and how it integrates with other Azure services. Key points:
WAF operates at Layer 7 – This is a common trick: candidates confuse WAF with Azure Firewall (Layer 3-4) or NSGs (Layer 3-4). Remember: WAF inspects HTTP/HTTPS traffic, not IP packets.
WAF is not standalone – It must be associated with Application Gateway, Front Door, or CDN. A question might ask: 'Which service can you use to deploy WAF?' The answer is Application Gateway, not a separate WAF service.
OWASP CRS vs. Managed Rules – The exam expects you to know that OWASP CRS is the default rule set, but Microsoft Managed Rules are newer and auto-updated. A question might ask: 'Which rule set provides automatic updates?' Answer: Microsoft Managed Rule Sets.
Anomaly Scoring – Understand that anomaly scoring reduces false positives by requiring multiple rule matches before blocking. Default threshold is 5. A question might give a scenario with scores and ask if the request is blocked.
Bot Protection – Know that bot protection is a separate rule set, not part of OWASP. It uses Microsoft Threat Intelligence.
Rate Limiting – Configured via custom rules, not managed rules. Default is disabled.
Common wrong answers: - 'WAF can replace Azure Firewall' – False; they complement each other. - 'WAF protects against DDoS attacks' – Partially true; it handles application-layer DDoS but not volumetric; Azure DDoS Protection is needed. - 'WAF is available as a standalone service' – False; it's always attached.
Exam trap: A question might describe a scenario where traffic is blocked and ask why. The answer could be that the request exceeded the anomaly score threshold. Or that a custom rule blocked the IP. Always look for clues about Layer 7 attacks (SQLi, XSS) to select WAF over other services.
WAF is a Layer 7 service that protects web applications from OWASP Top 10 threats like SQL injection and XSS.
WAF is not standalone; it integrates with Azure Application Gateway, Front Door, or CDN.
Default rule set is OWASP CRS 3.2; Microsoft Managed Rules are auto-updated.
Anomaly scoring default threshold is 5; used to reduce false positives.
WAF modes: Detection (log only) and Prevention (block).
Bot protection is a separate rule set using Microsoft Threat Intelligence.
Rate limiting is configured via custom rules, not managed rules.
Logging must be enabled separately via diagnostic settings.
WAF does not replace Azure Firewall or DDoS Protection; they complement each other.
Geo-filtering and IP allow/block lists are available via custom rules.
These come up on the exam all the time. Here's how to tell them apart.
Azure WAF
Operates at Layer 7 (application layer).
Protects against web exploits (SQLi, XSS, OWASP Top 10).
Must be attached to Application Gateway, Front Door, or CDN.
Supports OWASP CRS and Microsoft Managed Rule Sets.
Provides bot protection and rate limiting.
Azure Firewall
Operates at Layers 3-4 (network) and Layer 7 (TLS inspection).
Provides network filtering, NAT, and threat intelligence.
Is a standalone service with its own SKU.
Uses Microsoft Threat Intelligence and custom rules.
Supports DNS proxy, VPN, and traffic routing.
Mistake
WAF can replace Azure Firewall.
Correct
WAF operates at Layer 7 (application) and protects web apps from exploits like SQL injection. Azure Firewall operates at Layers 3-4 (network) and Layer 7 for TLS inspection. They are complementary; Azure Firewall provides network segmentation and filtering, while WAF protects the application layer.
Mistake
WAF is a standalone Azure service.
Correct
WAF is not a standalone service; it is always deployed as part of Azure Application Gateway, Azure Front Door, or Azure CDN. You cannot create a WAF resource by itself; it must be attached to one of these services.
Mistake
WAF blocks all malicious traffic automatically without configuration.
Correct
WAF comes with default rule sets (OWASP CRS) but requires proper configuration, including setting the mode (Detection or Prevention), enabling anomaly scoring, and tuning rules to avoid false positives. Bot protection and rate limiting are optional and must be explicitly enabled.
Mistake
WAF protects against volumetric DDoS attacks.
Correct
WAF can mitigate application-layer DDoS (e.g., HTTP flood) using rate limiting, but it does not protect against network-layer volumetric attacks (e.g., SYN flood). Azure DDoS Protection is required for volumetric DDoS mitigation.
Mistake
WAF logs are enabled by default.
Correct
WAF logging is not enabled by default. You must configure diagnostic settings to send logs to Log Analytics, Storage, or Event Hubs. Without logs, you cannot monitor attacks or tune rules.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Detection mode logs matched rules but allows the request to pass to the backend. Prevention mode blocks requests that match rules (or exceed anomaly score threshold). For SC-900, remember that Detection is for testing and tuning; Prevention is for production. The default mode is Detection.
No, WAF is not a standalone service. It must be attached to Azure Application Gateway, Azure Front Door, or Azure CDN. You cannot create a WAF policy without one of these services. On the exam, if a question asks for a service to deploy WAF, choose Application Gateway or Front Door.
Anomaly scoring is a feature that reduces false positives by accumulating scores from multiple rule matches instead of blocking on the first match. Each rule has a severity score (Critical=10, High=5, Medium=3, Low=1). When the total score exceeds the threshold (default 5), the request is blocked. This allows legitimate requests that trigger low-severity rules to pass.
WAF can mitigate application-layer DDoS attacks (e.g., HTTP flood) using rate limiting, but it does not protect against network-layer volumetric attacks (e.g., SYN flood). For full DDoS protection, you need Azure DDoS Protection. The exam may test this distinction.
Logging is not enabled by default. You must configure diagnostic settings on the Application Gateway or Front Door resource. Send logs to Log Analytics, Storage Account, or Event Hubs. Use Azure Monitor to query logs. Example KQL: `AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' and OperationName == 'ApplicationGatewayFirewall'`.
Microsoft Managed Rule Sets are pre-configured rule sets that are automatically updated by Microsoft to protect against new vulnerabilities. They include the Default Rule Set (SQLi, XSS, etc.) and the Bot Manager Rule Set. Unlike OWASP CRS, they are managed by Microsoft and require no manual updates.
Yes, you can create custom rules to allow, block, or log traffic based on source IP, geo-location, request headers, URI, etc. Custom rules are evaluated before managed rules. You can use them for geo-filtering, IP whitelisting, or rate limiting. Up to 100 custom rules per policy.
You've just covered Azure Web Application Firewall (WAF) — now see how well it sticks with free SC-900 practice questions. Full explanations included, no account needed.
Done with this chapter?