How do you keep up with web attacks you've never seen before?
New CVEs in popular frameworks (Spring4Shell, Log4Shell, MOVEit, ...) appear with little warning, and exploitation begins within hours. Your application can be patched in days — but in the meantime every request is a roll of the dice. On top of that, custom-built apps have their own logic flaws that no patch will ever fix, and they're constantly targeted by SQLi, XSS, and command-injection payloads.
How it fits together
How Cloudflare solves it
- Cloudflare Managed Ruleset. Continuously updated rules that block known exploitation patterns: SQLi, XSS, RCE, LFI, command injection, and emerging CVEs. Cloudflare's security team ships new mitigations the same day a public PoC drops.
- OWASP Core Ruleset. The industry-standard ModSecurity-style ruleset, tuned and curated by Cloudflare. Set per-domain sensitivity (low / medium / high) and choose between paranoia levels.
- Custom rules in a familiar language. Write rules in Cloudflare's rules expression language (e.g. <code>http.request.uri.path contains "/admin" and ip.geoip.country ne "US"</code>) and apply block, challenge, log, or skip actions.
- Test before you enforce. Every ruleset and rule supports log-only mode. Deploy globally, watch the analytics for false positives, then flip to block once you're confident. Zero-downtime tuning.
- Exception handling and bypass. Whitelist trusted IPs, internal QA traffic, or specific URLs from individual rules. Fine-grained enough to allow legitimate `SELECT` statements in your marketing CMS without disabling SQLi protection elsewhere.
Common questions
What happens when there's a new zero-day like Log4Shell?
Will the WAF break my legitimate traffic?
Can I write rules that combine multiple signals (IP + path + header)?
Does the WAF inspect request bodies?
Try it live
Fire real attack payloads against /api/waf/testattack. Cloudflare WAF rules configured on the demo zone evaluate each request — successful blocks return 403 and never reach the Worker. Unblocked attacks reach the Worker and return the simulated exploit data.
Pick an attack. The request goes to
/api/waf/testattack?type=<attack>.
A properly-tuned WAF rule on this zone will block it before the Worker
ever sees the request — you'll get a 403 challenge or block page.
If the rule misses, the Worker returns simulated exploit data showing
what an attacker would have gotten.