Is Vercel secure?
Vercel is a well-run platform, and asking whether it is secure is usually asking the wrong question. What matters is what your deployment exposes — and the defaults that catch people out are the ones that make development pleasant: environment variables that are inlined into the browser bundle on purpose, source maps that are helpful in preview and revealing in production, and security headers that are yours to configure because nothing can guess them for you.
Run a free scan
Get a graded security report for your Vercel app in under a minute.
Why Vercel apps are commonly at risk
- Any variable prefixed `NEXT_PUBLIC_` is inlined into the client bundle by design — the prefix is the only thing standing between a secret and every visitor.
- Source maps make production JavaScript readable, and a build can emit them without anyone deciding to.
- Security headers are not set by default; they come from your `next.config` or `vercel.json` and nowhere else.
- Preview deployments are real, reachable URLs — an unprotected one serves a build that was never meant for the public.
- A build that references a preview or localhost origin ships that reference to production.
Top security risks in Vercel apps
A secret behind a NEXT_PUBLIC_ prefix
HighThe prefix means “inline this into the browser”. A key that belongs on the server, given that prefix by an AI assistant that could not tell publishable from secret, is published to every visitor — and nothing breaks, so nothing signals it.
Source maps served in production
LowPublished source maps reconstruct your original source from the minified bundle, including comments and internal structure. Rarely a vulnerability on its own; reliably a shortcut to finding one.
No security headers on the deployment
MediumWithout a Content-Security-Policy, HSTS and frame protection, the deployment leaves XSS, downgrade and clickjacking open. Vercel serves whatever your config declares, and an app scaffolded by a generator usually declares nothing.
Preview or localhost origins in a production build
MediumA production bundle that still points at a preview deployment or `localhost` either breaks for users or quietly routes real traffic somewhere it should not go.
How to fix Vercel security gaps
Audit every NEXT_PUBLIC_ variable
Treat the prefix as a publication decision. Anything that is a credential belongs in a server-only variable and should be reached through a route handler or server action, never inlined.
Turn off production source maps
Set `productionBrowserSourceMaps: false` in `next.config` (it is the default — confirm a generator has not switched it on) and verify no `.map` file is served from your deployed origin.
Declare headers in config, not per route
Add HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and a CSP in the `headers()` function in `next.config`, or in `vercel.json`, so they apply to every response rather than the ones someone remembered.
Protect preview deployments
Use deployment protection so preview URLs are not publicly reachable, and keep environment values that differ between preview and production genuinely separate.
How do you make a Vercel app rank in Google and AI search?
Securing the app is half the job; the other half is being found. AI engines — ChatGPT, Claude, Perplexity — only cite what their crawlers can read.
Server-render the routes you want read
A client-rendered app on Vercel returns an empty root element to crawlers that do not run JavaScript. Use server components or static generation for content routes so GPTBot, ClaudeBot and PerplexityBot receive real HTML.
Allow AI crawlers and ship a sitemap
Allow GPTBot, OAI-SearchBot, ClaudeBot and PerplexityBot in robots.txt and point them at your sitemap so answer engines can discover your pages.
Give every route its own metadata
Use the Metadata API per route rather than one shared title, and add Organization + WebSite JSON-LD so engines resolve your app as an entity.
Check that AI crawlers are not blocked
ShipReady reports which AI crawlers your robots.txt disallows, and whether your host blocks a GPTBot request outright — the access problems worth ruling out before anything else.
Deep dives: Secret published through a browser-exposed environment variable·Exposed JavaScript Source Map
Vercel security: related guides
FAQ
- Is Vercel secure?
- As a platform, yes — Vercel operates the infrastructure and publishes its own security posture and certifications. That is a different question from whether the application you deployed on it is secure, which depends entirely on your configuration: which variables you exposed to the browser, whether you declared security headers, and whether preview builds are reachable. This guide is about the second question, because it is the one you control.
- Is it safe to put a key in a NEXT_PUBLIC_ variable?
- Only if the key is meant to be public — a Supabase anon key or a Firebase config, for example, both of which are designed to ship in the client. Anything else, including a service_role key, a Stripe secret key or a provider API key, must not carry that prefix. The prefix does not protect the value; it publishes it.
- Are Vercel preview deployments public?
- A preview deployment is a real URL and is reachable by anyone who has it unless you enable deployment protection. That matters when a preview points at production data or carries a build that was never reviewed. Treat preview URLs as public until you have deliberately made them otherwise.
Don't guess. Scan your Vercel app now.
100+ checks. 30 seconds. Free — with an AI-ready fix prompt for every critical and high finding.