Vercel WAF vs Cloudflare WAF

Every production web application needs a firewall. The question is where it runs. A WAF that sits as a reverse proxy in front of your origin can protect anything behind it, but it's a separate network, a separate vendor, and a separate place for rules to live. A WAF embedded in the platform your application already runs on can reference your framework's routes, ship with your code, and avoid the extra hop, but it only protects what's on that platform.

Cloudflare WAF and Vercel WAF sit on opposite sides of that choice. Cloudflare runs as a reverse proxy at its own edge, in front of any origin you point it at. Vercel WAF is embedded in the Vercel CDN, in the same request path as your deployment. That architectural difference shapes rule propagation, bot detection, pricing, and whether it even makes sense to run them together.

This guide breaks down how the two products compare so you can decide which one fits what you're running, and whether you need both.

The reverse-proxy vs embedded-platform choice described above affects rule scope, detection surface, and where rules live in your development workflow.

Both products expose the same core primitives: custom rules with rich match parameters, managed rulesets for common threats, and IP- and geo-based blocking. The differences are in propagation speed, rule scope, and what rules can reference.

For most IP allowlisting, geo restrictions, and L7 custom rules, the two products do the same job. The practical differences are that Vercel rules propagate in under 300ms (versus seconds for Cloudflare), Vercel rules can reference framework routes without regex, and Cloudflare offers paranoia-level OWASP tuning that Vercel doesn't match today.

Both platforms ship managed bot protection on every plan and add deeper detection on paid tiers. The detection models differ in what they expose to your application.

Vercel and Cloudflare take different approaches to sophisticated bots. Cloudflare exposes a numeric bot score so you can write threshold rules like "challenge anything below 30, block below 15." Vercel BotID returns a boolean verdict via checkBotId() in server-side code, so your application can make decisions directly. BotID relies on client-attached special headers for classification, but the application-facing verdict comes from checkBotId(), not a general platform request header. Which model fits better depends on whether your team wants to tune thresholds against a score or consume a verdict as a signal in code.

Both platforms offer unmetered DDoS mitigation on every plan. The differences are in network footprint and what emergency controls you have during an active attack.

For most applications, DDoS protection isn't the deciding factor; both products handle typical attack traffic without customer action. Cloudflare has a larger raw absorptive footprint for the very largest volumetric attacks. Vercel's Attack Challenge Mode is a useful emergency lever that's free on every plan and doesn't bill challenged traffic.

The comparison tables above show where the two products overlap. The sections below go deeper into the capabilities that are specific to Vercel WAF.

Rules in a reverse-proxy WAF match on raw URL patterns. A rule that should apply to a dynamic route, like a product detail page, must be written as a regex that infers the path at request time. This is brittle. Framework routing changes, path prefixes shift, trailing slashes vary, and a broken rule either over-blocks legitimate traffic or quietly stops matching at all.

Vercel WAF is aware of the framework routes in your deployment. A rule targeting /blog/[slug] or /api/checkout/[orderId] matches against the actual route definition, not a regex guess. The rule continues to work when you rename parameters, reorganize routes, or move the application between Vercel projects. See WAF Custom Rules for the full match parameter list.

Simple bots can be filtered on user agent and TLS fingerprint. Sophisticated bots are different. Those using Playwright or Puppeteer can solve CAPTCHAs and mimic real browsing behavior. This needs a different approach. BotID is Vercel's answer, built on Kasada's ML detection engine.

BotID is invisible to end users. There's no CAPTCHA to solve, no slider to drag, no images to identify. The client collects thousands of signals such as TLS fingerprint, JA4 digest, browser characteristics, and timing patterns. The detection logic is mutated on every page load to prevent reverse engineering. Server-side verification is a single checkBotId() call that returns a verdict. Requests that fail verification can be blocked, challenged, or logged based on your application logic.

Deep Analysis (generally available on Pro and Enterprise) adds continuous ML adaptation. When a new bot network appeared against one Vercel customer and traffic spiked 500% above baseline, Deep Analysis adapted and correctly classified the bots within minutes, with no customer action required.

When you're responding to an active attack, every minute of latency between "I wrote the rule" and "the rule is enforced globally" is a minute of continued damage. Cloudflare propagates rule changes in seconds. Vercel WAF propagates them globally in under 300ms, with an instant rollback in the dashboard if a rule turns out to be too aggressive.

The same propagation speed applies to Attack Challenge Mode. Flipping it on during an incident enables a browser challenge for all traffic in under a second, and flipping it off is just as fast. Search engine crawlers are automatically allowed through without being challenged, so extended use doesn't harm SEO.

Vercel WAF rules can be configured in three ways:

• Dashboard: click-through configuration in the Firewall tab of your project.
• Firewall API: programmatic rule management for automation and custom tooling.
• vercel.json: rules defined alongside the rest of your project configuration, deploying with the code so security changes follow the same review, branching, and rollback workflow as any other change.

Combined with the Vercel Terraform provider, a team can manage firewall rules across many projects as code. See Firewall Terraform Configuration for a worked example across multiple projects.

Cloudflare offers capabilities that fall outside Vercel WAF's current scope. If your project relies on any of these, Cloudflare may be worth keeping in front of a non-Vercel origin, or running alongside Vercel for specific zones.

Cloudflare Bot Management exposes a 1–99 bot score on every request. Rules can be written against that score: challenge anything below 30, block below 15, log below 50. For teams whose security playbooks are built around score thresholds or whose SIEM pipelines consume the numeric score directly, this is a real gap on the Vercel side. BotID can only return a pass/fail verdict, not a score.

Cloudflare implements the full OWASP ModSecurity Core Rule Set with four paranoia levels (PL1–PL4) and configurable score thresholds (25, 40, 60). Compliance programs that specify OWASP CRS paranoia level as a control and security teams that want to tune individual rule sensitivity can configure this at a granularity that Vercel doesn't match today. Vercel's OWASP Managed Ruleset (Enterprise) exposes per-rule log/deny and basic overrides, not paranoia-level tuning.

Cloudflare Enterprise supports account-level WAF policies that deploy a single ruleset across every zone under the account. For organizations running hundreds of domains under one configuration, this is much less operationally expensive than configuring each zone individually. Vercel WAF rules are scoped per project today; to apply the same rules across many projects, you manage them through Terraform or the API.

Cloudflare's Leaked Credentials Detection is enabled by default on Free plans. It compares submitted credentials against a database of known leaked passwords and surfaces a match as a rule field. This is distinct from credential-stuffing rate limiting; it catches reused passwords even when the request volume looks normal. Vercel does not offer this today. Credential stuffing is handled on Vercel via BotID on authentication endpoints, plus WAF rate limiting keyed to paths like /login or /auth, which addresses automation but not the individual-password leak case.

Cloudflare operates in 330+ cities across 100+ countries. Vercel runs on 100+ PoPs across 20 compute regions. For applications facing the very largest volumetric DDoS attacks, or for workloads with users spread across regions where Vercel doesn't currently have a PoP close by, Cloudflare's raw footprint is larger.

Cloudflare publishes a weekly changelog of managed ruleset changes and issues emergency releases for zero-days with public documentation. Security teams that need to audit what changed and when, or review upcoming changes before they propagate, have a documented feed. Vercel updates managed rulesets as threats emerge, but the cadence isn't publicly documented in the same way.

Both products bundle meaningful WAF capabilities into their lower tiers and add more at the Enterprise tier. The headline difference is that Vercel bundles the WAF into every plan (including Hobby), while Cloudflare's full WAF starts on the Pro tier.

If you're not on Vercel, Cloudflare's Free tier gets you the Free Managed Ruleset and five custom rules, enough for basic protection, but most production use cases need at least Pro for more rules and the broader Managed Ruleset.

For Vercel customers, the cost comparison that usually matters isn't "Vercel WAF vs Cloudflare WAF". It's whether the Cloudflare plan you're paying for is still pulling its weight once Vercel WAF is handling the same traffic. That question is the subject of the next section.

Generally, no. Running Cloudflare in proxy mode in front of Vercel creates three problems:

Client signals degrade. When Cloudflare is the reverse proxy, the true client IP address is rewritten, and client-side signals such as the TLS fingerprint and browser characteristics are hidden from Vercel's firewall and BotID. Detection quality drops noticeably, particularly for sophisticated bot traffic, where those signals serve as the detection surface.

You pay for two CDNs. Every request traverses both networks. You pay Cloudflare for the proxy layer and Vercel for the underlying delivery and compute, for traffic that either could serve alone.

You add a hop of latency. Every cache miss goes Cloudflare → Vercel origin → back through Cloudflare → user, instead of Vercel → user directly.

If you want to keep Cloudflare for DNS or registrar reasons, run it in DNS-only mode (the grey-cloud setting) rather than in proxied mode. That keeps DNS management on Cloudflare without putting Cloudflare in the request path. See Should I use Cloudflare in front of Vercel? for more information.

The exception is when one of Cloudflare's gap-closing capabilities: numeric bot score, paranoia-level OWASP tuning, leaked-credential lookup, or account-level policies across many zones is a non-negotiable. In that case, Cloudflare WAF makes sense in front of non-Vercel origins or alongside Vercel for specific zones that need those features.

The right product depends on what you're running and what security capabilities are hard requirements.

The choice usually comes down to whether your workload is on Vercel and whether one of Cloudflare's capability gaps is a key requirement for your use-case(s). Vercel-hosted applications without those specific requirements almost always consolidate on Vercel WAF, because the integration with the deployment pipeline and the absence of a second CDN layer outweigh the feature gaps for most teams.

If your application is on Vercel, the firewall is already available under Firewall in your project dashboard. Enable Bot Protection with a single click, define custom rules through the UI or vercel.json, and turn on Attack Challenge Mode as an emergency lever during an incident. Or sign up for a free account to try it.