Is v0 secure? Keeping a generated Next.js app's secrets in
v0 turns a prompt into a polished Next.js app, and the output looks production-ready — which is exactly the problem. "Is v0 secure?" comes down to whether the generated app keeps its secrets on the server, and Next.js makes that easy to get subtly wrong.
v0 is a capable tool that writes real Next.js. The gaps aren't in the framework; they're in the seams the generator doesn't always mind — and Next.js has two seams that leak secrets if you cross them.
The NEXT_PUBLIC_ prefix ships to everyone
In Next.js, any environment variable prefixed NEXT_PUBLIC_ is deliberately baked into the client bundle and sent to every visitor's browser. That's correct for a public value like a Supabase anon key. It's a leak the moment a secret ends up behind that prefix.
NEXT_PUBLIC_ variable isn't hidden by .env — the prefix tells Next.js to publish it. Secrets take plain, un-prefixed names and are read only on the server. Grep your build for NEXT_PUBLIC_ and make sure nothing sensitive rides along.The server/client component seam
Next.js splits code into server and client components. Anything in a "use client" component — or imported by one — can end up in the browser bundle. Read a secret there and it ships, even without a NEXT_PUBLIC_ prefix.
Secrets belong in server components, route handlers, and server actions, where the code runs on your machine and only the result crosses to the client. A generator focused on making the UI work doesn't always keep that line clean — it's the first thing to check.
Route handlers still need their own auth
A slick UI can hide an action from users who shouldn't see it, but the route handler behind it is still a public endpoint. If it doesn't re-check who's calling, anyone can hit it directly and skip the interface. Every server action and route handler re-verifies auth on the server — the UI is not the guard.
And if it wired up Supabase
If your v0 app stores data in Supabase, everything about Row Level Security applies here too — the public anon key is only safe behind real RLS policies. The whole Supabase side is in how to secure a Supabase app.
Audit your v0 app
My app was built with v0 (Vercel's v0.dev) and is a Next.js app. Audit it for the security gaps v0-generated Next.js apps commonly ship with, and give me the exact fix for each. 1. Env vars: list every environment variable prefixed with NEXT_PUBLIC_ and confirm NONE of them is actually a secret — because NEXT_PUBLIC_ vars are baked into the client bundle and shipped to every visitor. Flag any secret that's exposed this way. 2. Server vs client components: check whether any secret (API key, database URL, private token) is read inside a "use client" component or otherwise reaches client-side code. Secrets must only be used in server components, route handlers, or server actions. 3. If it uses Supabase: is Row Level Security enabled on every table, with policies that actually restrict rows to the owning user — not off, and not an allow-everyone policy? 4. Route handlers / server actions: does each one re-check auth and authorization on the server, rather than trusting that the UI wouldn't have shown the action? For each finding, give me the file, the risk in one sentence, and the exact code fix.
This is the v0-specific cut of the pattern behind every AI-built app — the cross-cutting version is vibe coding security risks, and the general exposed-key case is my API key is showing on my website.
Check the outside view too
free tool · no loginSecurity headers checkScan your v0 app's live URL for the security headers a generator leaves unset — clickjacking, sniffing, and downgrade protection. No login.Keep the secrets server-side. Then watch the live app.
The audit above secures your v0 app now. Tell Me When Down watches it after — SSL that lapses, a URL that starts erroring, a site that goes down — free, no card, so a quiet change doesn't become a public one.
spot something wrong or out of date? [email protected] — we'll fix it