Cloudflare Security Level explained

What Security Level does

The Security Level decides how aggressively Cloudflare presents a challenge to a visitor whose traffic it considers suspicious. It is a blunt, reputation-based filter applied to the whole zone unless a rule narrows it. The setting lives under Security > Settings, exposes the strings essentially_off, low, medium, high and under_attack, and defaults to medium.

The levels and their intent

• Essentially off. Only the most severe offenders are challenged. Intended for zones that expect very little bad traffic and want a frictionless visitor path.
• Low. Challenges only the most threatening visitors.
• Medium. The default. Challenges both moderately threatening and more severely rated visitors.
• High. Challenges every visitor that shows any suspicious behaviour. Use with care, because false positives surface as real users being challenged.
• I'm Under Attack. Every visitor is presented a managed challenge (a JavaScript interstitial). It is heavy and is only for an active layer-7 DDoS attack, not for normal operation.

The threat score retcon

Enough older material cites a threat-score threshold per level (such as medium challenging scores above 14) that it is worth being precise: the score behind those numbers is legacy. Cloudflare's current documentation states that the threat score is always reported as 0 and that rules built on it are no longer recommended. The levels still describe behavioural tiers in the dashboard, but the reproducible, machine-checkable signal you can build a rule on is not the old score. For that you use explicit controls: the managed rulesets, custom WAF rules, or rate limiting, which match on conditions you can see and test rather than an internal reputation number.

Scoping I'm Under Attack correctly

Because Under Attack challenges all traffic, leaving it on globally for normal operation makes automated consumers your API depends on (see client origins) hit challenges and fail. The recommended pattern:

1. Enable Under Attack only while the attack is active.
2. Scope it with a configuration rule to the paths under attack (for example example.com/api/*), not the whole zone, when only that surface is targeted.
3. Off elsewhere, keep rate limiting handling abuse without the full interstitial.
4. When the attack subsides, lower to medium or add precise WAF rules and monitor the events log.

Decision summary

• Normal traffic: medium (the default) is almost always right.
• A quiet zone that wants zero friction: low or essentially off.
• A targeted path under active attack: Under Attack mode, scoped with a configuration rule, switched off once the traffic normalizes.
• Any rule you need to reason about later: build it on explicit WAF conditions and rate limits, not on the legacy threat score.

The Security Level is a useful first line, not a place to encode sophisticated policy. Keep it at a sane default and put your real, testable filtering in WAF rules and rate limiting, which respond to events you can see instead of a score that no longer moves.