How to Set Up a WAF with Vercel Firewall

There is nothing to install. Vercel's firewall is already in front of your deployment, and it runs in two layers that you should understand before touching any settings:

• Platform-wide firewall (automatic, free, all plans): Provides DDoS mitigation at layers 3, 4, and 7. It blocks abnormal or suspicious request volumes with no configuration required and cannot be disabled.
• Vercel WAF (configurable): The layer you own. Here you define IP blocks, custom rules, and, depending on your plan, managed rulesets.

The firewall evaluates rules in a fixed execution order: DDoS mitigation first, then WAF IP blocking, then WAF custom rules, then WAF Managed Rulesets. Custom rules run in the order you arrange them, so precedence matters and you can reorder them.

Do not write blocking rules blind. Start by looking at real traffic so your conditions match what is actually hitting your site.

1. From your dashboard, select the project you want to protect.
2. Open Firewall in the project sidebar.
3. Use the traffic monitoring view and its live traffic window to group requests by parameter, for example by path, IP address, user agent, JA4 Digest, or country. This is the same observability surface you will use to validate every rule you write.

Identify the patterns you want to act on: a scraper's IP or ASN, a flood of requests to one API path, requests for files that should never exist such as .env or .git, or traffic from regions you do not serve.

IP blocking is the simplest and highest-precedence WAF control; it runs before your custom rules. Use it for known malicious addresses, scrapers, or competitors, not for geo restrictions (use a custom rule for geography instead).

1. In Firewall, select Configure at the top right.
2. Scroll to the IP Blocking section and select + Add IP.
3. Fill in the IP Address Or CIDR field and the Host field. The host is the exact domain the block applies to, entered without the https prefix, for example www.my-site.com. Add a separate entry for each subdomain you want to cover.
4. Select Create IP Block Rule, then Review Changes and Publish.

Project-level IP blocking is capped by plan: up to 3 on Hobby, up to 100 on Pro, and up to 1000 on Enterprise. Enterprise also offers account-level IP blocking from Team Settings, where CIDR rules are limited to /16 for IPv4 and /48 for IPv6.

Custom rules are the core of the Vercel WAF. Each rule is one or more If conditions combined with AND or OR, plus a Then action. Always build a new rule in log mode first so it records without blocking.

1. In Firewall, select Configure, then Add New... > Rule.
2. Name the rule so its purpose is clear later.
3. Add If conditions. Available parameters include Request Path and Target Path, Request Method, Hostname, IP Address, User Agent, Request Header, Cookie, Query, Geolocation (continent, country, region, city), AS Number, and the JA4 Digest TLS fingerprint (JA3 is Enterprise only). Operators include equals, not equals, contains, starts with, ends with, matches regex, exists, and is in set, and any operator can be negated.
4. Set the Then action to Log.
5. Select Save Rule, then Review Changes and Publish.

Example goals you can express directly: deny requests whose path ends in .php, .env, or .git; challenge requests whose user agent contains curl or wget; or deny traffic from countries you do not serve.

This is the step most people skip and regret. With the rule live in log mode, watch how it behaves against real traffic before you let it block anything.

1. On the Firewall overview page, select your rule from the traffic grouping dropdown and pick the parameters tied to your conditions.
2. Observe roughly 10 minutes of live traffic. Confirm the rule matches the abusive requests you intended and does not catch legitimate users.
3. If the match set is wrong, edit the conditions and observe again.
4. Once you are satisfied, select Configure, open the rule, and change the Then action to Challenge, Deny, or Bypass as appropriate. Save, review, and publish.

Know what each action does: Deny returns 403 Forbidden and the request never reaches your app (and is not billed as an Edge Request or Fast Data Transfer). Challenge serves a Vercel Security Checkpoint that only a real JavaScript-capable browser can pass, creating a 1-hour session. Bypass lets trusted traffic skip the remaining rules.

Rate limiting is a custom rule whose action is Rate Limit. Use it to cap requests from a single source to an endpoint, which protects APIs and login forms and helps control usage costs.

1. Create a new rule and add If conditions that scope it, for example Request Path starts with /api or equals /auth/login.
2. Set the Then action to Rate Limit.
3. Choose the limiting strategy: Fixed Window (all plans) or Token Bucket (Enterprise).
4. Set the Time Window (defaults to 60s) and the Request Limit (defaults to 100 requests per window).
5. Choose the counting key(s): IP and JA4 Digest are available on all plans; User Agent and arbitrary Header keys are Enterprise only.
6. Choose the action when the limit is exceeded: leave the Default (429) response, or select Log, Deny, or Challenge. Save, review, and publish.

Windows range from a 10s minimum to a 10 minute maximum on Hobby and Pro, and up to 1 hour on Enterprise. Rate limit rule counts are capped per plan: 1 rule on Hobby, 40 on Pro, and 1000 on Enterprise.

A normal deny or challenge rule only acts on requests that match its condition. A client that trips the rule once can still send other requests that do not match. Persistent actions close that gap by adding a time-based IP block.

1. Edit (or create) a custom rule whose action is Challenge, Deny, or Rate Limit.
2. In the action row, use the for timeframe dropdown (it defaults to 1 minute) to select how long to block the offending client.
3. Save, review, and publish.

When the rule matches, the client's IP is stored in the platform-wide firewall and blocked for the timeframe you chose. Because that block happens before the firewall processes further requests, the blocked traffic does not count toward your CDN and traffic usage. This is ideal for brute-force protection, for example rate limiting POST /auth/login to 10 requests per minute per IP and denying for 15 minutes.

Managed Rulesets are predefined collections you enable rather than author, and they run after your custom rules in the execution order. The OWASP Core Ruleset requires Enterprise, while the Bot Protection managed ruleset is generally available on all plans at no additional cost. Vercel's docs are not fully consistent here (the WAF limits table still marks managed rulesets as unavailable on Hobby and Pro, whereas the Bot Protection GA announcement says all plans), and the AI Bots ruleset tier is less clearly documented, so confirm what your plan includes before relying on it.

• OWASP Core Ruleset: Rules based on the OWASP Top Ten. Enable the whole set, or open Configure to toggle individual rules and set each one to Log or Deny.
• Bot Protection Managed Ruleset: Inactive by default (shown as Off). Set it to Log or Challenge; in challenge mode the WAF serves a JavaScript challenge to traffic unlikely to be a browser.
• AI Bots Managed Ruleset: Inactive by default (shown as Allow). Set it to Log or Deny to monitor or block traffic identified as AI crawlers.

Enable and configure these from Firewall > Rules in the project sidebar, then review and publish. As with custom rules, start each in Log and watch live traffic before switching to Challenge or Deny.

Attack Mode is an emergency toggle for highly targeted attacks. When enabled, every browser visitor must pass a security challenge before reaching your site, while known legitimate bots (search engines, webhook providers) and your own internal Function and Cron traffic are allowed through automatically.

1. Open Firewall in the project sidebar.
2. Click Bot Management.
3. Under Attack Mode, select Enable.
4. When the attack subsides, return here and select Disable.

Attack Mode is free on all plans, and requests it blocks do not count toward your usage. It will not hurt SEO, since crawlers like Googlebot are allowed through. Because the platform already mitigates DDoS automatically, reserve Attack Mode for active, targeted incidents rather than leaving it on permanently.

Dashboard changes are instant and need no deploy, but you can also version firewall rules with your codebase. In vercel.json, use the routes property with has or missing conditions and a mitigate action:

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

Only challenge and deny are supported in vercel.json; the log, bypass, and redirect actions are dashboard-only. Note the tradeoff: vercel.json rules ship with a deployment, whereas dashboard rules apply globally within 300ms with no re-deployment. For scripted or CI-driven management, the Firewall API (via the @vercel/sdk examples, using vercel.security.updateFirewallConfig) can create and update rules programmatically.

Whichever path you use, you can recover fast: open the ellipsis menu on the Firewall overview, choose View Audit Log, pick a prior version by date and time, and select Restore to instantly roll back the configuration.