What Is Azure Web Application Firewall?

Web applications are exposed to a constant stream of attacks—SQL injection, cross‑site scripting (XSS), remote file inclusion, and more. Without a dedicated security layer, these attacks can lead to data breaches, service disruption, and reputational damage. Azure Web Application Firewall (WAF) is a cloud‑native security service that inspects incoming HTTP/HTTPS traffic and blocks malicious requests before they reach your application. It integrates natively with Azure Application Gateway and Azure Front Door, providing centralized protection at the edge or the network layer. By leveraging a constantly updated rule set based on the OWASP Top 10, Azure WAF can detect and mitigate both known and emerging threats without requiring changes to your application code.

Unlike traditional network firewalls that operate at the packet level, Azure WAF understands web application protocols (HTTP/2, HTTP/1.1, WebSocket) and can parse headers, request bodies, and URLs to identify attack patterns. This deep inspection allows it to stop sophisticated attempts to exploit application logic or input validation weaknesses. For organizations that run their workloads on Azure, WAF becomes an essential part of a defence‑in‑depth strategy, complementing network security groups, DDoS protection, and identity‑aware access controls.

Key Features of Azure WAF

Protection Against the OWASP Top 10

The OWASP Top 10 represents the most critical web application security risks. Azure WAF ships with a managed rule set that covers injection attacks, broken authentication, sensitive data exposure, and more. The rules are regularly updated by Microsoft’s security research team, so you stay protected against zero‑day exploits as soon as patches are available. You can choose between the default rule set (version 3.x or 2.x) or opt for the newer Microsoft managed rule set that includes additional bot‑protection rules and anomaly scoring.

Custom Rules for Tailored Security

Out‑of‑the‑box rules are powerful, but no two applications are identical. Azure WAF allows you to write custom rules using simple conditions – match on IP addresses, geo‑location, request headers, URI patterns, or query string parameters. Custom rules support both allow and deny actions, and you can assign a priority to each rule so that critical exceptions are processed first. For example, you might create a rule to block all traffic from a specific country unless the request includes a valid API key, or allow a known administrative IP range while denying everything else.

Real‑Time Monitoring and Logging

Every request that Azure WAF processes can be logged to Azure Monitor, Log Analytics, or a storage account. The logs include detailed fields: rule ID, action taken (allowed, blocked, or logged), client IP, request URI, and a matching signature. This telemetry is crucial for security operations teams. With Azure Monitor alerts, you can trigger an email, SMS, or webhook when a specific attack signature is triggered repeatedly. The logs also integrate with Microsoft Sentinel (Azure’s SIEM) for advanced threat hunting and correlation.

Easy Integration with Azure Services

Azure WAF is not a standalone product—it is a feature of two Azure services: Application Gateway (regional, layer‑7 load balancer) and Azure Front Door (global, HTTP‑based CDN and load balancer). This tight integration means you can enable WAF on an existing gateway or front door with a few clicks. The WAF policy can be shared across multiple listeners and back‑end pools, reducing management overhead. For hybrid or multi‑cloud setups, you can pair Azure Front Door with third‑party origins and still benefit from WAF protection at the edge.

How Azure WAF Works

When a request arrives at the Application Gateway or Front Door endpoint, the WAF engine performs a series of inspections:

  1. Request normalization – The engine decodes the request (URL decoding, handling of null bytes) to prevent evasion techniques.
  2. Rule evaluation – It checks the request against the enabled rule groups (SQLi, XSS, PHP attacks, etc.) in the order of rule priority.
  3. Anomaly scoring – If you use the anomaly scoring mode, each rule violation increments a score. If the total exceeds a threshold (default 5), the request is blocked. Otherwise, it may only be logged.
  4. Custom rule evaluation – Custom rules are evaluated last, allowing you to override managed rules or add additional logic.
  5. Action execution – Depending on the combined outcome, the request is allowed, blocked (with a 403 response), or logged for later analysis.

This pipeline runs in milliseconds, adding negligible latency. For applications that handle file uploads, WAF can inspect the request body up to a configurable size (128 KB by default, adjustable). If a request exceeds that size, it can be rejected or inspected partially.

Enabling Azure WAF

Setting up Azure WAF is straightforward, whether you are deploying a new gateway or retrofitting an existing one. Below is an expanded walkthrough.

Step 1: Create an Azure Application Gateway or Enable Front Door

In the Azure Portal, search for “Application Gateway” and click “Create”. You will need a virtual network, a subnet dedicated to the gateway, and a public IP address. During the creation wizard, you will be asked to enable WAF. Alternatively, if you already have an Application Gateway, go to its Web Application Firewall blade and attach a WAF policy. For global distribution, use Azure Front Door – it offers the same WAF capabilities at the network edge.

Step 2: Configure the WAF Policy

A WAF policy contains the managed rule sets, custom rules, and global settings (mode, request body inspection, exclusions). You can create a policy within the gateway creation flow or as a standalone resource. Standalone policies are reusable—apply the same policy to multiple Application Gateways or Front Door profiles. Key configuration points:

  • Mode: Choose Detection (log only) or Prevention (block). Start with Detection to see what rules trigger without disrupting users.
  • Managed rule sets: Select the version (e.g., Microsoft_DefaultRuleSet_2.1 or OWASP_3.2). You can enable or disable individual rules.
  • Exclusions: If your application sends legitimate requests that contain patterns matching a WAF rule (e.g., a text editor that uses HTML tags), you can exclude specific request attributes (headers, cookies, request body) from inspection.
  • Custom rules: Add IP whitelist, geo‑block, or URI‑specific rules.

Step 3: Associate the Policy with the Gateway or Front Door

Link the WAF policy to the Application Gateway’s HTTP settings or listener. For Front Door, associate the policy with the frontend host or the route. After association, traffic is inspected immediately.

Step 4: Test in a Staging Environment

Before moving to production, deploy a test instance and run a set of known attack payloads (SQLi, XSS) against it. Use tools like OWASP ZAP or custom curl scripts. Check the WAF logs to see if the attacks are correctly matched. Adjust exclusion rules if false positives occur.

Integration Options: Application Gateway vs. Front Door

Azure Application Gateway (Regional)

Application Gateway is a regional load balancer that operates at Layer 7. It terminates TLS, routes traffic to back‑end pools, and provides session affinity and URL‑based routing. When you attach a WAF policy to an Application Gateway, the inspection happens inside the regional Azure data center. This is ideal for applications that:

  • Are hosted entirely in one Azure region.
  • Require low‑latency traffic inspection within the same data center.
  • Need to offload SSL termination and integrate with back‑end health probes.

Azure Front Door (Global)

Azure Front Door is a global HTTP load balancer with built‑in CDN capabilities. It routes traffic to the fastest back‑end and can accelerate dynamic content. WAF policies on Front Door are evaluated at Microsoft’s edge locations before the request reaches your origin. Advantages include:

  • Protection against DDoS and malicious traffic at the network edge, reducing load on your origin servers.
  • Global distribution with the same security rules applied worldwide.
  • Native integration with Azure App Service, storage, or any public HTTP endpoint.

Both platforms use the same WAF engine and managed rule sets. Your choice depends on whether you need regional or global traffic management.

Security Policies and Rule Groups

Azure WAF uses rule groups to organize related signatures. The OWASP rule set includes groups such as REQUEST‑920‑PROTOCOL‑ENFORCEMENT, REQUEST‑930‑APPLICATION‑ATTACK‑LFI, and REQUEST‑942‑APPLICATION‑ATTACK‑SQLI. Each group contains individual rules that can be enabled or disabled. In a tiered setup, you might disable the more aggressive anomaly‑scoring rules in detection mode and then incrementally enable them after false positives are addressed.

The newer Microsoft managed rule set (DRS) introduces a simpler structure with predefined rule groups (e.g., SQLI, XSS, PHP Attacks) and a severity field. It also includes a bot protection rule group that identifies good bots (search engine crawlers) and bad bots (scrapers). The DRS is recommended for new deployments because its anomaly scoring model reduces false positives compared to the older OWASP rule set.

Custom rules are evaluated after the managed rules. You can use them to:

  • Create geo‑block lists (e.g., block all countries except the US and Canada).
  • Rate‑limit requests from a single IP (useful for API endpoints).
  • Allow specific user agents like “Googlebot” while blocking others.
  • Intercept requests containing particular HTTP headers (e.g., block uploads with certain MIME types).

Monitoring and Logging with Azure Monitor

Without proper observability, a WAF is just a black box. Azure WAF logs are categorized into two main channels:

  • WAF logs: Contains per‑request decisions (allow/block) and matched rule IDs.
  • Activity logs: Shows administrative actions like policy modifications.

To enable diagnostics, go to the Application Gateway or Front Door resource, select “Diagnostic settings”, and route the logs to a Log Analytics workspace. Below are some practical queries you can run:

// Count blocked requests by rule type
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK" and rulesMatched contains "blocked"
| project TimeGenerated, ruleId = extractjson("$.rulesMatched[0].ruleId", tostring(rulesMatched))
| summarize BlockedCount = count() by ruleId
| top 10 by BlockedCount desc

Integrating with Microsoft Sentinel enables automated incident response. For example, create a Sentinel analytics rule that triggers an investigation when the same IP triggers more than 5 SQL injection alerts in an hour. The Log Analytics workspace also powers dashboards and custom alerts.

Optimizing and Tuning Azure WAF

False positives—legitimate traffic incorrectly flagged as malicious—are the most common challenge with any WAF. Tuning is an ongoing process:

  1. Start in Detection mode for at least one week to collect baseline traffic.
  2. Analyze the logs to identify patterns of false positives. For example, a forum application may send HTML in POST body that triggers the XSS rule.
  3. Add exclusions for specific request attributes. You can exclude a header, cookie, or a request body argument by name or pattern.
  4. If a managed rule is consistently problematic, disable it entirely—but be aware of the security gap.
  5. Use custom rules with a “log” action to test a new rule before switching to “block”.
  6. Revisit exclusions and disabled rules after every application update.

For highly dynamic applications (e.g., SPAs or GraphQL endpoints), consider enabling request body inspection only if needed, and fine‑tune the maximum body size. Also, use the rate limiting feature (available via custom rules) to mitigate brute‑force attacks on login endpoints without blocking legitimate users.

Cost Considerations

Azure WAF pricing is tied to the underlying service. For Application Gateway, you are billed based on gateway SKU (V2) plus a per‑hour WAF surcharge. For Front Door, there is a per‑profile fee plus a small per‑request cost for WAF inspection. The managed rule set licensing is included—no additional per‑rule fee. For most enterprise workloads, the cost is modest compared to the potential damage of a successful attack. Check the Azure WAF pricing page for the latest figures.

Real‑World Use Cases

  • E‑commerce platform: Combine Azure Front Door’s CDN with WAF to protect against credit card skimming scripts and DDoS. Custom rules block scraping bots that try to harvest product data.
  • Healthcare portal: Use WAF to prevent SQL injection attempts that could expose patient records. Enable anomaly scoring to catch subtle variations of known attacks.
  • Financial API gateway: Apply rate‑limiting custom rules on API endpoints to prevent brute‑force token theft. Use geo‑filtering to deny traffic from non‑authorized regions.
  • SaaS application: Run a shared Application Gateway with a single WAF policy applied to all tenants. Tenant‑specific exceptions are handled via custom rules that check the Host header.

Common Pitfalls to Avoid

  • Skipping detection mode: Going straight to “prevention” mode often leads to immediate user complaints. Always tune in detection first.
  • Ignoring log retention: WAF logs are only useful if you store them. Configure a retention policy of 90–365 days in Log Analytics.
  • Overly broad exclusions: Excluding an entire header (e.g., “Cookie”) weakens security. Use narrow patterns like “Cookie: sessionId=...”
  • Neglecting rule updates: Managed rule sets are updated monthly. Check the “What’s new” notifications on the Azure portal to review changes.
  • Not testing with automation: Use CI/CD pipelines to deploy WAF policy changes. Manual edits in the portal are error‑prone and unrepeatable.

Automating WAF Configuration

Infrastructure‑as‑code (IaC) ensures that WAF policies are version‑controlled and deployable across environments. ARM templates, Bicep, and Terraform all support WAF policy resources. Example snippet in Bicep:

resource wafPolicy 'Microsoft.Network/applicationGatewayWebApplicationFirewallPolicies@2022-01-01' = {
  name: 'myWafPolicy'
  location: resourceGroup().location
  properties: {
    managedRules: {
      managedRuleSets: [
        {
          ruleSetType: 'Microsoft_DefaultRuleSet'
          ruleSetVersion: '2.1'
        }
      ]
    }
    policySettings: {
      mode: 'Detection'
    }
  }
}

Use the Azure CLI or PowerShell to quickly enable WAF on existing resources during incident response. Scripting also helps apply uniform policies across multiple subscriptions.

Conclusion

Azure Web Application Firewall is a powerful, cost‑effective way to fortify your web applications against the most common and advanced threats. By combining managed rule sets, custom rules, and real‑time monitoring, you can significantly reduce your attack surface. The key to success lies in thoughtful configuration—tune for false positives, integrate with logging and analytics, and treat WAF policy as a living artifact that evolves with your application. Start with detection mode, analyse your traffic, then gradually shift to prevention. With Azure WAF, you gain not only protection but also visibility into the threat landscape targeting your digital assets.