Cloudflare WAF: What Managed Protection Really Blocks and What It Passes

Most teams activate Cloudflare WAF like installing an antivirus: once configured, the problem is solved. This premise is wrong, and the cost of not understanding it is a false sense of security that can be more dangerous than no protection at all.

WAF is an effective layer against a specific class of threats. Against another class, it provides friction, not barrier. Knowing the difference determines how you calibrate the system and what needs to be built at the application level.

What managed rulesets actually do

Managed rules cover the most common attack classes: SQL injection, cross-site scripting, directory traversal, web shell upload, exploitation of known CVEs in popular frameworks. They work by signature matching — the engine inspects the request and checks if any patterns match those registered in the rules.

This model has an intrinsic limitation: it operates on the form of the request, not on its meaning for the application. A rule that detects ' OR 1=1 -- in a query parameter will trigger both an SQLi attack and a legitimate user searching for SQL tutorials. The rule has no way of knowing what that parameter represents in the context of your application — it only sees bytes.

This generates predictable false positives. In applications with rich text editors, endpoints that accept HTML as legitimate input crash on XSS rules. APIs that receive JSON with special characters collide with SQLi rules. The protection is real, but it is not surgical.

What a patient attacker can do

Managed rulesets are excellent against commodity attacks: automated scanners, tools like sqlmap in standard mode, script kiddies that trigger generic payloads. Anyone who uses these vectors without customization will hit WAF and stop there.

The different scenario is the attacker knows which WAF is protecting the target — often public information via headers, cookies, or response behavior. With this knowledge, he systematically tests bypass techniques: unusual encoding (URL encoding at multiple levels, unicode normalization, mixed-case in SQL keywords), fragmented payloads in large bodies, combinations that exploit the engine's processing limit.

Against a determined attacker who customizes payloads for the specific target, WAF adds work, not impossibility. This still has value — increasing the cost of an attack reduces the number of attackers willing to pay for it. But it is not an absolute barrier, and treating it as such is dangerous.

There is one category of vulnerability where WAF simply doesn't fit: business logic. If your application allows a user to view another's data by manipulating IDs in the URL (IDOR), WAF will not detect this. The request is formally valid, without malicious payload. The problem is in the application logic, and the only effective protection is in the code.

Tiers and what each plan actually covers

Layer 3 and 4 DDoS protection is available on all plans, always on and without configuration: volumetric mitigation at the edge, before traffic reaches your infrastructure.

Layer 7 WAF — with managed rules — starts on the Pro plan at $20 per month. This tier unlocks Cloudflare Managed Ruleset and OWASP Core Ruleset. The free plan only allows 5 custom rules, without access to any managed rulesets. For most applications with real safety requirements, Pro is the minimum acceptable floor.

The actions available per rule are: Block (immediately returns 403), Challenge (displays a JavaScript challenge that bots cannot solve), Managed Challenge (Cloudflare automatically decides the level of the challenge), Log (logs without taking action), Skip (skips specific rules or entire groups) and Allow (passes without inspection). The composition of these actions is where much of the calibration happens.

A detail that invalidates everything

There is a prerequisite that is not obvious in the initial documentation: WAF only works for DNS records with the Cloudflare proxy active — what the interface calls "orange cloud". Records configured as DNS-only (gray icon) point directly to the source IP. Traffic does not go through Cloudflare, so no WAF rules, no edge DDoS mitigations, no JavaScript challenges apply.

This affects subdomains left as DNS-only for convenience: staging environments, internal APIs accessed from outside, ancillary services. If the attacker discovers these subdomains — and DNS enumeration tools make this trivial — he has a direct path to the origin without going through the WAF. Mapping your DNS records and the state of each needs to be part of the security audit.

What your team needs to decide before activating

Enabling managed rulesets without an observation period is a recipe for blocking legitimate traffic in production. The operationally safe path starts with all rules in Log mode: you see what would be blocked without blocking anything, analyze the firing pattern and identify false positives before switching to Block or Challenge.

The most critical decision is how to handle rules that fire incorrectly. Disabling the rule globally creates a loophole for the actual attack it protected against. The right answer is a precisely scoped Skip rule: this specific managed rule, on this specific path, for this specific condition. The closed scope preserves coverage throughout the rest of the application.

It is also worth deciding in advance the sensitivity threshold for the OWASP Core Ruleset. It works by accumulated score — each rule that triggers adds points, and the action happens when the total exceeds a configurable limit. Too low a limit blocks legitimate traffic; too high, it misses sophisticated attacks. The break-even point depends on the nature of your application and the traffic profile you observed.