Cloudflare WAF managed rulesets explained

What a managed ruleset is

A managed ruleset is a preconfigured set of WAF rules that Cloudflare updates for you. You deploy a ruleset rather than writing individual rules, and it filters requests before your origin ever sees them. The WAF runs the rules and sends matching requests to an action, such as block, challenge, or log.

Cloudflare provides two families with genuinely different behaviour:

• Cloudflare Managed Ruleset: a signature-heavy engine tuned to false positives, updated frequently, and enriched by Cloudflare's global attack intelligence. It covers known attack techniques (SQL injection, XSS) and fast-tracked zero-day protections.
• Cloudflare OWASP Core Ruleset: an implementation of the OWASP ModSecurity Core Rule Set, scored instead of signature based. Every matching rule adds points to a cumulative threat score, and the WAF acts when the total passes your threshold.

The two overlap, and Cloudflare's own docs state that OWASP adds marginal protection on top of the managed ruleset while carrying a higher false positive rate. That matters when you tune.

Plan availability

WAF managed rulesets are not identical across plans:

The Free Managed Ruleset is a subset tuned for the highest-impact exploits and is enabled by default on Free zones. It does not let you customize individual rules. The full Cloudflare Managed Ruleset, the OWASP Core Ruleset, and per-rule customization arrive on paid plans.

OWASP scoring and paranoia level

The OWASP Ruleset is the part that needs real understanding because two knobs control it:

• Paranoia level (PL1 to PL4): PL1 is the least aggressive and the default. Each higher level enables additional rule groups and, with them, enforcement groups designed for stricter inputs. At the higher levels you will need to disable some rules for applications that accept complex input.
• Score threshold: Low (60+), Medium (40+, default), or High (25+). The threshold holds the anomaly score that buys the configured action.

Example: a request trips a couple of XSS rules worth 25 points. With threshold Medium (40+) those points cause no action. With threshold High (25+), the total passes and the OWASP action fires. So "stronger" is not a single setting: it is the combination of paranoia level (which rules are active) and threshold (when they act). Cloudflare's recommended start is either strict (PL4, Low threshold) and relax, or relaxed (PL1, High threshold) and tighten, based on what your traffic does.

Deploy and tune

1. Open Security > WAF > Managed rules in the dashboard.
2. Deploy the Cloudflare Managed Ruleset first; verify legitimate traffic is unaffected.
3. When you want stricter input protection, deploy the OWASP Core Ruleset with the default PL1 / Medium.
4. Switch the OWASP ruleset to Log while you watch Security Events for days, then read the request span that matched and either add an exception or keep it blocked.
5. Raise the paranoia level only for protected, narrow paths (forms, checkout, APIs), and keep aggressive inspection away from pages that accept free-form text.

The false positive loop is the same for both rulesets: an exception rule (skip) that runs before the executed rules is better than disabling a single rule, because it lets the rest of the bundle keep protecting the path. When a legit visitor is blocked, use the security events flow to pull the ray ID, the rule ID, and the exact match before editing anything.

Prevention

Start logged, watch for two weeks, add vault exceptions instead of disabling rules, and lower the paranoia level before any app launches so a new feature does not walk your entire traffic into a block. The WAF is a tool that needs evidence, not a flip-it-on-and-forget-you set.