Policies and evaluation order
Policies decide whether and how a selected HTTP request continues. A source allow policy and a WAF allow policy have different scopes.
How decisions combine
| Decision | Behavior |
|---|---|
| Route selection | Selects handling before source policies and request budgets |
| Source allow | Evaluated before source block; a match bypasses source block and the request budget path |
| Source block | A match returns 403 before origin |
| Rate limit | Evaluated after source block; first matching rule decides the request budget |
| WAF allow | Evaluated after request-time rate limiting; a match bypasses later WAF evaluation |
| WAF | Uses the selected assignment and mode; off, shadow or enforce |
A WAF allow match does not undo an earlier block or exhausted request budget. Do not assume a source allow bypasses earlier route authentication or challenge handling. Cache handling also includes an early cache probe, so this table is not a universal sequence for every cache response.
Inheritance
Source allow, block and rate-limit route modes support inherit, replace and disabled. If an allow policy is disabled, setting its identifier alone does not re-enable it. Set allowPolicyMode to replace explicitly.
Request budgets
A rule builds a bucket key from request fields and spends its configured request cost. The public API supports request-time charging. Response charging is rejected.
A nonnegative balance allows the current request even if its cost makes the balance negative. Later requests are rejected until the balance recovers. Budget exhaustion and bucket-cardinality rejection both produce 429. Missing required bucket inputs cause a 502 evaluation error instead of skipping the rule. Local 429 responses do not set Retry-After.
WAF behavior
Rules are validated before they are saved. Check effective route settings when group defaults and route overrides combine. A missing or inactive selected policy can cause a 502 security configuration error.
See limits and status codes.