Vercel handles TLS, CDN caching, and infrastructure scaling, but it does not add application-level security headers, protect your API routes, or restrict preview deployments for you: those are configuration you (or your framework) have to set explicitly, and a fast prompt-to-deploy workflow rarely stops to add them.
Why this happens on Vercel
Vercel is the hosting layer under a large share of AI-generated frontends, most commonly Next.js. Because deployment itself is instant and mostly invisible, it's easy to assume the platform is handling security the same way it handles TLS and CDN. It isn't, beyond the transport layer.
Every push to a connected repo produces a live URL automatically. That's a huge productivity win and also means there's no manual "go live" step where someone might otherwise pause and check what's being exposed.
Common issues on Vercel deployments
What actually shows up across Vercel-hosted apps:
- No security headers configured: Vercel serves whatever headers your app or framework sets; without an explicit headers() config (or framework-level middleware), there's no Content-Security-Policy, HSTS, or clickjacking protection by default.
- Environment variables exposed via the wrong prefix: in frameworks like Next.js, any environment variable prefixed for client exposure (e.g. NEXT_PUBLIC_) ships to the browser bundle; a variable meant to stay server-only that gets the public prefix by mistake leaks exactly the same way.
- Preview deployments reachable without protection: every push can generate a public preview URL; Vercel offers deployment protection (password or SSO) but it isn't the default, so a preview of an in-progress feature can be reachable by anyone with the link.
- API routes with no rate limiting or auth: a serverless API route is publicly reachable the moment it's deployed; Vercel doesn't add auth or rate limiting on your behalf.
How to fix it
Most of this is one-time project configuration:
- Add security headers via your framework's config (e.g. headers() in next.config.js) so they apply to every route automatically.
- Audit every environment variable's prefix and confirm only genuinely public values use the client-exposed naming convention.
- Turn on Deployment Protection (Project Settings → Deployment Protection) for preview environments that touch real or sensitive data.
- Add explicit auth checks and rate limiting to any API route that isn't meant to be fully public.
Frequently asked
Does Vercel's CDN or edge network add any application security?
It handles TLS termination, caching, and DDoS mitigation at the infrastructure level, but it doesn't inspect or restrict what your application code does, add security headers, or enforce auth on your routes. That's all application-level configuration.
Are preview deployments as exposed as production?
Yes, by default. A preview URL is a fully live, publicly reachable deployment unless you've explicitly enabled Deployment Protection. It runs the same code against the same environment variables as any other deployment of that branch.