The most common assumption from teams who have just enabled Cloudflare WAF is that the application is now protected. This conclusion is technically incorrect — not because WAF doesn't work, but because the attacks it blocks are only a subset of the ones you'll receive. The other two subsets have different products, with completely different detection logic, and the three are rarely configured together from the start.
What each layer actually sees
The clearest way to understand the division is to think about three dimensions of the request: what it contains, how many arrive, and who is sending them.
WAF operates on content — inspects the request payload and checks whether it matches known attack patterns. A ' OR 1=1 -- in a query parameter, a script tag in a form field, a ../../../etc/passwd sequence in a path: these are signatures that the engine recognizes and blocks. The WAF is surgical in the que dimension, and blind in the other two.
Rate Limiting operates on speed. It doesn't matter what the request contains — if an IP is sending 50 login attempts in ten seconds, something is wrong. WAF cannot detect this because each individual request is formally valid: the SQL query is correct, there is no malicious payload, the HTTP request would be accepted by any server without objection. The problem isn't the format — it's the frequency.
Bot Management operates on behavioral identity. A sophisticated bot that randomizes intervals between requests, uses a rotating IP pool, and maintains rates within the limits configured in Rate Limiting will pass through the first two layers without friction. What delivers this type of traffic is the behavioral fingerprint: navigation patterns that do not exist in human sessions, absence of mouse events before submit, request sequences without the auxiliary assets that a real browser would load, use of TLS fingerprints associated with automation stacks. Bot Management scores each session in this behavioral dimension and acts on the score, regardless of payload and speed.
How credential stuffing passes through WAF and why Rate Limiting catches on
The attack that best illustrates the need for the three layers is credential stuffing with a controlled cadence. The attacker has a list of leaked credentials from other services and tests each pair against your application's login endpoint — not in bursts, but methodically, at 3 to 5 attempts per minute per IP. It uses residential proxies to distribute attempts and ensures that no individual IP goes beyond obvious limits.
From the WAF's perspective, this attack is invisible. The login request is a POST with email and password fields, structurally identical to what any legitimate user would send. The incorrect password is not a malicious payload — it is just text that will fail authentication. There is no signature for WAF to recognize.
With Rate Limiting, you configure a rule on endpoint /login with a time window and a limit of attempts per IP. Five requests in ten seconds triggers Block. Three requests in fifteen minutes on the password recovery endpoint, ditto. The attacker who calibrated your bot to be below this threshold will still get through, but you've eliminated the cheapest layer of credential stuffing — the scripts that simply fire without cadence control.
What Rate Limiting doesn't solve is the attacker distributing it across enough IPs to stay below the limit on each one. This is where Bot Management comes in: even if each individual IP only makes two attempts, the session's behavioral score will indicate automation.
The product architecture and what each plan unlocks
Rate Limiting is a separate product from WAF — they are not rules within the same system, they are systems with independent logic and configurations. This distinction is important when configuring, because teams used to working only with WAF rules often look for Rate Limiting in the wrong place in the interface.
The control dimensions available in Rate Limiting include IP, combination of IP and path, specific cookie, and user-agent. The actions are Block, Challenge, and Log — with Log being the equivalent of WAF's watch mode, useful for calibrating thresholds before activating blocking in production.
Cloudflare's free plan allows for a single Rate Limiting rule. Pro ($20/month) goes up to five rules. Business stops one hundred. Enterprise removes the rules limit and unlocks full Bot Management, including access to cf.bot_management.score as a variable in rule expressions — a number between 0 and 99 where lower values indicate more automated traffic.
On Pro, the Bot Management equivalent is Super Bot Fight Mode: a simplified setting that blocks definitely automated bots, challenges probably automated ones, and lets verified traffic through. You don't access the numeric score or write rules based on it, but coverage against the most common bot categories is active.
What the Pro plan combination covers in practice
For $20 per month, a web application with minimal attention to configuration can cover most of the automated attack surface. WAF with Cloudflare managed rulesets in Block mode for OWASP level 1 intercepts SQLi, XSS, path traversal, and exploitation of known CVEs. The five Rate Limiting rules cover critical endpoints: login with a limit of five requests in ten seconds per IP, password recovery with three requests in fifteen minutes, account registration with ten requests in one hour, payment endpoint with ten requests in one hour, and API root with one hundred requests per minute. Active Super Bot Fight Mode blocks the volume of bots that do not have enough sophistication to disguise behavior.
What this combination doesn't cover are bots with genuinely human behavior — sessions that browse at plausible speed, with synthetic but convincing mouse and keyboard patterns, using home IPs with clean histories. This level of sophistication is expensive for the attacker and rare in attacks targeting applications that are not high-value targets. For most web applications, the gap left in Pro is acceptable.
Where does it make sense to scale to Business or Enterprise
The decision to upgrade is an equation of risk and cost, not of technological ambition. Business justifies the leap especially if you need more than five Rate Limiting rules — an application with dozens of sensitive endpoints will exhaust the Pro limit quickly. One hundred rules in Business solve this problem without reaching the Enterprise investment.
Enterprise makes sense when the threat profile includes adversaries with capabilities to bypass simplified detection: sophisticated financial fraud, competitors systematically scraping prices with bots that mimic human behavior, or highly distributed credential stuffing against a high-value service. Access to Bot Management's numerical score allows you to create rules with a granularity that Super Bot Fight Mode does not offer — block above 30, challenge between 30 and 60, allow above 60, with additional logic via path or HTTP method. This expressiveness has a cost, and the cost is only justified when the risk mitigated is proportional.
A concrete way to evaluate: Add up the revenue at risk in the event of successful fraud, the cost of a Layer 7 DDoS outage, and the incident response effort for a credential stuffing attack at scale. If this number is greater than the annual difference between Pro and Enterprise, the conversation with the vendor is worth the time.
Also read
- Cloudflare WAF: What managed protection actually blocks and what passes
- KV for rate limiting, feature flags and distributed configuration: where it works and where it breaks
- DNS proxied vs DNS only: what changes and when each mode makes sense
- DNSSEC with Cloudflare: what it protects, what it doesn't protect and how to activate without problems
- Cloudflare Durable Objects: Consistent state at the edge — what really changes
- Email Routing + Workers: process emails programmatically on edge