Cloudflare WAF and DDoS: what actually needs a custom rule
Managed rulesets stop generic attacks. What they miss is specific to you: the endpoint that looks like an attack to a rule and like Tuesday to your traffic.
Cloudflare's managed WAF rulesets block the well-known attack patterns the moment they are turned on: SQL injection, cross-site scripting, the OWASP top ten, all covered out of the box. That is the floor, and it is a real floor. It is also not the whole job.
The gap is whatever is specific to your application: the internal API endpoint whose payload shape looks unusual to a generic rule and is completely ordinary for that one integration, the login flow that needs its own rate limit because the managed default was tuned for the average site, not yours.
Managed rules are the floor, not the ceiling
| Situation | Managed ruleset | What actually closes the gap |
|---|---|---|
| A generic SQL injection or XSS attempt | Blocks it | Nothing else needed |
| An internal API with an unusual but legitimate payload shape | Can false-positive | A custom rule scoped to that one path |
| A login endpoint under credential stuffing | Partially covered | A rate limit tuned to your real login volume, not a default |
| A specific bot pattern hitting checkout | Bot Management scores it | A custom rule that acts on the score, not just logs it |
The middle two rows are where most of the actual work lives, and they are exactly the rows a default configuration skips, because a default cannot know what your login volume or your internal API traffic actually looks like.
DDoS protection is always on; the false positive is the real risk
Cloudflare's DDoS protection runs at layers 3, 4, and 7, always on, with no configuration required to get the baseline. The risk that remains is not an attack getting through, it is a rate-limiting rule tuned during a quiet month mistaking a real traffic spike, a product launch, a marketing campaign that actually worked, for an attack and blocking it.
Where this actually gets implemented
Getting this right is less about knowing Cloudflare's product list and more about knowing your own traffic well enough to write the two or three rules that matter, and leaving the rest to the managed baseline instead of over-configuring rules that fight each other.
We implement WAF and DDoS configuration as part of our Cloudflare implementation practice, with the same discipline we bring to any engineering engagement: a traffic review before a single rule changes, not a template applied blind. How we handle security in our own delivery, including under a signed BAA when health data is involved, is in our security practices.
Check your own case
Where does your team stand on this?
The article describes the pattern. These take your answers and tell you which part applies to you — no signup to see the result.