Azure Front Door and Application Gateway WAF Security Guide: Origin Lockdown, WAF Policies and Private Link

An Azure web application firewall only protects traffic that passes through it, and many Azure estates leave the origin reachable directly, run the WAF policy in Detection mode, or never turn on the logs that would show either problem. Microsoft offers Azure Web Application Firewall on two platforms: Azure Front Door, the global edge and CDN service, and Azure Application Gateway, the regional layer 7 load balancer. This guide covers the customer-side settings that decide whether that design holds up: origin lockdown, managed rule sets and anomaly scoring, policy scope, request body inspection, rate limiting, Private Link, admin access and logging. It is written for cloud security engineers, platform teams and SOC analysts who run Azure workloads exposed to the internet.

This is an independent guide from NHI Mgmt Group, based on Microsoft's public documentation as of November 2026. It is not sponsored or reviewed by Microsoft. Product features change, so confirm settings against Microsoft's current documentation.

Key takeaways

• Lock the origin or the WAF is optional. Microsoft's own guidance is that an origin reachable without Front Door lets traffic skip the WAF and DDoS protection. Use Private Link on Front Door Premium, or combine the AzureFrontDoor.Backend service tag with an X-Azure-FDID header check, because neither of the last two is enough alone.
• Detection mode gives no protection. Both the Front Door and Application Gateway best practice pages say it plainly. Use Detection to tune, then move to Prevention with a date in the change plan.
• Anomaly scoring changes how you read logs. On Default Rule Set (DRS) 2.0 and later a single rule match does not block; the request is blocked when its anomaly score reaches 5. A Critical match scores 5 on its own, a Warning scores 3.
• Body inspection settings are security settings. On Application Gateway, request body inspection, the inspection limit in KB and the size enforcement toggles are configured separately. Turning enforcement off or lowering the inspection limit lets uninspected content through.
• The WAF policy is privileged configuration. Whoever can switch a policy to Detection, add an exclusion or detach it from a listener can remove your perimeter without touching the application. Treat WAF policy write access as privileged access with alerting.

Front Door and Application Gateway: where each WAF sits

The two services share the Azure WAF engine family and the same managed rule set naming, but they sit at different points in the path and have different feature sets.

• Edge only: suits global public sites and APIs whose origins are platform services such as App Service, Functions or Storage, reached through Private Link.
• Regional only: suits internal or regional applications, workloads that need path-level policy differences on one gateway, and designs where traffic must stay in one region for residency reasons.
• Both: common for large estates. Front Door handles global routing, bots and rate limits; Application Gateway applies per-application policy close to the workload. Decide which layer owns which rule, or you will tune every false positive twice.

Origin lockdown: stop traffic going around the WAF

Microsoft's origin security page lists four ways to make sure an origin only accepts traffic from your Front Door profile. They differ in tier and strength.

• Prefer Private Link on Premium: it keeps the origin off the public internet altogether, which removes the bypass rather than filtering it.
• For public origins use both checks together: App Service access restrictions can filter on the service tag and the X-Azure-FDID header without code changes. See the Azure App Service Security Guide.
• Edge token validation is not origin lockdown: the Premium authentication policy (public preview) validates Entra ID JWTs at the edge, but a client that finds the origin can still skip it.
• Application Gateway behind Front Door: lock the gateway listener the same way, so the regional WAF is not a second public entry point with a weaker policy. NSG rules on the gateway subnet must still allow GatewayManager on TCP 65200 to 65535 and the AzureLoadBalancer tag, or the gateway breaks. See the Azure Virtual Network Security Guide.

WAF policies, rule sets and anomaly scoring

A WAF policy holds managed rules, custom rules, exclusions and policy settings. On Application Gateway a policy can be associated at three scopes, and the most specific one wins: per-URI over per-site over global. A global policy still covers any listener or path without its own policy. Every per-site or per-URI policy is another place an exclusion can hide, so keep an inventory.

Older Application Gateway deployments may still hold settings in the legacy WAF configuration rather than a WAF policy. Microsoft's best practice is to migrate to WAF policies to get current features, and there is a built-in Azure Policy definition for that migration.

Managed rule sets

• Use DRS 2.2 where it is available: it is based on OWASP CRS 3.3.4 with 18 rule groups and is Microsoft's recommended version on Application Gateway. Customers on DRS 2.1, CRS 3.2 or CRS 3.1 are advised to upgrade. CRS 3.1 and 3.0 have a support end date set, and CRS 2.2.9 is no longer supported.
• Know the scoring: severities contribute Critical 5, Error 4, Warning 3, Notice 2. The threshold is 5. In the Front Door log, rule 949110 "Inbound Anomaly Score Exceeded" marks the request that crossed it, and the contributing rules show the action AnomalyScoring.
• Paranoia level: DRS 2.2 runs Paranoia Level 1 by default with PL2 rules disabled. Enabling PL2 catches more attacks with more false positives; set PL2 rules to Log first, tune, then enforce. PL3 and PL4 are not supported.
• Upgrades reset customisations in the portal: changing the rule set version in the portal resets rule state, rule actions and rule-level exclusions. Change versions with PowerShell, CLI, REST or templates to carry overrides across, and test first.

Custom rules and exclusions

Custom rules run before managed rules, and a match ends evaluation. An Allow custom rule with a broad condition, such as a header value or a source range, therefore skips every managed rule for matching traffic. On Application Gateway with CRS 3.2 and later, high-priority custom rules on headers, cookies or URI are even evaluated before the size limits. Review Allow rules as carefully as firewall any-any rules. Exclusions can be set at rule set, rule group or rule level: prefer the narrowest, tied to a named request attribute.

Request body inspection and size limits

On Application Gateway WAF_v2 with CRS 3.2 or later, four settings that used to be one are now independent. Each is a security decision.

In Detection mode the WAF inspects up to the limit and ignores the rest, so an attacker can pad a body past the inspection depth.

Rate limiting, geo filtering and DDoS

• Front Door rate limits: set with rateLimitThreshold and rateLimitDurationInMinutes (1 or 5). The default grouping is SocketAddr, the address that opened the TCP connection to Front Door, which may be a proxy. Grouping by GeoLocation, Asn or Ja4 is in preview on Premium. Once a group exceeds the threshold, matching traffic is blocked for the rest of the fixed window.
• Expect some leakage at low thresholds: counters are kept per Front Door server, so a client that opens new connections can land on a server whose count is behind. Microsoft notes that below about 200 requests per minute some requests over the threshold can get through. Do not rely on a WAF rate limit as an exact quota; enforce strict quotas in the API layer.
• Set thresholds from data: Microsoft suggests a threshold about twice normal client behaviour (20 for a client that sends 10 requests a minute), and for grouped rules at least a week of normal peak traffic, starting with Log or a JavaScript challenge before Block.
• Geo filtering: if users are in known regions, block the rest with geomatch custom rules, but allow the unknown location ZZ so unmapped addresses are not blocked by accident.
• DDoS: the WAF handles layer 7 floods; network-layer protection for public IPs in your virtual network is a separate Azure DDoS Protection decision. See the DDoS Protection Guide.

Private Link and network isolation

Private Link appears twice in these designs, in opposite directions:

• Front Door to origin (Premium): Front Door connects to the origin through a private endpoint that the origin owner approves. Approve only connection requests you expect, then disable public network access on the origin.
• Consumers to Application Gateway: a private link configuration attached to a gateway frontend IP lets clients in other virtual networks, subscriptions or tenants reach the gateway through a private endpoint. The private link configuration needs its own subnet, separate from the gateway subnet. Connections can be auto-approved, manually approved or rejected: use manual approval for anything outside your tenant.
• Identify private traffic: for HTTP and HTTPS, Application Gateway sends X-Azure-PrivateEndpoint-ID to the backend and logs the same value as LinkId. Use it to tell which consumer endpoint a request came from.
• DNS: creating the private endpoint does not create a privatelink DNS record, so add records to the zones clients use.

Where identity fits: who can change the WAF

An attacker who holds a cloud account with write access to the network resource group does not need an exploit to get past the WAF. Switching the policy to Detection, adding a broad exclusion or Allow rule, detaching the policy from a listener or editing an NSG to expose the origin all work. This is ATT&CK T1685 Disable or Modify Tools carried out through T1078.004 Cloud Accounts.

Broad built-in roles such as Contributor and Network Contributor on the resource group include the ability to change these resources, so scope them tightly. Use Azure Policy with Deny effects for WAF enabled and Prevention mode on production, so even a privileged mistake is caught. See the Azure RBAC and Service Principals Guide and the Azure Managed Identities Security Guide for the pipeline identity and the Front Door managed identity used for origin authentication.

Logging, detection and metrics

Front Door access, health probe and WAF logs are not enabled by default; Application Gateway access and firewall logs are also enabled per gateway through diagnostic settings. Send them to a Log Analytics workspace and, through the Azure WAF connector, to Microsoft Sentinel or another SIEM. Matched values are logged in plain text, so add exclusions or log scrubbing for fields such as passwords and tokens.

• Front Door WAF log fields: action, ruleName, policy, policyMode, trackingReference (also returned to the client in X-Azure-Ref, which makes false positive tickets easy to trace), clientIP taken from X-Forwarded-For if present, and socketIP from the TCP session. Rate limit and block decisions are based on the socket address, so investigate with socketIP.
• Application Gateway firewall log fields: ruleId, ruleGroup, action (Detected in Detection mode; Allowed, Blocked or Matched in Prevention mode), transactionId to group all matches for one request, and policyScope and policyScopeName to show which policy applied.

Metrics that show the control is working:

• Coverage: share of internet-facing Front Door endpoints and Application Gateway listeners with a WAF policy and logs flowing (target 100%).
• Enforcement: share of policies in Prevention mode, and the age of any policy still in Detection.
• Origin exposure: number of origins reachable without Front Door, found by external scans of origin hostnames and public IPs (target zero).
• Rule set currency: share of policies on DRS 2.2, and days since Microsoft's latest version was available.
• Exclusion debt: count of exclusions and Allow custom rules, each with an owner and review date.

Phased rollout

1. Inventory: list every Front Door profile, Application Gateway, listener and origin. Flag Front Door classic profiles for migration before 31 March 2027, and Application Gateway deployments still on legacy WAF configuration.
2. Assign Azure Policy in Audit: WAF enabled, specified mode, request body inspection, resource logs, and the Premium tier definition for Front Door.
3. Turn on logging everywhere: diagnostic settings for WAF and access logs to a central workspace before any tuning.
4. Deploy DRS 2.2 and Bot Manager in Detection: as code, per application, for one to two weeks of representative traffic.
5. Tune: fix false positives with the narrowest exclusion, record each with an owner, and avoid broad Allow rules.
6. Lock the origins: Private Link on Premium, or service tag plus X-Azure-FDID; test that direct requests fail from outside.
7. Switch to Prevention by ring: low-risk apps first, then customer-facing ones. Rollback is a policy mode change back to Detection or a single rule set to Log, done through the pipeline and logged.
8. Add rate limits and geo rules: start with Log or JavaScript challenge, then Block once thresholds are confirmed.
9. Move Azure Policy to Deny for production: once compliant, block new non-compliant gateways and profiles.

Common failure patterns

• The origin answers the internet directly: the WAF is in place, but the App Service default hostname or the gateway's public IP still serves the app.
• Detection mode left in production: a policy created for tuning is never switched, and dashboards show "Detected" counts that look like protection.
• Customisations lost on upgrade: a portal rule set upgrade silently resets exclusions and overrides.
• Broad Allow custom rule: an Allow rule for a partner's header or IP range bypasses all managed rules for any request that carries it.
• Body inspection weakened for performance: the inspection limit is lowered or enforcement turned off to stop large-upload errors across the whole gateway, instead of a per-URI policy for the upload path.

Framework mapping

Practitioner checklist

• Every internet-facing origin accepts traffic only through Private Link, or through the AzureFrontDoor.Backend service tag plus an X-Azure-FDID check.
• Every production WAF policy is in Prevention mode, enforced by Azure Policy with a Deny effect.
• Policies use DRS 2.2 where available and Bot Manager 1.1, managed as code so upgrades keep overrides.
• Request body inspection is on with the maximum inspection limit; size enforcement is on, with per-URI exceptions for upload paths.
• Rate limit rules exist for sign-in and expensive API paths, with thresholds set from at least a week of traffic data.
• Each exclusion and Allow custom rule has an owner, a reason and a review date.
• WAF and access logs from every profile and gateway reach the SIEM, with sensitive fields excluded from logging.
• WAF policy write access is limited to a PIM-eligible group and a scoped pipeline identity, with alerts on policy mode, association and NSG changes.
• Front Door classic profiles have a dated migration plan before 31 March 2027.

Standards and references

• Microsoft Learn: Secure traffic to Azure Front Door origins
• Microsoft Learn: Azure WAF DRS rule groups and rules on Azure Front Door
• Microsoft Learn: Application Gateway WAF DRS and CRS rule groups and rules
• Microsoft Learn: Application Gateway WAF request and file upload size limits
• Microsoft Learn: Rate limiting for Azure Front Door WAF
• Microsoft Learn: Azure WAF policy overview for Application Gateway
• Microsoft Learn: Application Gateway Private Link
• Microsoft Learn: Azure Web Application Firewall and Azure Policy

Related NHI Mgmt Group resources: Securing the web application firewall (WAF) itself · Web application firewall (WAF) health check · Microsoft Azure Security Guide · Azure API Management Security · Azure Policy and Management Groups Guide