Cloudflare Managed Ruleset: What the WAF Rules Actually Do, Which Plan Gets Which, and How to Stop the False Positives

A Cloudflare managed ruleset is a set of web application firewall rules that Cloudflare writes, maintains and updates, which you deploy to a zone with one switch instead of authoring rules yourself. There are four. The Free Managed Ruleset covers a small number of high-impact vulnerabilities and is on for every zone including free ones. The Cloudflare Managed Ruleset is the broad signature-based set for known attacks and CVEs. The OWASP Core Ruleset is a scoring-based implementation of the open ModSecurity rules that catches generic injection patterns at the cost of more false positives. The Exposed Credentials Check watches login endpoints for leaked passwords. The paid three come with Pro and above, and the practical skill is not turning them on but tuning them so a legitimate request with SQL in a comment field does not come back as a 403.

The dashboard makes deploying these look like flipping a switch, which it is. What it does not make obvious is what each set is looking for, how the OWASP scoring works, and where to look when a real user is blocked, which is the point at which most people either disable the ruleset or start writing skip rules at random.

Table of contents

• The four rulesets and what each one is for
• Which plan gets what
• How the OWASP ruleset scores, and why it needs tuning
• Diagnosing a false positive
• What the managed rulesets do not cover
• How this fits the rest of the stack
• FAQ

The four rulesets and what each one is for

• Cloudflare Free Managed Ruleset. A short list of rules for widely exploited vulnerabilities, such as the well-known remote code execution flaws in popular logging and web frameworks, deployed automatically on every zone. It is not configurable beyond on and off, and there is no reason to turn it off.
• Cloudflare Managed Ruleset. The main event. Hundreds of signature rules written by Cloudflare’s team against specific attack patterns and CVEs, grouped by the software they target: WordPress, Joomla, PHP, Drupal, Magento, and generic categories for SQL injection, cross-site scripting, file inclusion and so on. Each rule has a default action that is usually block, and the set is updated as new exploits appear. Designed for low false positives.
• Cloudflare OWASP Core Ruleset. Cloudflare’s implementation of the OWASP ModSecurity Core Rule Set. Instead of matching specific exploits, it scores each request against dozens of generic patterns: does this parameter look like SQL, does that header look like a path traversal. A request whose total score exceeds a threshold is blocked. It catches novel attacks the signature set has never seen and it blocks legitimate requests that happen to look suspicious.
• Cloudflare Exposed Credentials Check. Watches configured login endpoints and checks submitted username and password pairs against a database of credentials leaked in public breaches. It does not block by default; it adds a header your application can read to force a password reset or a second factor.

Which plan gets what

The Free plan gets the Free Managed Ruleset and nothing else from this list. Pro adds the Cloudflare Managed Ruleset, the OWASP Core Ruleset and the Exposed Credentials Check. Business and Enterprise add more control: more rule overrides, custom managed ruleset configurations, and on Enterprise, the ability to build managed rulesets at the account level and deploy them across zones.

For a small site on the Free plan, the honest position is that the WAF protection is the Free ruleset plus whatever custom rules you write yourself, and the custom rules engine on the Free plan is capable: rate limiting by path, blocking by country or ASN, challenging requests that match a pattern. That is often enough for a marketing site. It is not enough for an application with a login, an upload or a search box, which is where Pro and the managed sets earn their fee.

How the OWASP ruleset scores, and why it needs tuning

The OWASP set is the one that generates support tickets, because it works differently from the signature set. Each rule that matches adds points, weighted by the rule’s severity: critical rules add five, errors add four, warnings three, notices two. The zone has a score threshold, and a request exceeding it is blocked. The threshold is expressed as a sensitivity: low means a high threshold and few blocks, high means a low threshold and many.

The paranoia level is the other dial. Rules are grouped into levels one to four, and each level adds more speculative rules. Level one is meant to be safe for almost any application. Level four assumes anything unusual is hostile and is meant for applications where a false positive is cheaper than a missed attack.

The tuning approach that works: deploy with the action set to log rather than block, run for a week, look at what would have been blocked, and only then switch to block at a sensitivity where the false positives are ones you can live with or exempt. Deploying at high sensitivity in block mode on day one and then turning the whole thing off after the first complaint is the pattern to avoid, and it is the common one.

Diagnosing a false positive

When a real user reports a 403 from Cloudflare, the request is in the security events log with the rule ID that matched. That is the starting point, and it is faster than guessing.

1. Open Security, then Events, filter to the time and the client IP or Ray ID the user gave you.
2. The event shows the ruleset, the rule ID, and for OWASP the individual rules that contributed to the score.
3. Decide whether the rule is wrong for your application in general, or only for one path or parameter.

The fix depends on that last answer.

• Override the rule in the managed ruleset configuration: change its action from block to log, or disable it. Applies zone-wide, and is right for a rule that will never be relevant to your stack, such as the Joomla group on a site that is not Joomla.
• Add a skip rule in custom rules: when the URI path matches /api/editor/save, skip the OWASP ruleset. Scoped, and right for one endpoint that legitimately receives content that looks like code.
• Lower the OWASP sensitivity if the false positives are broad and diffuse. This is the blunt instrument; prefer the first two.

Skip rules deserve a caution: a skip that matches too broadly, such as on a whole path prefix, removes protection from every endpoint under it. Match on the path and the method, and review the skip list every few months for entries nobody remembers adding.

What the managed rulesets do not cover

A WAF inspects requests and blocks patterns. It does not fix the vulnerability in your code; it hides it from the most obvious probes. It does not handle logic flaws: a request that is well-formed and authorised and does something it should not do passes every ruleset. It does not stop credential stuffing at volume without rate limiting alongside it. And it protects only traffic that passes through the proxy, which is why the origin allowlist and authenticated origin pulls matter: an attacker who reaches the origin directly is talking to an unfiltered server.

The right mental model is that the managed rulesets remove the background noise of automated scanning so that your own security effort can go into the application. They are a floor, not a ceiling.

How this fits the rest of the stack

The WAF sits in front of something, and how that something is hosted decides how much of the rest of the security story is yours. A service on RunxBuild is deployed from a repository with its runtime logs in the dashboard, which is where a blocked request’s origin-side half shows up when you are working out whether a rule was right. A managed database behind it is on a private network and not reachable from the internet at all, which removes the class of attack the SQL injection rules exist for from the outside path. The RunxBuild hosting calculator prices the service and the database together, so the WAF plan tier can be judged against what the origin costs to run.

Useful related references:

• Cloud Managed Firewall: What It Does, What It Doesn’t, When to Use One
• Cloudflare Logpush: What It Ships, What It Costs, and What It Misses
• WordPress Self-Hosting: LAMP, Docker, or Managed RunxBuild
• Services on RunxBuild

FAQ

What is a Cloudflare managed ruleset?

A set of WAF rules that Cloudflare writes, maintains and updates, deployed to a zone with a single toggle. There are four: the Free Managed Ruleset, the Cloudflare Managed Ruleset for known attack signatures, the OWASP Core Ruleset for generic scored patterns, and the Exposed Credentials Check for leaked passwords on login endpoints.

Which managed rulesets are available on the Cloudflare Free plan?

Only the Free Managed Ruleset, which covers a small set of high-impact vulnerabilities and is deployed automatically. The Cloudflare Managed Ruleset, OWASP Core Ruleset and Exposed Credentials Check require Pro or above. Custom rules and rate limiting are available on Free.

How does the OWASP Core Ruleset decide to block a request?

Each matching rule adds points weighted by severity, and a request whose total exceeds the zone’s threshold is blocked. The threshold is set via a sensitivity level, and a paranoia level controls how many speculative rules are active. Deploy in log mode first and tune before switching to block.

How do I fix a false positive from a Cloudflare managed rule?

Find the event in Security, Events, using the time, IP or Ray ID. Note the rule ID. Then either override that rule’s action to log or disable it zone-wide, or add a custom skip rule scoped to the specific path and method that legitimately triggers it. Avoid broad skips and avoid disabling the whole ruleset.

Does a managed ruleset protect my origin server directly?

Only for traffic that passes through Cloudflare’s proxy. Requests sent straight to the origin’s IP bypass every rule. Pair the WAF with an origin firewall that allows only Cloudflare’s IP ranges and with Authenticated Origin Pulls so the origin accepts connections only from your zone.