Web Application Firewall on Front Door

A Web Application Firewall (WAF) inspects HTTP/HTTPS requests at Layer 7 and blocks known attack patterns before they reach your application. Common attacks it prevents include SQL injection, cross-site scripting (XSS), remote file inclusion, and protocol anomalies. Without a WAF, attackers can exploit vulnerabilities in your application code even if your network is correctly locked down. Azure WAF integrates with both Azure Front Door and Azure Application Gateway.

In Azure, a WAF policy is a standalone resource that contains managed rule sets and custom rules. You create the policy, configure rules, then associate it with one or more Front Door endpoints or Application Gateway instances. This decoupled design means one WAF policy can protect multiple Front Door endpoints — a single change to the policy propagates to all associated endpoints automatically. WAF policies exist in a specific Azure region but when attached to Front Door, protection is applied globally at all PoPs.

WAF policies operate in two modes. Detection mode inspects all requests and logs matches against rules but does not block any traffic — useful for initial deployment to understand what traffic your policy would block before enforcing it. Prevention mode both logs and actively blocks requests that match rule conditions. Best practice is to start in Detection mode, review the WAF logs for false positives, tune rules, then switch to Prevention mode once you are confident the policy is correct.

The Microsoft Default Rule Set (DRS) is a managed rule group maintained by Microsoft's security team. It contains rules detecting the OWASP Top 10 vulnerabilities plus bot signatures and credential-stuffing patterns. Microsoft continuously updates DRS with new rules in response to emerging threats — you do not need to write rules yourself. DRS versions are periodically released (e.g. DRS 2.1), and you can upgrade your WAF policy to a newer version during a maintenance window.

The OWASP Core Rule Set (CRS) is available on Application Gateway WAF and as part of the Verizon-tier CDN WAF. It contains over 200 rules covering the OWASP Top 10: injection attacks, broken authentication, sensitive data exposure, XML external entity attacks, and more. Each rule has an ID and group (e.g. REQUEST-942-APPLICATION-ATTACK-SQLI). You can disable individual rules by ID to suppress false positives without disabling the entire rule group.

Custom rules let you write specific allow/block conditions that managed rule sets do not cover. A custom rule consists of one or more match conditions (e.g. source IP, request URI, header value, query string) combined with an action (Allow, Block, Log, or Redirect). Custom rules are evaluated before managed rule sets and support priority ordering. A common use case: block specific countries, rate-limit aggressive crawlers, or whitelist a trusted monitoring IP bypassing WAF rules.

Rate limiting rules restrict the number of HTTP requests from a single client IP address within a time window (1 or 5 minutes). When the request count exceeds the threshold, the WAF returns HTTP 429 (Too Many Requests) to that client. Rate limiting is effective against brute-force login attacks, credential stuffing, and API abuse. You configure the request threshold and window as part of the custom rule definition in the WAF policy.

The Bot Manager rule set (available in Front Door Premium) classifies incoming traffic as good bots (verified search engine crawlers), bad bots (known scanners, vulnerability probes), and unknown bots (unclassified automated traffic). You can configure the action per category — allow good bots, block bad bots, and log unknown bots. Without bot protection, automated scanners can generate enormous traffic loads that inflate your costs and mask real user traffic in analytics.

Managed rule sets sometimes generate false positives — blocking legitimate requests because they happen to match a security rule pattern. For example, a CMS with rich text editing may send HTML in POST bodies that matches an XSS rule. WAF exclusions let you exclude specific request attributes (request headers, cookies, query string parameters, or request body fields) from rule evaluation, either globally or for a specific rule group or rule ID, without disabling the rule entirely.

WAF generates two types of log entries in Azure Monitor: WAF logs (every request that matched a rule, whether blocked or logged) and access logs (all requests including those that passed without matching any rule). Send these logs to a Log Analytics workspace and use KQL to query blocked request trends, identify top attacked endpoints, or investigate a specific client IP. The WAF Insights workbook in the portal provides pre-built dashboards visualising these logs.

To activate WAF protection, you must associate the WAF policy with your Front Door security profile. In the portal, navigate to your Front Door profile, select Security policies, and add the WAF policy, specifying which domains it applies to. Alternatively, use the CLI to link the policy. Once associated, the WAF inspects all HTTP/HTTPS requests arriving at those Front Door domains before routing them to origin. You can associate one WAF policy per domain.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: WAF policies contain managed rule sets (Microsoft DRS, OWASP) and custom rules that inspect HTTP traffic before it reaches your origin, Detection mode lets you tune rules before switching to Prevention mode, and rate limiting rules protect against brute-force and abuse. Next up we explore using Front Door's rules engine to optimise performance with redirects and security headers.