Managed Rules vs Custom Rules in WAF: When to Write Your Own

There is a common belief that enabling Cloudflare Managed Ruleset and OWASP Core Ruleset is enough to have a protected application. The premise ignores what these rulesets were designed to do — and what they deliberately don't do.

Managed rulesets are broad-spectrum protection. They were built to work on any web application, from a WordPress blog to a payments API, without any knowledge of what makes their application different from any other. This is precisely what limits them.

What managed rulesets cover and where they generate friction

Cloudflare Managed Ruleset is automatically updated when Cloudflare detects new exploit kits, large-scale attack signatures, and active exploitation of CVEs in popular software. For a team without a dedicated security team, this has real value — continuous coverage without manual maintenance.

The OWASP Core Ruleset works with cataloged attack classes: SQL injection, XSS, file inclusion, insecure deserialization. The scoring model accumulates points as rules fire on the same request, and action occurs when the total crosses a configurable threshold. This design reduces false positives from very sensitive isolated rules, but does not eliminate them.

False positives appear predictably in three contexts. API endpoints that accept JSON with quotes, apostrophes, or parentheses collide with SQLi rules — the engine sees the form, not the context. Administrative panels with rich text editors trigger XSS rules when the user saves legitimate HTML in a POST. Binary upload endpoints enable text-calibrated body inspection rules. None of these are attacks; all are legitimate application behaviors.

What custom rules allow you to do

Custom rules operate with knowledge that managed rulesets will never have: the specific behavior of your application, the profile of legitimate traffic, the threats relevant to your use case.

Cloudflare's expression language supports compound conditions with and, or, and not. A block by country of origin ip.geoip.country eq "RU" combined with http.request.uri.path eq "/api/register" restricts only the registration endpoint, without touching the rest. Field cf.threat_score gt 10 blocks IPs with poor reputations without requiring manual blacklists.

Allowlists for trusted sources are as important as blocking rules. Monitoring IPs, CI/CD and internal operators must be excluded from all inspection with an Allow rule applied before the others. Without this, a health check returns 403 and a staging deployment gets stuck in rate limiting — hours of investigation into a problem that shouldn't exist.

Rate limiting on sensitive endpoints belongs to custom rules. Logins, password recovery, and OTP endpoints have very different traffic profiles than the rest of the application. A rule limiting /auth/login to 5 requests per minute per IP protects against credential stuffing without affecting any other path.

Blocking malicious scraper user agents also fits here: http.user_agent contains "Scrapy" or http.user_agent eq "" are filters that a generic ruleset will not implement because they depend on your decision about which sources to exclude.

How to resolve false positives without opening loopholes

When a managed ruleset fires incorrectly, disabling the rule globally removes protection for all other paths where it worked. The correct answer is a precisely scoped Skip rule: http.request.uri.path eq "/api/content" and cf.waf.rule_id eq "100016" disables rule 100016 for that path only, maintaining coverage across the entire application. Scoping by cf.waf.rule_id rather than by rule group is the difference between a surgical exception and a hole.

Rule identifiers appear in activity logs when the rule fires in Log mode — yet another reason the observation period is mandatory before any blocking.

How to calibrate plans according to what is available

The free plan offers 5 custom rules and no access to managed rulesets. With 5 rules, the priority is clear: allowlist of internal IPs, blocking by high cf.threat_score, rate limiting on the most critical endpoint. Trying to cover everything with 5 rules results in overly broad rules with unpredictable side effects.

The Pro plan goes up to 20 rules and unlocks managed rulesets. The Business plan reaches 100 — which allows you to create different protection profiles per group of endpoints: public APIs with more permissive rate limiting, administrative panels with more aggressive inspection, partner webhooks with allowlists by source IP. With 20 rules you make choices; with 100 you do politics.

The calibration process that works in practice

The order of operations matters more than the specific configuration of each rule. Starting with active blocking in a production application without a traffic baseline is a recipe for disrupting real users.

The sequence begins with all rulesets managed in Log mode for seven to fourteen days. The WAF activity dashboard accumulates real data: which rules would fire, with what frequencies, on which paths. With this mapping you identify false positive candidates before they become incidents, write Skip rules with the correct scope, and configure custom allowlist and blocking rules.

Only then does it make sense to move to Managed Challenge or Block, starting with the rules with the lowest false positive risk — specific CVEs — and moving up to the broader ones (OWASP SQLi, OWASP XSS) as you gain confidence. Calibrating the OWASP Core Ruleset threshold is the last decision, because it depends on seeing the real distribution of scores in your application's traffic.