Web Application Firewall (WAF)

Azure Web Application Firewall (WAF) is a cloud-native, managed service that provides centralized protection for web applications from common exploits such as SQL injection, cross-site scripting (XSS), and other OWASP Top 10 threats. It is integrated with Azure Application Gateway, Azure Front Door, and Azure Content Delivery Network (CDN) from Microsoft. WAF uses a rules engine that inspects HTTP/HTTPS traffic and applies a set of rules to detect and block malicious requests. The rules are based on the OWASP Core Rule Set (CRS) and are continuously updated by Microsoft to address new vulnerabilities.

When an HTTP request arrives at the WAF-enabled endpoint (Application Gateway, Front Door, or CDN), the WAF engine performs the following steps:

WAF can be configured via Azure Portal, PowerShell, CLI, or ARM templates. Below are examples for Azure Application Gateway.

Create a WAF Policy via Azure CLI:

az network application-gateway waf-policy create \
  --name myWAFPolicy \
  --resource-group myRG \
  --location eastus \
  --type OWASP \
  --version 3.2

Associate WAF Policy with Application Gateway:

az network application-gateway waf-policy update \
  --name myWAFPolicy \
  --resource-group myRG \
  --set properties.managedRules.managedRuleSets[0].ruleSetType=OWASP \
  --set properties.managedRules.managedRuleSets[0].ruleSetVersion=3.2

Enable WAF on an Application Gateway listener:

az network application-gateway http-listener update \
  --gateway-name myAppGateway \
  --name myListener \
  --resource-group myRG \
  --set firewallPolicy.id=/subscriptions/.../wafPolicies/myWAFPolicy

Verify WAF status:

az network application-gateway waf-policy list --resource-group myRG --output table

Check WAF logs:

az monitor log-analytics query \
  --workspace myWorkspace \
  --query "AzureDiagnostics | where ResourceType == 'APPLICATIONGATEWAYS' | where OperationName == 'ApplicationGatewayFirewall' | limit 10"

WAF inspection adds latency. For Application Gateway, expect ~1-2 ms additional latency per request. For Front Door, latencies are similar. High request rates (e.g., >10,000 req/s) may require scaling the WAF instance (e.g., using WAF_v2 with autoscaling). Rate limiting can also affect performance if thresholds are too low.

A large e-commerce company hosts its web application on Azure Application Gateway with WAF enabled. The application handles sensitive customer data (credit cards, personal info). The security team configures WAF with OWASP 3.2 rule set and custom rules to block requests from known malicious IP addresses (using IP reputation feeds). They set up rate limiting to prevent brute-force login attempts (10 requests per minute per IP on the login endpoint). They also add exclusions for the 'creditcard' POST parameter to avoid false positives from legitimate card numbers that might match SQL injection patterns. In production, they observe ~500 requests per second and the WAF adds ~2 ms latency. They use Azure Monitor to set up alerts for any spike in blocked requests. A misconfiguration occurred when they excluded too many parameters, allowing a SQL injection attack to pass through. They fixed it by narrowing exclusions to only specific fields.

A global SaaS company uses Azure Front Door with WAF to protect its web app deployed in multiple regions. They configure managed rules with anomaly scoring threshold of 10 to reduce false positives. They also create a custom rule to block requests from countries where they do not have customers (geo-blocking). For rate limiting, they set 200 requests per 5 minutes per client IP. They use Front Door's WAF logs to identify and block DDoS attacks at Layer 7. During a global promotion, traffic spikes to 10,000 req/s, and the WAF successfully handles it without dropping legitimate traffic. However, they noticed that some legitimate users from blocked countries were being denied; they added an exception for their corporate VPN IP range.

A fintech company exposes REST APIs behind Azure Application Gateway with WAF. They need to protect against API-specific attacks like parameter pollution and JSON injection. They disable some OWASP rules that cause false positives for JSON payloads (e.g., rules that check for script tags). They create custom rules to validate specific API endpoints: for example, block any request to /api/transfer that has a negative amount. They also set up rate limiting per API key (using a custom header). They use WAF logs to audit all API calls. A common mistake is forgetting to enable logging, which makes troubleshooting difficult. They also learned to test new rules in 'Log' mode before enabling 'Block' to avoid breaking the API.