Personal study reference, not customer-facing. Covers WAF plan tiers, Managed Rules, request body inspection, WAF attack score, Sensitive Data Detection, Leaked Credentials Detection, AI Security for Apps, and WAF's relationship to adjacent products. Includes a major correction: two internal account-feature names ("WAF Advanced," "Web Attack Detection WAF") that don't correspond to any real public Cloudflare product — the actual public capabilities are different and are documented here. Every fact below is sourced from live Cloudflare docs (full list at the bottom).
Major correction before anything else: "WAF Advanced" and "Web Attack Detection WAF" are not current public Cloudflare product names — a thorough docs search found zero hits for either term. These appear to be internal account-feature flag names (waf_advanced_accfeat, web_attack_detection_waf) visible in an internal provisioning tool, not customer-facing SKUs. The real, currently-documented capabilities are: request body inspection fields are standard Enterprise functionality (not a separate paid add-on — Module 4), and WAF attack score (cf.waf.score) is the real, named, Business/Enterprise-gated feature that "Web Attack Detection" was likely gesturing at (Module 5). Honest nuance: if a customer with Enterprise genuinely hits an entitlement error on a body-inspection rule despite docs saying it's standard, that could reflect an account-level flag that still needs enabling on the backend — escalate to the account team rather than assuming the customer is wrong, but don't tell them upfront that a separate paid "WAF Advanced" product exists, because it doesn't appear in any public materials you could show them.
WAF is three layers working together: Managed Rules (Cloudflare/OWASP-maintained signatures), Custom Rules (your own match-and-action logic), and Rate Limiting Rules (frequency-based blocking). All three evaluate within the same Ruleset Engine, which also powers Bot Management scoring, Transform Rules, and more.
Correction to a common assumption: Free plan is not "Custom Rules only with zero managed ruleset coverage" — it does get the Free Managed Ruleset. It just doesn't get the full Cloudflare Managed Ruleset, OWASP Core Ruleset, or any of the detection add-ons.
This is the table to have open on a call. All numbers verified against current docs, October 2026.
| Capability | Free | Pro | Business | Enterprise |
|---|---|---|---|---|
| Custom Rules — count | 5 | 20 | 100 | 1,000 |
| Custom Rules — regex support | No | No | Yes | Yes |
| Custom Rules — Log action | No | No | No | Yes |
| Zone-level custom rulesets | 1 | 2 | 5 | 10 |
| Account-level custom rulesets | No | No | No | Yes (10 rulesets, 100 rules/ruleset, 1,000-rule hard cap) |
| Rate Limiting Rules — count | 1 | 2 | 5 | 100 (contract-dependent) |
| Rate Limiting — max counting period | 10 sec | 1 min | 10 min | up to 1 day |
| Free Managed Ruleset | Yes | Yes | Yes | Yes |
| Cloudflare Managed Ruleset (full) | No | Yes | Yes | Yes |
| OWASP Core Ruleset | No | Yes | Yes | Yes |
| Leaked Credentials Detection | 1 field | Full | Full | Full + custom locations |
| Sensitive Data Detection | No | No | No | Yes |
WAF attack score (cf.waf.score) | No | No | 1 field only | Full, incl. per-vector scores |
| Request body inspection fields | No | No | No | Yes — standard, not a separate add-on |
| Max body size inspected | 1 MB | <128 KB default, Support can raise | <128 KB default, Support can raise | 128 KB (Support can raise to 1 MB) |
Hard ceiling, not negotiable: the account-level 1,000-rule total quota is a hard limit that applies even to Enterprise and cannot be increased regardless of contract. The 100-custom-rule zone-level default can vary by specific Enterprise contract terms, but there is no publicly listed per-rule add-on price — changes go through Support/account-level entitlement, not a self-serve purchase (unlike Bot Management or Load Balancing, which have real metered SKUs).
WAF is included in the flat per-domain plan price on every tier, Free included — it is never a standalone toggle-on purchase. Only specific advanced capabilities (Sensitive Data Detection, Malicious Uploads Detection, AI Security for Apps detection fields, Advanced Rate Limiting) are gated as separately priced Enterprise paid add-ons.
Managed Rules are not a static ruleset — Cloudflare ships near-continuous updates, often same-day with CVE disclosure. Recent examples from a single month: emergency RCE rule for popular web frameworks, TanStack XSS, Atlassian file-access CVE, F5 BIG-IP heap overflow, Citrix NetScaler emergency release, WordPress + JFrog Artifactory CVEs, Adobe Commerce/Magento "StyleSmuggler" RCE.
"This isn't a ruleset you set once and forget — it's a virtual patching service. When a critical CVE drops in a framework you run, there's a real chance a Managed Rules update already covers it same-day, before you've even patched the underlying software."
Cloudflare Exposed Credentials Check is explicitly marked deprecated. Don't recommend it for new deployments — point customers to Leaked Credentials Detection instead (Module 6), which is the actively maintained, broader replacement.
This corrects the old "WAF Advanced add-on" framing entirely.
Every http.request.body.* field (raw, form, multipart and its sub-fields, mime, truncated) carries the exact same public doc language: "Requires a Cloudflare Enterprise plan." There is no separate named add-on gating these fields beyond the Enterprise plan floor itself.
| Plan | Max body size WAF inspects |
|---|---|
| Free | 1 MB |
| Pro / Business | Lower than Enterprise by default — contact Support to raise (commonly to 1 MB) |
| Enterprise | 128 KB — can request an increase to 1 MB via Support |
Content beyond the inspected window sets http.request.body.truncated = true — the origin still receives the full, untruncated body; only WAF's inspection window is limited.
The payload-limit saga (December 2025) — a genuinely useful teaching story: Cloudflare briefly raised WAF body inspection to 1 MB on all plans to catch a React RCE CVE. Five days later, Enterprise was rolled back down to 128 KB because the larger inspection window caused OWASP/Managed Ruleset false-positive spikes. Free plans kept the 1 MB limit; paid plans need a Support ticket to opt in. This is a real, concrete example of the body-size-vs-false-positive tradeoff worth walking a technical customer through.
Separate and larger: Malicious Uploads Detection (a distinct Enterprise paid add-on, content-scanning/AV pipeline) inspects up to 50 MB of request body — don't confuse this limit with the standard WAF body-field inspection limits above; it's a completely different pipeline.
| What they want to do | Can they do it without body inspection fields? |
|---|---|
| Match a value in a URL query parameter that duplicates the body value | Yes — use http.request.uri.query |
| Match a value in a header the client sends | Yes — use http.request.headers |
| Enforce a schema on an API endpoint | Maybe — API Shield does this without WAF body fields (Module 8) |
| Inspect a small percentage of routes for a specific body pattern | Maybe — put a Worker in front of the route, inspect the body in JavaScript, attach a header, then a base WAF rule matches on that header |
| Broad body inspection across many routes and content types | No — genuinely requires Enterprise plan with body-field access |
This is the real, current, publicly documented feature that the old "Web Attack Detection WAF" internal name was almost certainly gesturing at.
cf.waf.scoreA global score from 1–99 combining the score of each WAF attack vector into a single number, usable directly in Custom Rules and Rate Limiting Rules.
| Plan | Access |
|---|---|
| Business | Limited — the single combined cf.waf.score field only |
| Enterprise | Full — combined score plus per-vector sub-fields: cf.waf.score.sqli, cf.waf.score.xss, cf.waf.score.rce, cf.waf.score.class |
New since September 2026, Early Access only (contact your account team for access). Evaluates requests against Cloudflare's attack signature catalog — the same signature catalog Managed Rules use — but only records match metadata (confidence, category, reference) without applying an action itself. This decouples detection from mitigation: you build a separate Custom Rule off the detection fields to actually act on it, rather than getting an automatic block/challenge the way Managed Rules does.
Positioning: Managed Rules = detect and mitigate in one step, using the configured ruleset action. Attack Signature Detection = detect only, mitigate separately via your own rule — more control, more setup, Early Access today.
Runs on the body of the response (not the request), looking for patterns of PII, financial information, and secrets (e.g. API keys). Requires Enterprise. Rules are always deployed with the Log action — you cannot block a response that's already been sent, so this is a detection/visibility tool, not a blocking mechanism. Handles text, HTML, JSON, and XML content in the response, up to 1 MB.
Don't confuse this with Sensitive Data Detection. Leaked Credentials Detection is request-side (checks submitted login credentials against a breach database) and is available starting on Free (one field) through full access on Pro/Business/Enterprise, with custom detection locations on Enterprise. It is the actively maintained replacement for the now-deprecated Exposed Credentials Check (Module 3).
New since August 2026: Leaked Credentials Detection now scans Authorization (Basic Auth) headers by default, in addition to bodies, query strings, and known-app headers — applied automatically, no config change needed.
A genuinely hybrid case worth understanding precisely: AI Security for Apps is explicitly "built into the Cloudflare WAF" — the WAF must be enabled on the zone before its detection fields can populate. But commercially, the detection fields and Log Mode Ruleset are gated as a separate Enterprise paid add-on, same pattern as Malicious Uploads Detection and Advanced Rate Limiting. LLM endpoint discovery alone is free on all plans; the detection capability itself is the paid layer.
Recent change worth a customer callout: the PII categories (cf.llm.prompt.pii_categories) and unsafe-topic categories (cf.llm.prompt.unsafe_topic_categories) were revised in Sept/Oct 2026 — existing Custom Rules referencing removed or renamed categories will silently stop matching those specific categories. If a customer built rules on these fields before the revision, their rule may now be quietly less effective — worth proactively checking.
New since September 2026, Enterprise-only closed beta (auto-available to existing API Security/Schema Learning customers). A positive-security model: "Schema Profiles" learn the expected request structure for an application — paths, query parameters, headers, cookies, JSON/form body shape — and flag traffic that doesn't conform, for review before deciding to mitigate via Custom Rules. This is the opposite approach from signature-based Managed Rules (which block known-bad patterns) — Application Profiles instead defines known-good shape and flags deviations.
All confirmed as separate SKUs/products — WAF doesn't bundle these, though several surface fields usable inside WAF's rules language.
| Product | Relationship to WAF |
|---|---|
| Bot Management | Separate Enterprise paid subscription. cf.bot_management.score is usable inside WAF Custom/Rate Limiting Rules once purchased — also required to unlock JA3/JA4 fingerprint and richer rate-limiting counting characteristics. |
| API Shield | Explicitly an "Enterprise-only paid add-on," its own product line with its own plans page — not a WAF feature. |
| DDoS Protection (Advanced) | Baseline unmetered DDoS protection is included on all plans; the Advanced DDoS Protection subscription (override controls) is a distinct Enterprise add-on. |
| Client-side security (renamed from Page Shield) | Its own Free/Pro/Business/Enterprise/Advanced availability table, own separately metered pricing (per-request). Listed as a WAF "Related product," not a WAF feature. |
| AI Security for Apps (renamed from Firewall for AI) | The one real exception — architecturally built into WAF, commercially billed as a separate Enterprise add-on (Module 7). |
| Malicious Uploads Detection | Separate Enterprise paid add-on, distinct 50 MB inspection pipeline (Module 4). |
"Request body inspection — rules that look inside a POST body, JSON payload, or form data — is standard functionality included with Enterprise, not a separate purchase. If you're seeing an entitlement error on a body-inspection rule despite being on Enterprise, that's worth escalating through your account team rather than assuming you need to buy something extra — there's no publicly documented 'WAF Advanced' product to purchase. Separately, if you want attack-pattern scoring beyond the base Managed Rules, that's WAF attack score — Business gets a single combined field, Enterprise gets the full score plus per-vector breakdowns (SQLi, XSS, RCE). And if you want response-side scanning for leaked secrets or PII in your own API responses, that's Sensitive Data Detection, Enterprise-only, log-only by design."
failed_detections field (new, Oct 2026)cf.appsec.request.failed_detections is a new array field usable in Custom Rules, Rate Limiting Rules, and Request Header Transform Rules (zone and account level) that tells you when a security detection — content scanning, attack score, attack signature detection, leaked credentials, AI prompt detections — failed to complete, so you can explicitly choose fail-open or fail-closed behavior instead of it happening silently.
| Scenario | Answer |
|---|---|
| Customer wants to block on URL/header/cookie/query/IP patterns only | Base Custom Rules on any plan — no Enterprise needed |
| Customer needs regex matching in Custom Rules | Business or above |
| Customer wants to inspect POST body / JSON payload content | Enterprise — standard capability, not a separate add-on |
| Customer wants a single aggregate "how suspicious is this request" score | WAF attack score — Business (1 field) or Enterprise (full, per-vector) |
| Customer wants to scan their own API responses for leaked secrets/PII | Sensitive Data Detection — Enterprise-only, log-only |
| Customer wants to catch stolen/breached login credentials at submission | Leaked Credentials Detection — available from Free, full access Pro+ |
| Customer wants LLM prompt injection / PII leakage protection for an AI app | AI Security for Apps — Enterprise paid add-on, built into WAF architecturally |
| Customer wants a positive-security model instead of signature blocking | Application Profiles — Enterprise closed beta, ask account team |
| Customer wants detection without automatic mitigation, to build custom logic | Attack Signature Detection — Early Access, ask account team |
"We have Enterprise but a http.request.body.raw rule throws an entitlement error. What do we buy?"
Nothing publicly documented — body inspection fields are standard Enterprise functionality, not a separate purchase. If you're genuinely hitting an entitlement error, escalate through your account team; there may be an account-level flag that needs enabling on the backend, but there's no named "WAF Advanced" product to point to.
"What's the difference between WAF attack score and Managed Rules?"
Managed Rules match known-bad signatures and act automatically per the ruleset's configured action. WAF attack score (cf.waf.score) is a 1-99 number you reference inside your own Custom Rules to build logic like "if score is low AND path is /login, challenge" — it's a signal to build rules against, not a rule itself.
"Is Sensitive Data Detection the same as Leaked Credentials Detection?"
No — SDD scans your responses for PII/secrets/financial data and is Enterprise-only, log-only. Leaked Credentials Detection scans incoming login requests against a breach database and is available starting on Free.
"Why does a 128 KB body inspection limit on Enterprise seem low compared to Free's 1 MB?"
Historical accident, not a typo — Cloudflare briefly set all plans to 1 MB in December 2025 to catch a specific React RCE, then rolled Enterprise back to 128 KB five days later after it caused false-positive spikes on Managed Rules. Enterprise customers can request a Support-ticket increase to 1 MB if needed.
"Does Free plan get any managed ruleset protection at all?"
Yes — the Cloudflare Free Managed Ruleset, available on every plan including Free. It's narrower than the full Cloudflare Managed Ruleset (Pro+) and OWASP Core Ruleset (Pro+), but it's not zero coverage.
"Customer wants detection without Cloudflare automatically blocking anything. Is that possible?"
Yes, two ways: set a Managed Ruleset or Custom Rule's action to Log instead of Block, or use the newer Attack Signature Detection (Early Access), which only records match metadata by design — you build the mitigation rule separately.
Click a question to reveal the answer. No peeking before you commit to one.
No — a thorough docs search found zero hits. Request body inspection fields are standard Enterprise plan functionality, not a separate named add-on to purchase.
5 / 20 / 100 / 1,000 — correcting an older "5/20/unlimited" claim that implied only 3 tiers and an unlimited top tier, neither of which is accurate.
False — it's a hard limit that applies to all plans including Enterprise and cannot be increased regardless of contract terms.
No — Free gets the Cloudflare Free Managed Ruleset (available on all plans). It just doesn't get the full Cloudflare Managed Ruleset, OWASP Core Ruleset, or any detection add-ons, which start at Pro.
WAF attack score (cf.waf.score) — Business gets the single combined field, Enterprise gets the full score plus per-vector sub-scores (SQLi, XSS, RCE).
Managed Rules detect and mitigate automatically per the configured ruleset action. Attack Signature Detection only records match metadata — you build a separate Custom Rule to act on it. Same underlying signature catalog, decoupled mitigation.
The larger 1 MB window, briefly rolled out to all plans to catch a React RCE CVE, caused false-positive spikes on OWASP/Managed Rules once applied at Enterprise scale. Enterprise was rolled back to 128 KB five days later; Free kept 1 MB; paid plans can request a Support-ticket increase.
SDD scans responses for PII/secrets/financial data, is Enterprise-only, and is always log-only (can't block an already-sent response). Leaked Credentials Detection scans incoming requests for breached login credentials and is available starting on Free.
No — it's explicitly deprecated. Leaked Credentials Detection is the actively maintained replacement.
It now scans Authorization (Basic Auth) headers by default, in addition to bodies, query strings, and known-app headers — applied automatically with no config change needed.
Both, genuinely — it's architecturally built into WAF (the WAF must be enabled for its detection fields to populate) but commercially billed as a separate Enterprise paid add-on, the same pattern as Malicious Uploads Detection and Advanced Rate Limiting.
It doesn't error — it silently stops matching traffic in that specific category. Worth proactively checking any AI Security rules built before the September/October 2026 category revision.
A positive-security model — instead of blocking known-bad signatures like Managed Rules, it learns an application's expected request shape (paths, params, headers, body structure) and flags traffic that deviates from that learned shape.
Purchased separately — it's its own Enterprise paid subscription. Once purchased, cf.bot_management.score becomes usable inside WAF Custom and Rate Limiting Rules, and unlocks richer rate-limiting counting characteristics.
Up to 50 MB — and no, it's a completely separate pipeline from the standard WAF body-field inspection limits (128 KB/1 MB range). Don't conflate the two when discussing size limits with a customer.