What does the NEXT_PUBLIC_ prefix do?

It tells Next.js the variable is safe to expose to the browser. Never put a secret behind NEXT_PUBLIC_ — anything with that prefix ends up in your client bundle for anyone to read.

Are server components enough to keep my key safe?

Only if the key is read in server code and never passed to a client component. A secret fetched in a server component but handed down as a prop can still leak.

Is your v0 app secure? Common security gaps and how to close them

v0 is great at the UI and the happy path. The security wiring underneath is still yours to check. Here's what to look for.

Updated June 22, 2026 · 4 min read

Check your own app in 30 seconds — free, no login:

Passive scan of your app's public files only — no login, nothing stored, your code never leaves your machine. Scan only apps you own.

What v0 does and doesn't cover

v0 is excellent at generating clean React and Next.js front-ends, and Next.js gives you a real place to keep secrets — server components, route handlers, and server-only environment variables. That's an advantage over tools that run everything in the browser.

But the advantage only helps if the secret actually ended up on the server. When you ask v0 to 'connect Stripe' or 'add OpenAI', it's easy to end up with the key in a client component, where Next.js will happily ship it to the browser. The framework gives you a safe place; it doesn't force you to use it.

The gaps to check

Keys in client components. In Next.js, anything in a file with 'use client' (or imported by one) can reach the browser. A secret key read there — or exposed via a NEXT_PUBLIC_ variable — is public. Secrets belong in server code and in env vars without the NEXT_PUBLIC_ prefix.

Backend access rules. v0 apps often pair with Supabase or a hosted Postgres. The database is only as safe as its row-level rules — verify RLS is on and scoped to each user.

Server-side checks. Authorization (is this user allowed to do this?) must run on the server, in your route handlers or server actions — never decided in the browser.

Verify it in 30 seconds

Run your deployed v0 app's URL through VibeShield. It reads the public JavaScript your app already serves and flags any exposed secret keys or detectable open-backend setups, with a clear fix for each.

For anything it finds, move the secret into a server route, rotate the leaked key, and re-deploy. Then re-scan to confirm the bundle is clean.

Frequently asked questions

What does the NEXT_PUBLIC_ prefix do?: It tells Next.js the variable is safe to expose to the browser. Never put a secret behind NEXT_PUBLIC_ — anything with that prefix ends up in your client bundle for anyone to read.
Are server components enough to keep my key safe?: Only if the key is read in server code and never passed to a client component. A secret fetched in a server component but handed down as a prop can still leak.

Don't guess — scan it

VibeShield checks your live app for exposed keys and open databases in about 30 seconds, and hands you the fixes.