Azure Web Application Firewall
Azure Web Application Firewall (WAF) inspects HTTP requests at the edge and blocks the ones that match its rules. On the Azure platform the Azure Enterprise Baseline owns the rule template, and the Web App Blueprint turns it into the Azure Front Door WAF policy of each stage.
What it does
A WAF policy on Azure Front Door holds custom rules (match conditions on the request, such as a URI, header or client address, or a rate limit per client) and managed rule sets maintained by Microsoft: the Default Rule Set, which covers the OWASP (Open Worldwide Application Security Project) attack classes such as SQL injection and cross-site scripting, and the Bot Manager rule set. The policy runs in Prevention mode, which blocks matches, or Detection mode, which only logs them. A security policy attaches it to Front Door domains. Custom rules work on the Standard and Premium Front Door SKUs; managed rule sets need Premium.
How BuiltForProd uses it
The template. The Baseline keeps one template at policies/waf-template.json:
{
"custom_rules": [
{
"name": "RateLimitPerClient",
"priority": 100,
"type": "RateLimitRule",
"action": "Block",
"rate_limit_duration_in_minutes": 1,
"rate_limit_threshold": 1000,
"match_conditions": [
{ "match_variable": "RequestUri", "operator": "Contains", "negate": false, "match_values": ["/"] }
]
}
],
"managed_rules": { "drs_version": "2.1", "bot_version": "1.1" }
}
One custom rule blocks a client that sends more than 1,000 requests in a minute, and the managed rule sets are pinned to Default Rule Set 2.1 and Bot Manager 1.1. The kv-publish unit publishes the file into every stage's contract vault as the secret waf--policy-template, so each stage carries the same rules. Under CODEOWNERS, /policies/ needs a review from the infra admins and the security team.
The policy. The Web App Blueprint's front-door unit reads the template from the contract vault and builds azurerm_cdn_frontdoor_firewall_policy (modules/front-door/waf.tf), named wafacme<environment><stage>, such as wafacmeeus2prd:
| Setting | Value |
|---|---|
| Mode | Prevention in every stage (waf_mode; Detection is an option to observe first) |
| Custom rules | Every rule of the template |
| Managed rules | Default Rule Set and Bot Manager, action Block, on the Premium SKU only |
| SKU | The stage's Front Door SKU: Standard_AzureFrontDoor in dev, Premium_AzureFrontDoor in staging and prod |
| Attached to | Both custom domains, blueprint-app.<stage>.<domain> and blueprint-api.<stage>.<domain>, for every path |
So dev enforces the rate limit only, and staging and prod enforce the rate limit and both managed rule sets. A change to the template reaches the stages through the Baseline's pipeline (the contract secret) and then each stage's Front Door plan.
At the network layer, Front Door's edge carries its own DDoS protection, and Azure DDoS Protection covers public IPs inside the virtual networks when it is switched on.
Terms you will see
| Term | Meaning |
|---|---|
| WAF policy | The set of custom and managed rules and the mode, attached to Front Door domains. |
| Custom rule | A rule written in the template, here a per-client rate limit. |
| Managed rule set | Microsoft-maintained rules: the Default Rule Set and the Bot Manager rule set. |
| Prevention mode | Matching requests are blocked; Detection mode only logs them. |
| Security policy | The Front Door object that binds a WAF policy to domains and paths. |
waf--policy-template | The contract secret that carries the template to each stage. |
Where to read more
- Azure Web App Blueprint overview for the Front Door entry point and its two endpoints.
- Azure Enterprise Baseline overview for the contract vault that carries the template.
- Defense in depth for how the edge layers with the network and identity controls.