Bot Protection on Vercel: The Cost-Attribution View [2026]

A 403'd bot still costs you. Vercel Functions bill per invocation regardless of the response status code, the docs are explicit that Invocations are "counts regardless of request success or failure" [5]. So the question for indie SaaS on Vercel in 2026 is not "is bot traffic a security problem," it is "how much of last month's invoice was bot traffic that your code rejected after billing you to reject it."

This is the cluster 2.7 pillar in Application Security. Where rate limiting on Server Actions catches abuse from a small number of identified sources, this post covers the upstream defense layer: classifying clients as automated BEFORE they hit your business logic, and the cost-attribution math that makes that classification matter in the first place. The framing leans on backend-only data access and the Next.js security hardening checklist; this post earns its place by handling the cost vector those posts do not.

TL;DR:

• Bot traffic is a billing problem on Vercel. Function invocations, Active CPU, and Provisioned Memory all accrue while your code runs the rejection check; a successful block does not refund any of them [5].
• Vercel BotID is free at the Basic tier. Deep Analysis costs $1 per 1,000 checkBotId() calls and is the right add-on for high-value routes (checkout, signup, login, expensive APIs) [1]. Vercel runs it on v0.dev internally [3].
• The Vercel Firewall ships free DDoS mitigation on every plan. Volumetric floods are handled at the platform layer before they reach your function instances [4]. WAF custom rules cost extra and run after.
• Cloudflare in front of Vercel is a tradeoff, not a default. Vercel explicitly recommends against it because the proxy degrades Firewall, BotID, and DDoS accuracy [6]. It still works as a cost-reduction lever at scale; treat it as a conscious choice once a scraper has actually moved the invoice.
• Rate limiting and bot protection are not substitutes. Distributed polite AI scrapers defeat per-IP rate limits. Use both: rate limit Server Actions, classify with BotID on the routes scrapers target.

Table of contents

• Why is bot protection a cost problem in 2026?
• How does Vercel's pricing model amplify bot traffic costs?
• How does Vercel BotID work and what does it stop?
• What does Vercel's free Firewall and DDoS layer actually cover?
• Should you put Cloudflare in front of Vercel?
• When is one layer enough and when do you need two?
• What does SecureStartKit's bot-protection posture look like?

Why is bot protection a cost problem in 2026?

Bot protection in 2026 is a cost-attribution problem first and a security problem second. AI crawlers now generate more than 50 billion requests per day on the Cloudflare network alone, just under 1% of all web requests [8]. Across the top one million Cloudflare-served sites, 39% are accessed by AI bots and only 2.98% take measures to block or challenge them [7]. The gap between traffic share and active blocking is what an unprotected indie SaaS pays for at the end of the month.

The shift from 2023 is not that bots got more numerous. It is that bots became economically asymmetric in a way that targets the serverless model directly. A scraper hitting a SaaS pricing page or a /tools/* calculator does not need to break in to cost the operator money. The act of requesting the page, even for a polite well-identified GPTBot, triggers a Function Invocation, consumes Active CPU during rendering, and bills Provisioned Memory for the entire instance lifetime [5]. The bot pays nothing. The operator pays per request.

Vercel's own announcement of BotID names the attack surface explicitly: "scalpers attacking limited checkouts, fake accounts flooding signups, or credential stuffing targeting login endpoints. It also includes scraping against dashboards, pricing pages, or APIs that expose business logic or drive up compute" [3]. The "drive up compute" framing matters; it is the cost vector, named in primary source, by the platform itself. Vercel built BotID in part because v0.dev needed protection from this exact pattern [3].

How does Vercel's pricing model amplify bot traffic costs?

Vercel Functions on Fluid Compute bill across three dimensions: Active CPU per hour, Provisioned Memory per GB-hour, and Invocations per million [5]. The pricing docs are explicit that Invocations are "billed per incoming request" and "counts regardless of request success or failure." A bot that triggers a 403 still counts as one invocation, plus whatever Active CPU the rejection logic consumed, plus the Provisioned Memory the instance reserved while handling it.

Three properties of this pricing model amplify bot traffic costs in ways that traditional VPS hosting does not.

Invocations meter every request, not every successful request. A Hobby plan includes 1 million invocations per month; overage is $0.60 per million on Pro [5]. A scraper running 10 requests per second sustained for a day pumps 864,000 invocations into your invoice before the day ends. The fact that 100% of those returned 403 changes nothing.

Active CPU bills the rejection path. Active CPU is "the CPU time your code actively consumes in milliseconds" and is "billed during actual code execution and not during I/O operations" [5]. Running the bot check itself, whether that is parsing a JWT, calling checkBotId(), looking up an IP in a denylist, or comparing a header against a managed ruleset, is active CPU. A fast rejection still draws CPU time; a slow rejection (a Supabase lookup, a database join, a Stripe API call to validate a fake customer) draws considerably more.

Provisioned Memory bills the instance, not the request. Memory billing "continues billing while handling requests, even during I/O operations" and only stops "after all requests complete" [5]. A burst of bot traffic that holds an instance open for an hour bills 1 GB-hour of memory on a 1 GB function regardless of whether the requests succeeded.

The math compounds in the worst direction during scraper bursts. A single Bytespider session hitting a JavaScript-heavy Next.js tool page that runs server-side rendering can easily consume 200ms of Active CPU per invocation. Ten requests per second from that one crawler, sustained for an hour, in the iad1 region ($0.128 per CPU-hour, $0.0106 per GB-hour at 1 GB) [5]:

• Invocations: 36,000 requests, $0.022 on the overage rate.
• Active CPU: 36,000 × 200ms = 2 CPU-hours, $0.256.
• Memory: 1 instance × 1 hour = 1 GB-hour, $0.0106.
• Total: roughly $0.29 per scraper-hour, per crawler.

Scale that to ten crawlers running simultaneously across a typical free-tools-heavy indie SaaS surface and the math turns into real dollars on a quiet weekend. The cost is not catastrophic by enterprise standards, and most months it stays inside Hobby's included resources. The risk profile is asymmetric: most months are fine, the month a scraper decides your /tools/* pages are training data is the month the invoice doubles. For deeper SaaS cost mechanics across infrastructure layers, see how much does a SaaS cost to run in 2026.

How does Vercel BotID work and what does it stop?

Vercel BotID is a client-side invisible challenge plus server-side verification, launched June 25, 2025 [3]. The browser solves a challenge that runs JavaScript only a real browser will execute correctly; the server-side checkBotId() call validates the integrity of the response and optionally runs Kasada-powered Deep Analysis [1]. The basic tier is free on all plans; Deep Analysis is $1 per 1,000 checkBotId() calls on Pro and Enterprise [1].

Two integration steps in a Next.js App Router project. First, register the protected routes in instrumentation-client.ts (Next.js 15.3+):

// instrumentation-client.ts
import { initBotId } from 'botid/client/core'

initBotId({
  protect: [
    { path: '/api/checkout', method: 'POST' },
    { path: '/api/og', method: 'GET' },
    { path: '/purchase', method: 'POST' },
  ],
})

Second, call checkBotId() on the server in the API route or Server Action that handles the protected path:

// app/api/checkout/route.ts
import { checkBotId } from 'botid/server'
import { NextRequest, NextResponse } from 'next/server'

export async function POST(request: NextRequest) {
  const verification = await checkBotId()

  if (verification.isBot) {
    return NextResponse.json({ error: 'Access denied' }, { status: 403 })
  }

  // Real business logic only runs for verified humans.
  const body = await request.json()
  // ...
}

The integration is genuinely small. The interesting question is what BotID actually stops and what it does not.

What Basic BotID catches: non-browser HTTP clients, headless browsers without challenge-solving capability, and traffic that omits the BotID headers the client SDK attaches. Per the docs, a request made with curl to a protected route "will block you in production" [2]. This is the floor; it eliminates the lowest-effort scrapers and most credential stuffers using off-the-shelf request libraries.

What Deep Analysis catches: Playwright, Puppeteer, and other automation frameworks that successfully execute JavaScript and solve the basic challenge. Vercel's own framing: "Sophisticated bots are designed to closely mimic real user behavior. They can run JavaScript, solve CAPTCHAs, and navigate interfaces in ways that closely resemble humans" [1]. Deep Analysis uses Kasada's behavioral ML to fingerprint these clients across thousands of signals.

What BotID does not stop: Function Invocation charges on rejected bots. The docs are explicit: "Calling the checkBotId() function in your code triggers BotID Deep Analysis charges" [1]. The bot hits the route, the function spins up, your code runs checkBotId(), the bot is rejected, and you pay the Invocation cost plus the Active CPU consumed plus, if Deep Analysis is enabled, $0.001 for the analysis call. BotID is a security layer, not a cost-elimination layer. It stops the abuse from completing; it does not stop the abuse from being billed.

The honest conclusion: BotID is the right default for protecting expensive business logic from completing for bots (avoiding fake signups in Supabase, avoiding Stripe API calls for fake customers, avoiding Resend sends to fake email addresses). It is not the right tool if the cost problem is the bot reaching your function in the first place. For that, you need to block the traffic upstream of Vercel.

What does Vercel's free Firewall and DDoS layer actually cover?

The Vercel Firewall is a multi-layer system that runs in a fixed execution order: DDoS mitigation rules first, then WAF IP blocking, then WAF custom rules, then WAF Managed Rulesets [4]. The platform-wide DDoS layer is free on every plan and runs automatically with no configuration required; Vercel describes it as blocking "incoming traffic if we identify abnormal or suspicious levels of incoming requests" and protecting against "large-scale attacks such as DDoS and TCP floods" [4].

The free DDoS layer handles two things well and one thing poorly.

Volumetric floods (handled well): A million requests per second from a botnet, an L7 HTTP flood targeting a single endpoint, a TCP/SYN flood. The platform-wide rules absorb these at the edge before they hit your function instances, so you do not get billed for the burst.

JA3 / JA4 TLS fingerprinting (handled well): Vercel's firewall uses TLS fingerprints to identify and restrict known-bad clients before they complete a handshake [4]. This catches automated tooling that uses distinctive TLS stacks (older Go-based scrapers, Python requests defaults).

Polite, distributed AI scraping (handled poorly): A well-behaved AI crawler that respects robots.txt, fetches one page per second, rotates across 200 IPs, uses a recent Chrome TLS stack, and identifies itself with the GPTBot user-agent. This does not look like a DDoS. It looks like normal traffic distributed across many clients. The DDoS layer is not designed to catch it.

The paid WAF layer adds the missing pieces: IP blocking, custom rules to match user-agent strings or request patterns, and Managed Rulesets that cover OWASP and bot-specific signatures. For an indie SaaS, the highest-leverage WAF rule is a custom rule that challenges or blocks the documented AI scraper user-agents (Bytespider, GPTBot, ClaudeBot, CCBot) on routes that are not designed to be indexed; the Cloudflare AI-bot list [9] is a useful starting catalogue for which UAs to enumerate. Attack Mode, available as a switch in the firewall settings, escalates every request to a managed challenge during an active incident.

The free layer is genuinely useful and worth being explicit about: every Vercel project gets DDoS protection without any code change. The free layer is also genuinely limited; it does not solve the cost-attribution problem for polite-looking distributed scraping. For that, you need BotID on the route, a WAF rule, or a third party in front.

Should you put Cloudflare in front of Vercel?

Vercel's official position is no. Their guide Cloudflare with Vercel states: "Using reverse proxies like Cloudflare will limit Vercel's traffic visibility for security measures, introduce latency that degrades performance, and create cache management issues that may affect reliability" [6]. The specific degradations they name: the Vercel Firewall loses "full traffic visibility, which prevents the Vercel Firewall and our threat intelligence products from working to their full potential"; Bot Protection accuracy "significantly degrades"; DDoS protection loses the "ability to automatically challenge requests, prevent DDoS attacks, and more."

That is the platform-aligned default. Three honest reasons it does not always win.

Cloudflare blocks at the edge BEFORE Vercel is billed. A WAF rule, a Cloudflare Bot Fight Mode challenge, or a "Block AI bots" managed rule that triggers on Bytespider returns a response from Cloudflare's edge network. Vercel's Function Invocation counter never increments. The cost-attribution math from Section 2 disappears for blocked traffic. For an indie SaaS getting hammered by scrapers, the math can favor Cloudflare in front despite the tradeoffs Vercel names.

Cloudflare's free tier blocks more than Vercel's free tier. Bot Fight Mode is free and "identifies traffic matching patterns of known bots" with "computationally expensive challenges that force the requesting client to perform CPU-intensive calculations" [10]. The one-click "Block AI bots" managed rule covers the AI-crawler list verbatim: GPTBot, ClaudeBot, Bytespider, CCBot, Amazonbot, Meta-ExternalAgent, and others [9]. Vercel's free DDoS layer does not include equivalent user-agent-level AI-bot blocking; that requires the paid WAF.

Cloudflare proxy mode is reversible. The change is two DNS records flipped from grey-cloud to orange-cloud. If the latency or the cache invalidation pain or the Vercel observability loss is too high, the orange cloud flips back to grey in seconds. This is unlike most architectural decisions where reverting requires a code change.

The decision matrix that actually holds up:

• No scraper problem yet, predictable traffic. Default to BotID on the routes with expensive business logic. Skip Cloudflare in front. Re-evaluate if a future invoice surprises you.
• Scrapers visible in logs, costs still inside your budget. Add a Vercel WAF custom rule blocking documented AI scraper user-agents on routes you do not need indexed. Keep BotID on the conversion-critical routes. Skip Cloudflare in front.
• Scrapers materially moving the invoice, AND Vercel Pro WAF is not catching enough. Orange-cloud the domain through Cloudflare, accept the Vercel-side accuracy degradation, enable Bot Fight Mode + Block AI Bots. This is a conscious cost-vs-protection-accuracy trade, not the default.
• Enterprise traffic where Cloudflare is non-negotiable for other reasons. Vercel supports a documented Cloudflare Origin CA certificate path [6]. Coordinate with the Vercel account team.

The frame on this decision is the same as every other architecture call: align with the platform's defaults until the platform's defaults stop solving your problem. Vercel's defaults solve the cost problem at low scale. They do not solve it at the scale where scraping pays for itself off your bandwidth.

When is one layer enough and when do you need two?

One layer is enough when the bot risk is "expensive business logic running for a non-human" (fake signups, scalper checkouts, credential stuffing, fake Stripe customers). BotID alone on the affected routes solves it: the function runs, BotID rejects, the business logic skips. You still pay for the Invocation and the rejection-path CPU, which is a known and small cost. The expensive part, the Supabase write, the Stripe API call, the Resend send, never executes.

Two layers become necessary when the bot risk is "many bots reaching the platform at all." This is the AI-scraper case. The cost is not in your code running fake-customer business logic; it is in the platform billing you for thousands of rejected GETs to /tools/*, /blog/*, or /api/og. BotID does not help here; the request still reached the function. You need an upstream layer that blocks the request before it ever hits Vercel.

The five failure modes of single-layer setups, by frequency:

1. BotID alone on a content-heavy site. A polite AI crawler fetches every blog post and every tool page once a week. None of those routes call checkBotId() (they have no business logic to protect), so BotID is silent. The invoice grows linearly with corpus size and crawler diversity.

2. WAF custom rules alone matching only known AI UAs. A new AI startup ships a crawler with a user-agent string nobody has catalogued yet. Your rule does not fire. The crawler exfiltrates the corpus before you update the rule. Cloudflare's managed list [9] gets ahead of this; a hand-rolled Vercel WAF rule lags.

3. Cloudflare alone, no BotID. Bot Fight Mode catches low-sophistication bots. The Playwright-driven credential stuffer that solves the JS challenge cleanly does not match Bot Fight Mode signatures, blows through to your Server Action, and runs a thousand fake login attempts. Cloudflare did not catch a sophisticated bot because the free tier does not catch sophisticated bots reliably. You need Super Bot Fight Mode (paid) or BotID on the login route.

4. Rate limiting alone, no client classification. A distributed scraper rotates through 500 residential IPs at one request per IP per minute. No IP exceeds your per-IP threshold. Your rate limiter says everything is fine. The aggregate scraper exfiltrates content uninterrupted. Rate limiting is a defense against repeated abuse from a known identifier; it is not a defense against unknown identifiers.

5. DDoS layer alone, no application-layer protection. A small distributed scraper running well below DDoS thresholds (a few hundred requests per minute total) is invisible to platform-wide volumetric protection. The DDoS layer does what it is named for; everything else needs application-layer logic.

The clean rule: classify per-route by what the route is exposed to. Expensive business logic exposed to authenticated and unauthenticated traffic gets BotID. Indexable but not-meant-to-be-scraped content (tool pages, calculators) gets a WAF user-agent rule plus, if scraping costs are real, an upstream block. Public APIs that return data anyone can have anyway (/api/og image generation, public RSS) get a generous rate limit and no BotID. For broader OWASP-aligned exposure framing, the OWASP Top 10 for Next.js and Supabase apps pillar maps each category to a Next.js failure mode.

What does SecureStartKit's bot-protection posture look like?

SecureStartKit ships an opinionated default that lines up with the decision matrix above. The routes that need BotID, the routes that need WAF rules, and the routes that need nothing are documented per file, not left to the operator to figure out.

The route classification:

Route surface	BotID?	Rate limit?	WAF UA rule?	Reason
/purchase (Stripe Checkout creation)	Yes (Deep Analysis)	Per-IP, 5/min	No	Triggers Stripe API call; bot abuse costs real money
/api/og (dynamic OG image generation)	No	Per-IP, 30/min	No	Public asset; bots crawling it is acceptable
Server Actions on /auth/*	Yes (Deep Analysis)	Per-IP, 5/min	No	Credential stuffing target
/tools/* (free utility pages)	No	Per-IP, 60/min	Yes (block AI UAs)	Scraper-attractive; no business logic to protect
/blog/* (content)	No	None	Yes (block AI UAs)	Indexable by search engines, not by training crawlers
Webhook endpoints (/api/stripe/webhook)	No	None	No	Signed-request validation handles authenticity (webhook signature pillar)

The implementation pattern:

// instrumentation-client.ts
import { initBotId } from 'botid/client/core'

initBotId({
  protect: [
    { path: '/purchase', method: 'POST' },
    { path: '/api/auth/sign-in', method: 'POST' },
    { path: '/api/auth/sign-up', method: 'POST' },
    { path: '/api/auth/reset-password', method: 'POST' },
  ],
})

The corresponding server side, for example on the Stripe Checkout creation Server Action:

// actions/billing.ts
'use server'

import 'server-only'

import { checkBotId } from 'botid/server'
import { headers } from 'next/headers'
import { z } from 'zod'

const checkoutSchema = z.object({
  priceId: z.string().startsWith('price_'),
})

export async function createCheckoutSession(formData: FormData) {
  const verification = await checkBotId()
  if (verification.isBot) {
    return { ok: false, error: 'Request rejected.' }
  }

  const parsed = checkoutSchema.safeParse({
    priceId: formData.get('priceId'),
  })
  if (!parsed.success) {
    return { ok: false, error: 'Invalid request.' }
  }

  // ... existing rate-limit check + Stripe API call
}

Three things to notice. First, import 'server-only' keeps the BotID server module out of any client bundle even by transitive import; this is the same barrier the environment variable leak prevention guide recommends across every server module. Second, BotID runs BEFORE Zod parsing; rejecting a bot is cheaper than parsing its (probably invalid) input. Third, the rate limit check still happens after BotID; the layers compose, they do not substitute.

For the tool pages and the blog, the posture is different: a Vercel WAF custom rule enumerates the documented AI scraper user-agents (Bytespider, GPTBot, ClaudeBot, CCBot, Amazonbot, Meta-ExternalAgent, GoogleOther, PetalBot, TikTokSpider, DuckAssistBot, Google-CloudVertexBot, Applebot) and serves a managed challenge on routes matching /tools/* and /blog/*. This is the cost defense for the scraper-attractive surface; BotID would not catch these clients because they identify themselves honestly.

If the WAF is too coarse and a scraper is actively running up the bill, Cloudflare orange-cloud becomes the next lever, with the Vercel-side accuracy tradeoffs from Section 5 understood and accepted. The pre-launch security audit covers the broader checklist this fits into; the SaaS security checklist tool is the operator-facing version of the same review.

Bot protection in 2026 is not a security checkbox you add at launch. It is the cost defense for the indie SaaS economic model when the public surface is permanently exposed to crawlers that pay nothing per request and platforms that bill per request. The architecture that wins is the one that classifies routes by what they actually expose: business logic gets BotID, scrape-attractive content gets a WAF rule, public APIs get a rate limit, webhooks get signature verification. Defaults set per route, not per site. The platform makes those defaults cheap and easy; the operator just has to pick which one each route deserves before the invoice picks for them.

For SecureStartKit's complete take on shipping a secure SaaS without these patterns being an after-the-fact retrofit, the pricing page names the architectural defaults the template ships with.