6.4 Web Application Firewall on Azure Front Door

Web Application Firewall on Azure Front Door

The AZ-700 security objective asks you to configure rule sets for WAF on Azure Front Door and, separately, for WAF on Application Gateway. They share a name and an OWASP heritage, but they differ in tier gating, rule set versions, and association model — and the exam tests exactly those differences.

[!IMPORTANT] The tier gate is the single most tested Front Door WAF fact. Azure WAF is natively integrated with Front Door Premium with full capabilities; for Front Door Standard, only custom rules are supported. Any scenario requiring managed OWASP protection, Microsoft Threat Intelligence rules, or bot protection at the edge requires Premium.

---

1. WAF Policy Structure

A Front Door WAF policy contains two kinds of security rules:

1. Custom rules that you author.
2. Managed rule sets — Azure-maintained collections of preconfigured rules.

When both are present, custom rules are processed first, then the managed rule set. Custom rule actions are Allow, Block, Log, and Redirect. This ordering is what makes a custom allow-list rule an effective way to bypass a managed rule that produces a false positive for a known-good source.

Modes

---

2. Anomaly Scoring — DRS 2.0 and Later

DRS versions 2.0 and above use anomaly scoring. A rule match does not block the request on its own, even in Prevention mode. Instead each rule carries a severity that contributes a numeric value to the request's anomaly score.

When a request accumulates an anomaly score of 5 or greater, the WAF takes the configured anomaly score action, which is one of Block, Log, or Redirect. The default anomaly score action is Block.

Working the arithmetic

• A single Critical match scores 5, which alone reaches the threshold and blocks in Prevention mode with the default action.
• A single Warning match scores 3 — not enough on its own. Two Warning matches score 6 and do reach the threshold.
• In Detection mode, a request scoring 5 or more is logged with the action blocked recorded by rule ID 949110 (Inbound Anomaly Score Exceeded) but is not actually blocked.

[!NOTE] Rule sets older than DRS 2.0 run in traditional mode, where a match on any single rule is evaluated independently and blocks the request. In traditional mode you have no visibility into the full set of rules a request matched, which is exactly why anomaly scoring was introduced.

---

3. Managed Rule Set Versions

All DRS versions include the Microsoft Threat Intelligence Collection rules, written in partnership with the Microsoft Threat Intelligence team to add coverage, patch specific vulnerabilities, and reduce false positives.

Paranoia levels

Every rule is assigned a Paranoia Level (PL).

• PL1 rules are less aggressive and rarely produce false positives; they provide baseline security with minimal tuning.
• PL2 rules detect more attacks but are expected to produce false positives that need tuning.
• DRS 2.2 is configured at PL1 by default, with all PL2 rules disabled. You enable PL2 rules manually when you want deeper inspection.
• DRS 2.1 and CRS 3.2 include PL2 rules enabled; to run strictly at PL1 you disable specific PL2 rules or set their action to Log.
• Paranoia Levels 3 and 4 are not supported in Azure WAF.

[!CAUTION] Changing rule set version in the portal resets your tuning. If you assign a new managed rule set through the Azure portal, all previous customisations — rule state, rule actions, and rule-level exclusions — are reset to the new rule set's defaults. Custom rules and policy settings survive. To preserve overrides and exclusions, make the version change with PowerShell, CLI, REST API, or a template.

---

4. A Safe Rollout Sequence

1. Create the WAF policy on a Premium profile and assign the current DRS in Detection mode.
2. Run for one to two weeks and analyse WAF logs for false positives — typically JSON payloads containing SQL-like keywords, or rich-text fields tripping XSS rules.
3. Add exclusions for the specific request attributes causing false positives, and add custom Allow rules ahead of the managed set for known-good sources.
4. Switch to Prevention mode with the anomaly score action set to Block.
5. Associate the policy with the Front Door domains that need it.
6. Layer Bot Manager and rate-limiting custom rules once the baseline is stable.

[!TIP] Front Door Premium also allows you to secure the origin with Azure Private Link, so the backend has no public IP at all. Edge WAF plus a Private Link origin is the reference zero-trust pattern: the only path to the application is through the inspected edge.