Web application firewall
Apply managed rule sets, test exclusions, handle TLS inspection, and recover rejected application traffic.
The web application firewall (WAF) evaluates supported HTTP requests against managed and customer-configured rules at the protected edge. It can inspect HTTPS only when the service terminates TLS at an inspection point; opaque transport passthrough does not expose HTTP bodies.
Stage a rule set
At Network protection → Policies → Edge policy → WAF, select a managed rule-set version and start in monitor mode. Choose explicit services and configure rule actions. Managed rule-set versions are recorded in each event. Review available updates at WAF → Updates, preview them on representative traffic, and publish through the policy workflow.
Actions are monitor or block. An exclusion targets a named rule and match condition; it does not create an organization-wide bypass. Blocked HTTP requests receive 403 with the service's request reference. Sensitive matched payloads are masked in ordinary event views.
Match and inspection limits
Review Service → Inspection capabilities for content types, maximum inspected body size, decompression support, and protocol limitations. Requests exceeding inspection limits use the configured oversized-body action; do not assume that an uninspected body passed inspection. Enable a restrictive oversized-body rule only after testing legitimate uploads.
Rules evaluate the parsed request observed at the edge. The origin might interpret encodings or duplicate parameters differently. Use application validation and parameterized database access alongside WAF policies. Guard does not remove a vulnerable code path from the application.
Diagnose an application rejection
Open Network protection → Events → Event using the request reference. Compare service ID, route, rule ID, rule-set version, action, and client identity. Reproduce with a benign request in the pilot service. Create a narrowly scoped exclusion at WAF → Exclusions → Add exclusion, give it an owner, reason, and expiry, and publish a new revision.
Verify the request succeeds and unrelated attack tests still match the intended controls. If the update causes widespread rejections, create a new draft from the previous policy revision and publish it. Check adoption before declaring recovery. Historical matches remain attached to the old revision. See exceptions and Policy API.