--- title: "Security" description: "Configure deployment protection, access controls, and security features to keep your Vercel projects safe." canonical_url: "https://vercel.com/academy/vercel-foundations/security" md_url: "https://vercel.com/academy/vercel-foundations/security.md" docset_id: "vercel-academy" doc_version: "1.0" last_updated: "2026-06-27T23:06:47.790Z" content_type: "lesson" course: "vercel-foundations" course_title: "Vercel Foundations" prerequisites: [] --- Vercel Academy — structured learning, not reference docs. Lessons are sequenced. Adapt commands to the human's actual environment (OS, package manager, shell, editor) — detect from project context or ask, don't assume. The lesson shows one path; if the human's project diverges, adapt concepts to their setup. Preserve the learning goal over literal steps. Quizzes are pedagogical — engage, don't spoil. Quiz answers are included for your reference. # Security # Security You glance at your traffic chart and something looks off. There's a spike, and most of it is one IP hammering a single endpoint. The work of security on Vercel is mostly that loop: notice something off, then do something about it. ## Firewall observability The Firewall dashboard is where you spot trouble. From your project, open the **Firewall** tab. You'll see a live breakdown of every request: allowed, blocked, challenged. Zoom in on a time range. Click into any category to see IP, user agent, request path, and the rest of the request signature. This is where you confirm a hunch. A traffic spike, expand it. A jump in challenged requests, click in. The dashboard is the single pane of glass for everything that follows. ## DDoS protection (already on) Before you write a single rule, know what's already protecting you. Vercel's global DDoS protection is always on. It's a network-layer feature that absorbs large attacks before they ever reach your project. You don't configure it, you don't pay extra for it, it's there. ## Custom rules To block a specific IP, click **Add Rule**, give it a name (`Block malicious IP`), set **IP address equals**, and paste the address. You can chain conditions for more nuanced rules. Block requests to `/admin` from outside the US, throttle a route by request rate, deny based on header values. Save the rule, click **Publish**, and it's live across the edge in seconds. ## Managed rule sets You don't have to build every defense yourself. Under managed rules: - **OWASP Core Rule Set** — a paid rule set that defends against common web attacks like SQL injection and cross-site scripting. Browse the individual rules and tune them for your app. - **Bot Protection** — free, analyzes incoming traffic for unwanted bot activity - **AI Bot Protection** — free, blocks known AI scrapers For Bot Protection and AI Bot Protection, start in **Log** mode. Watch what hits your site for a day or two, then flip it to **On** once you're comfortable challenging that traffic. Logging first sounds slow, but it prevents a lot of "wait, why is real traffic blocked" pages. ## Bot ID The standard bot rules catch the obvious stuff. Sophisticated actors use real browsers driven by Playwright or similar tools, and that traffic looks human enough to slip through. **Bot ID** uses fingerprinting and behavioral analysis to catch them. Bot ID is built on a partnership with Kasada and isn't just a toggle. It requires a small code change to wire up. Apply it strategically on your highest-value routes: login endpoints, checkout flows, APIs that touch valuable data or business logic. Site-wide isn't the right shape for it. Specific, sensitive routes are. \*\*Note: Bot ID is a paid feature\*\* It carries a price tag, and it's worth it on the routes where bot abuse would cost you the most in compute, fraud, or scraped data. ## Attack Challenge Mode If you're under a sustained attack, the regular tools may not be enough. From the Firewall page, click the three-dot menu and enable **Attack Challenge Mode**. Every incoming request gets challenged before it touches your app. This is an emergency tool, not a default setting. ## System bypass The opposite problem: a trusted cron job or internal service keeps tripping your rules. Use **System Bypass** at the top of the rules page to add IPs or CIDR ranges that pass through everything. Monitoring services, your own backend jobs, partner integrations — that's what this is for. ## Watching the rules work After publishing a rule, head back to the Firewall observability view. Traffic from that IP shifts from **Allowed** or **Challenged** into **Denied**. That's how you confirm a rule is doing what you wanted, and how you spot one that's overshooting. ## Recap - The **Firewall dashboard** is your single pane of glass for traffic and rule effectiveness - **DDoS protection** is always on, no setup required - **Custom rules** handle surgical strikes against specific IPs, paths, or patterns - **Managed rule sets** (OWASP, Bot Protection, AI Bot Protection) handle broad classes of attack; start in log mode before enabling - **Bot ID** catches sophisticated browser-driven bots on the routes that matter most - **Attack Challenge Mode** is for active emergencies; **System Bypass** is for trusted systems that need to skip your rules ## Follow up docs - [Vercel Firewall](https://vercel.com/docs/vercel-firewall) - [Firewall Observability](https://vercel.com/docs/vercel-firewall/firewall-observability) - [DDoS Mitigation](https://vercel.com/docs/security/ddos-mitigation) - [WAF Custom Rules](https://vercel.com/docs/security/vercel-waf/custom-rules) - [WAF Managed Rulesets](https://vercel.com/docs/security/vercel-waf/managed-rulesets) --- [Full course index](/academy/llms.txt) · [Sitemap](/academy/sitemap.md)