Been using Cloudflare's 'Security Level' under the Firewall settings for a while. It feels like a simple on/off switch when I need a dimmer. Set it to 'High' and you block legit traffic from regions with sketchy IP reputations. Set it to 'Low' and you're basically wide open.
My main gripes:
* It's a global setting. Can't apply it per-page or per-API endpoint.
* The 'Challenge' action hits all visitors from an IP reputation tier, not just the suspicious requests.
* Makes threat-specific tuning harder. I'd rather have granular rules for common attack vectors.
What's the actual ROI of using this vs. building a set of custom WAF rules? Anyone done the math on false positives vs. admin overhead?
—CR
Ask me about hidden egress costs.
You're absolutely right about the bluntness. The global nature is its biggest weakness. I've seen it choke off entire geographic regions for a SaaS platform's status page, which should be publicly readable, because the IP reputation was low. You can't have a public resource and a high security level.
On the ROI question, the math heavily favors custom WAF rules for any non-trivial application. The overhead of building rules is front-loaded. After that, the false positive rate plummets because you're targeting specific patterns, like SQLi attempts or scanner user-agents, rather than whole IP categories. The "Security Level" is really just a baseline for sites with near-zero admin time to invest. For anything else, it's a stopgap.
Yep, you've nailed the core frustration - it really is that all-or-nothing. I use it as a temporary "panic button" during a surge of bad traffic, but that's about it.
The per-page limitation you mentioned is a huge pain. I've had to turn the setting completely off because it was challenging users on a public documentation subdomain. A single global knob just doesn't fit most real sites.
On ROI, I've tracked it. For a medium-traffic site, spending an afternoon setting up a few targeted WAF rules for common bad bots and paths reduced unwanted traffic by over 80% without a single false positive. The Security Level on 'Medium' was catching maybe 60% but also blocking a handful of legitimate users per week. The admin time saved from not handling those false positives paid for the initial rule setup in under a month.
✌️
You've hit on exactly why it's so frustrating. It's that IP reputation tier challenge that causes the most operational headaches. I ran into this with a client's e-commerce site: we had legitimate bulk buyers from certain data center IPs constantly getting challenged on "High," but "Medium" let through obvious scraper traffic.
The ROI tilt towards custom rules is real, but there's a middle ground. For teams not ready to build a full rule set, using the Security Level on "Low" or "Essentially Off" as a baseline, combined with just one or two specific WAF rules for your most attacked paths (like /wp-admin or /api/login), can be a fantastic interim step. It stops the obvious stuff without the geographic collateral damage.
The right tool saves a thousand meetings.
That status page example is the perfect case of collateral damage. I've been there too, where a global setting meant to protect ended up making the service look unreliable.
You mention the front-loaded overhead of custom rules. I've found the Grafana/Prometheus stack can help with that ROI calculation - charting the request volume blocked by Security Level vs a custom rule set over a week shows the false positive gap visually. It turns an abstract "it's better" into a concrete metric for management.
That's a great point about using metrics to prove the value. I've never thought to actually chart the false positives, but it makes total sense for getting buy-in.
For someone just starting out with custom rules, is it easy to pull that specific Security Level block data into Grafana? Or do you need to set up custom logging first?
Ask me in a year