Older Cloudflare guides refer to selectable Low, Medium or High security levels. Current security behaviour uses an Always protected model, while Under Attack mode and specific security rules address defined situations. Do not follow obsolete level selectors that your dashboard no longer provides.
IN THIS ARTICLE
What you need before you begin
Identify the problem you need to solve: abusive requests, a false positive, an attack spike or a specific vulnerable path. Review security events and the Cloudflare plan’s available controls before changing broad settings.
01 Use Cloudflare’s current security controls instead of old security levels
- Open the intended zone’s Security area and inspect recent events for the affected hostname, path, action and rule.
- Use a supported WAF or custom rule for a clearly defined traffic pattern, keeping its scope narrow and testing legitimate requests.
- Use Under Attack only when an incident warrants its browser challenge behaviour. Consider a supported scoped configuration rule for selected paths instead of challenging every visitor.
- Retest login, checkout, webhooks and API clients after a change. Nonbrowser clients may not be able to complete an interstitial challenge.
- Review the effect and remove temporary incident settings when they are no longer required.
Confirm the expected result
Legitimate workflows should remain usable while the targeted unwanted traffic is handled as intended. Check actual event outcomes rather than assuming a higher-looking label always improves protection.
Can I still use the old threat score to build new security rules?
Do not build new rules around the retired threat-score behaviour, which no longer provides the old signal. If a rule blocks customers, inspect the matching condition and use a narrowly justified correction. Avoid globally bypassing security to solve one false positive.