Web application firewall (WAF)
A managed web application firewall runs at every point of presence. It screens requests before anything is forwarded to the origin, it is on for every tenant, and there is nothing to install or configure.
What it screens for
- Common web attacks. Requests are matched against a managed rule set covering the well-known injection classes — SQL injection, cross-site scripting, path traversal, and the rest — and blocked at the point of presence rather than at the origin.
- Bots and abuse. Automated and abusive sources, and addresses with a known-bad reputation, are blocked. The reputation data is kept current for you.
- Rate limiting. A client making requests against the same URL faster than a real client would is throttled, and one producing a sustained abusive pattern is blocked for a period. See DDoS mitigation.
Because all of this runs at the point of presence, it happens close to the client and adds no meaningful latency to a request that passes.
What it covers
The firewall runs on the machines that front domains you have pointed at the edge — your storefronts and your /cdn/ asset paths.
api.revenexx.com is answered by the origin and is not behind a point of presence, so it is not behind this firewall. The API's protection is authentication plus the per-tenant rate limit. Do not read "the WAF covers everything" into this page — it covers the edge-terminated hostnames, which is where untrusted browser traffic arrives.
When it blocks something it should not
The rule set is tuned conservatively, but any managed rule set produces false positives eventually. A request that a rule matches gets a 403; a request that trips rate limiting gets a 429.
The pattern most likely to trip a rule is a legitimate payload that looks like an injection attempt — a product description containing SQL-like text, a rich-text field carrying markup, a filter expression with unusual punctuation. If you are building something that posts free-form content through an edge-terminated domain, test it before a customer finds it.
To get an exception, contact us with the X-Request-ID from the blocked response, the URL, and roughly what the payload looked like. That is enough to find the rule that matched and to scope an exception to your integration rather than turning a rule off for everyone.
Related
- DDoS mitigation — the flood handling on the same machines
- Edge network — which hostnames run behind a point of presence
- Rate limits — the API gateway's own budget