Vercel

Vercel deployment security checklist for AI-built apps

Vercel makes deployment invisible — push and it's live. That convenience hides a few sharp edges that AI-generated apps hit constantly. Check these before your next deploy.

1. The NEXT_PUBLIC_ trap

Any environment variable prefixed NEXT_PUBLIC_ is bundled into your frontend JavaScript — visible to every visitor. AI tools regularly put real secrets behind that prefix because it "makes the error go away." Rule: NEXT_PUBLIC_ is for genuinely public values only (your Supabase anon key qualifies; your service key never does). Audit your Vercel env vars for misplaced secrets and rotate any you find.

2. Server-side secrets belong in env vars

Keys used by API routes and server components go in Vercel's environment variables without the public prefix — set per environment (Production / Preview / Development), never hardcoded.

3. Security headers

Vercel doesn't add HSTS, CSP, or X-Frame-Options for you. Add them in vercel.json or next.config.js — five minutes of config that blocks whole attack classes like clickjacking.

4. Preview deployments leak too

Every branch gets a public preview URL. If your preview environment points at production data, anyone who guesses or finds the URL sees it. Use separate preview credentials, or protect previews with Vercel's deployment protection.

The pre-deploy checklist

• No secrets behind NEXT_PUBLIC_ — audit and rotate offenders
• Server keys in env vars, scoped per environment
• Security headers configured and verified on the live URL
• Preview deployments use non-production data or protection
• Code scan + live URL scan pass with no criticals

VibeSafe's live URL scan checks your deployed Vercel app for missing headers, exposed paths, and CORS misconfiguration — no code access needed.

Related: