How to Choose an Enterprise Web Application Firewall

Short answer: Three things decide whether a WAF works in production: what a false positive costs you, whether its rule language can express your own business logic, and who maintains it after go-live. Rule count is a poor proxy for quality. On Cloudflare the practical floor is Pro, because Cloudflare Managed Ruleset and the OWASP Core Ruleset start there; custom rules are capped at 5/20/100 on Free/Pro/Business, regular expressions require Business or above, and both the Log action and the WAF attack score are Enterprise-only.

The three things that actually decide a WAF purchase

Vendor comparisons usually lead with rule counts and OWASP coverage. Neither predicts whether the WAF will still be helping you in six months. What does:

1. False positive cost. Every blocked legitimate request is a lost order, a failed login or a support ticket. The question is not “how many attacks does it catch” but “how much of my traffic can I afford to have it wrong about, and how fast can I correct it”.
2. Expressiveness for your business logic. A WAF that knows SQL injection but not what your checkout flow looks like will block your own customers on a busy day. You need to be able to write rules about your endpoints, parameters and clients.
3. Who maintains it. Managed rules need ownership: someone reviews detections, tunes thresholds and decides when a rule goes from log to block. A WAF nobody owns drifts into “block everything that looks odd”, and then into being switched off.

What a WAF is made of, and in what order it runs

Component	Role	When it runs
HTTP DDoS managed ruleset	Absorbs floods before anything else	First
Custom rules	Your own logic: paths, ASNs, headers, clients	Second
Rate limiting rules	Request-rate control per key	Third
Managed rules (Cloudflare / OWASP)	Generic attack signatures	Last
Application profiles	Learns what normal traffic to your app looks like	Detection and analysis layer

The ordering matters more than it looks. Managed rules run last precisely because they are the most likely to be wrong about your traffic, and everything you know for certain about your own business should be settled before they are consulted.

Five tests to run before you sign

1. Can you see what the WAF sees? On Enterprise you get cf.waf.score — 1 to 99, where 1 is almost certainly malicious and 99 is very likely clean; 100 means the request reached the scoring system but was not scored, and 0 in Logpush means it never reached that stage. The class field maps to attack (1–20), likely_attack (21–50), likely_clean (51–80) and clean (81–99). The numeric score plus the sqli/xss/rce sub-scores are Enterprise-only; the class field starts at Business. If you cannot see scores, you cannot tune anything — you can only guess.

2. Can you write rules that describe your business? Custom rule counts are 5 / 20 / 100 / 1,000 by plan, and regular expressions require Business or above. The Log action is Enterprise-only — a real constraint, because “observe before blocking” is how you avoid false positives.

3. Does the managed coverage you expect actually exist on your plan? The Free Managed Ruleset is on all plans, but the Cloudflare Managed Ruleset and the OWASP Core Ruleset are not available on Free — they start at Pro. Sensitive Data Detection is Enterprise-only. Verify coverage per plan rather than assuming the marketing list applies to your tier.

4. Can you tune threshold instead of only blocking? The WAF’s tuning knob is the OWASP score threshold: Low ≥ 60, Medium ≥ 40, High ≥ 25, with paranoia levels PL1–PL4 and PL1 the default. Choosing a level means enabling every rule up to that level, so raising paranoia raises both coverage and false positives together. (Note: sensitivity levels High/Medium/Low/Essentially Off belong to the DDoS managed ruleset, not the WAF — a distinction that causes a lot of impossible change requests.)

5. Do you need multi-tenant or account-level policy? WAF for SaaS is Enterprise, as is account-level WAF configuration. If you serve customers on their own hostnames, this is not an optional extra — it is the product.

How the pieces stack up

Cloudflare capabilities vs. what your team must own

Item	What Cloudflare provides	What your team must do
Generic attack coverage	Managed rulesets; Cloudflare and OWASP sets from Pro	Own the log-to-block decision per rule
Business-specific policy	Custom rules, plan-limited; regex from Business	Write and review rules from real traffic, not templates
Detection visibility	cf.waf.score and sub-scores on Enterprise; class from Business	Build a review loop on detections
Behavioural baselining	Application Profiles — observe in Profile Analysis first	Decide which profiles become blocking rules
Multi-tenant policy	WAF for SaaS (Enterprise)	Define per-tenant overrides and their ownership
Application-layer correctness	—	Input validation, authorisation and parameterised queries; the WAF is not a substitute

Boundaries and non-applicable cases

• A WAF is not an input validation layer. It inspects requests; it does not know what your code does with them. Parameterised queries, output encoding and authorisation checks remain application work.
• A WAF is not a DDoS product. Volumetric and protocol floods are handled by the DDoS layer; the WAF handles payload-level attacks. Buying one does not cover the other.
• A score is not a verdict. A low score is evidence, not proof. High-value actions — payments, password changes, exports — should combine score with application context rather than blocking on the score alone.
• Paranoia level is a trade, not a dial to max out. Choosing PLn enables every rule up to n. Higher paranoia means more coverage and more false positives at the same time; move it with measurement, not enthusiasm.
• Rules without owners decay. Every custom rule should have an author, a reason and a review date. Rules added during an incident and never revisited become the next incident.

FAQ

Do we get OWASP coverage on the free plan? No. The Free Managed Ruleset is available on all plans, but the Cloudflare Managed Ruleset and the OWASP Core Ruleset start at Pro. If OWASP coverage is a procurement requirement, Pro is the floor.

Why can’t we set rules to log only? The Log action on custom rules is Enterprise-only. On lower plans the practical alternative is to start with a challenge action on a narrow expression, or to use Application Profiles in analysis mode and only then decide whether a rule is needed.

How many rules do we really need? Fewer than vendors imply. A handful of well-scoped rules describing your own endpoints, clients and rate expectations usually outperforms a large set copied from a template. Count is a poor proxy for quality.

Is higher paranoia always safer? No. Paranoia level and false positive rate rise together. Safer means “attacks blocked minus legitimate requests blocked”, and the second term grows faster once you leave PL1 without measurement.

Related reading

• Cloudflare WAF vs AWS WAF
• How to Mitigate HTTP Flood and Layer 7 Attacks
• How to Prevent Malicious Web Scraping
• WAF capabilities