Vibe Coding

'It works on Vercel': the serverless security myths

The platform is good — that is where the myth starts

Deploying on Vercel, Netlify or a similar platform is genuinely a security upgrade in many ways. You inherit automatic HTTPS, patched and hardened infrastructure, sane network defaults, and DDoS protection you did not have to configure. None of that is marketing — it is real work the platform does so you do not have to.

The myth is the quiet leap from 'the platform secures the infrastructure' to 'the platform secures my app.' Those are different layers, and the second one is still yours.

What the platform genuinely covers

Give credit where it is due. On a good serverless host you typically get:

  • HTTPS provisioned and renewed for you.
  • Servers and runtimes kept patched.
  • Network-level hardening and isolation between deployments.
  • Sensible defaults that beat a hand-rolled server in a lot of cases.

If your mental model is 'a VPS I have to babysit,' the platform is a real improvement. The mistake is stopping there.

What is still entirely yours

The platform runs your code faithfully — including its mistakes. It cannot know your intent, so the application layer stays your job:

  • Your secrets. Environment variables are safe on the server, but a key referenced in client-side code still ships to the browser. The platform will not stop you from exposing it. On many frameworks a public-prefixed variable is meant to be exposed — easy to misuse.
  • Security headers. CSP, X-Content-Type-Options, X-Frame-Options, HSTS — these are not set for you. Absent unless you add them.
  • Auth and access logic. Whether an API route checks who is calling it is your code. The platform happily serves an endpoint that forgot to authorize.
  • Your dependencies. A vulnerable or compromised package runs just as smoothly on serverless as anywhere.
  • Input handling. Injection, unsafe rendering, missing validation — all application logic, all yours.

Why this trips up fast builders

This is not carelessness, and the platform is not at fault. When you ship quickly with AI assistance, the code that gets written is the code you asked for — the feature — not the security you did not mention. The AI writes the feature; the host runs it; both did their job. Nobody in that loop was assigned the headers, the auth check, or keeping the key off the client. 'It deployed' becomes a false signal of 'it is safe.'

The honest mental model

Think of it as a clean split: the platform owns the infrastructure, you own the application. A successful deploy proves your app runs. It says nothing about whether a secret is exposed, an endpoint is unprotected, or your headers are missing. Those are normal hygiene items — not a crisis — but they are checked by you, not by the deploy.

Check the part the platform does not

The gaps that survive a perfect deploy are exactly the ones you cannot see from the dashboard. An automated scan reads your live site the way a visitor — or a bot — would, and reports exposed secrets, missing headers and reachable files. Scan your site and see what the platform did not cover.

Related reading

FAQ

Does Vercel handle security for me?
It handles infrastructure security — HTTPS, patched servers, network hardening — which is real and valuable. It does not handle your application: your secrets, security headers, auth logic, dependencies and input handling remain your responsibility regardless of the platform.
Are my environment variables safe on serverless platforms?
Server-side environment variables are kept off the client. But a variable referenced in client-side code, or one with a public prefix, still ships to the browser. The platform will not stop you from exposing a secret that way.
Does a successful deploy mean my app is secure?
No. A successful deploy means your app runs. It says nothing about exposed secrets, missing security headers, or unprotected endpoints. Those are application-level concerns the platform does not check for you — they need a separate review.