Firewall & WAF

Vercel's layered firewall — automatic DDoS mitigation, the Web Application Firewall, custom rules, rate limiting, IP blocking, and managed rulesets.

The Security page introduces the firewall at a high level. This page goes deeper into how it actually works and how to configure it.

A layered model

Vercel's firewall has two layers that work together:

Platform-wide firewall — automatic mitigation of network-level (L3/L4) attacks like DDoS and SYN floods. It's on for every project on every plan, including Hobby, with no configuration. You don't manage it; it just runs.
Web Application Firewall (WAF) — the customizable layer where you define rules to log, block, challenge, or rate-limit application-level (L7) traffic.

Both sit at the edge in the request path, so once enabled, a request can't slip past them. The platform layer evaluates first (system mitigations), then your WAF custom rules in the order you've arranged them.

A useful billing detail: you aren't charged for traffic blocked by DDoS mitigation or the WAF. Denies, challenges, and rate-limits from your rules don't incur request or bandwidth usage — you only pay for requests actually served before mitigation kicks in.

Custom rules

A custom rule is an if/then: one or more conditions, and an action to take when they match. You can build rules step-by-step in the dashboard or describe them in natural language ("rate limit /api/login to 10 requests per minute, then challenge").

Actions: log, deny, challenge, bypass, rate_limit, and redirect.

Match parameters (15+): host, path, query, method, route, IP address, header, cookie, user agent, environment, region, geo (continent / country / city), and JA4 TLS fingerprint (JA3 is legacy and Enterprise-only).

Changes apply globally in about 300ms with no redeploy, and you can instantly roll back to a previous firewall configuration if a rule misbehaves — the same instant-revert principle as deployments.

Test before you enforce. Publish a rule with the log action first and watch the Firewall dashboard to see what would be affected. Once you're confident the condition is right, switch the action to challenge or deny. A deny with a loose condition (e.g. path starts with /) blocks your whole site, so always review the matched traffic first.

Persistent actions

By default, blocking one request doesn't block the next request from the same client unless it also matches. Persistent actions fix that: attach a time-based block to a challenge or deny action, and any client that triggers it is blocked for the duration you set. The block is applied at the platform-firewall level before the request is processed, so those blocked requests don't count toward usage. Persistent actions are a Pro and Enterprise feature.

Rate limiting

A rate-limit rule caps how many requests a client can make in a time window, then applies a follow-up action (log, deny, challenge, or return 429). You configure the algorithm, the window, the request limit, and the tracking key.

By default the key is the client IP. For application-level limits — per authenticated user, per organization — use the Rate Limiting SDK (@vercel/firewall) with a custom rateLimitKey:

import { checkRateLimit } from '@vercel/firewall';

const { rateLimited } = await checkRateLimit('login-attempts', {
  rateLimitKey: userId, // bucket per user instead of per IP
});
if (rateLimited) return new Response('Too many requests', { status: 429 });

Tune gently: start with a limit several times higher than legitimate traffic and the action set to log, review the data, then tighten.

IP blocking

IP blocks deny an address or CIDR range outright, and run earlier in the request lifecycle than custom rules. There are two scopes: project-level and account-level. Account-level CIDR rules are capped at /16 for IPv4 and /48 for IPv6. Use IP blocking for known-bad sources; use a custom rule when the decision depends on more than the address.

Managed rulesets

Rather than writing everything yourself, you can enable Vercel-maintained rulesets:

OWASP Top 10 protection — common risks like SQL injection and cross-site scripting.
Bot Protection — challenges non-browser traffic (covered in Security).
AI Bots — detect and optionally block AI crawlers.

Each can run in log mode (observe) or challenge/deny mode (enforce).

Configuring in `vercel.json`

Most teams manage the firewall in the dashboard, but you can version-control a subset of WAF rules in vercel.json via the routes property. Only deny, challenge, and rate_limit actions are supported there — log, bypass, and redirect are dashboard-only:

{
  "$schema": "https://openapi.vercel.sh/vercel.json",
  "routes": [
    {
      "src": "/(.*)",
      "has": [{ "type": "header", "key": "x-unwanted-header" }],
      "mitigate": { "action": "deny" }
    }
  ]
}

From the CLI

After linking a project, you can inspect and stage firewall changes from the terminal:

vercel firewall overview               # active rules, blocks, attack mode, drafts
vercel firewall diff                   # show unpublished draft changes
vercel firewall rules inspect "Name" --expand

Staged changes require an explicit publish, so review the diff before applying.

Monitoring

Every project's sidebar has a Firewall tab with a live traffic view, letting you see what's being allowed, challenged, and blocked, and set alerts. You can group traffic by parameters like JA4 digest to spot patterns. This pairs directly with Observability when you're investigating an anomaly. For sustained targeted attacks, layer on Attack Challenge Mode.

Plan notes

The WAF is available on all plans, but feature limits vary — for example, Hobby projects are capped at 3 total custom rules, and persistent actions require Pro or Enterprise. Limits change over time, so confirm current values on vercel.com and see Pricing & plans.

Firewall & WAF

On this page