Is my v0 app secure?

v0 generates a Next.js application — typically React with Tailwind and shadcn/ui components — that you deploy on Vercel. Next.js runs code in two very different places: on the server (Server Components, route handlers, server actions) and in the browser (Client Components, marked with "use client"). Everything that runs in the browser is public.

That split is the heart of Next.js security, and it is where most v0 gaps appear. Put a secret on the wrong side of the line and it ships to every visitor. Get the line right and the same app is safe. The two levers to check are environment variable naming and the server/client boundary.

Next.js has one rule that decides whether a value is exposed: the NEXT_PUBLIC_ prefix. Any variable with that prefix is inlined into the browser bundle and readable by anyone. Any variable without it is available only to server-side code and never reaches the browser.

Fine as NEXT_PUBLIC_

Values meant to be seen: a Supabase project URL, a Supabase anon key, a public analytics id.

Must NOT be NEXT_PUBLIC_

A Stripe secret key, a Supabase service_role key, an AI provider API key, a database connection string, or any private token. Give these plain names (for example STRIPE_SECRET_KEY) and read them only in server code.

If a secret already shipped with a public prefix, treat it as leaked: see public .env files and what to do if a secret leaked.

Even with correct naming, a secret leaks if you use it in the wrong place. The moment you reference a private key inside a component marked "use client", it has to be sent to the browser to run. Calls to paid APIs, your database with elevated rights, or any privileged service must happen on the server.

• Search your project for "use client" and confirm none of those files read a secret or call a privileged API directly.

• Move privileged calls into a Server Component, a route handler (app/api), or a server action.

• Treat anything fetched or computed in client code as visible to the user — because it is.

If your v0 app talks to Supabase or another database, the UI is not what keeps data safe. With Supabase specifically, an exposed anon key is normal — your protection is Row Level Security. If you connect to a database from the server with a privileged credential, then your server code is responsible for checking that the current user is allowed to see each record.

• Using Supabase: enable RLS on every table with real data and scope each policy to the right user.

• Using a server-side DB connection: verify the logged-in user owns the record on every read and write.

• Never expose a database service_role key or connection string to the browser.

For Supabase specifics, see the Supabase RLS checklist; for the access boundary in general, the authentication security checklist.

v0 apps deploy on Vercel, and a few platform settings matter at launch: environment variables must be set for the Production environment (not only Preview), and preview deployments expose work-in-progress at public URLs. These and more are covered in the Vercel security checklist, which pairs directly with this guide.

• No secret uses a NEXT_PUBLIC_ name — only genuinely public values do.

• No "use client" component reads a secret or calls a privileged API directly.

• Privileged work runs in Server Components, route handlers, or server actions.

• Supabase RLS is on (or server-side authorization checks ownership) for all real data.

• Vercel environment variables are set for Production, and preview URLs don't expose anything sensitive.

• Login, logout, and password reset work, and one user cannot reach another's data.

• HTTPS is enforced, security headers are present, and you scanned the live URL.

The tool-agnostic master list is the launch security checklist for vibe-coded apps, with header details in the HTTP security headers checklist.

GuardMint scans your deployed app from the outside and reports what is visible there; the methodology page explains the scope.

• Detects keys exposed in the browser bundle, including anything mistakenly given a NEXT_PUBLIC_ name.

• Looks for other leaked secrets and obviously open endpoints.

• Checks HTTPS, security headers, and other public launch-readiness signals.

Is a v0 app secure by default?

Not on its own. v0 produces clean Next.js code, but security depends on choices it cannot finalize for you: keeping secrets out of NEXT_PUBLIC_ variables, only reading those secrets in server-side code, and protecting your data with Row Level Security or server-side authorization. A v0 app can work perfectly while a secret is exposed or a database is open, so verify these before launch.

What does the NEXT_PUBLIC_ prefix do to security in a v0 app?

In Next.js, any environment variable named with the NEXT_PUBLIC_ prefix is inlined into the browser bundle and is fully public. Use it only for values that are meant to be seen, such as a Supabase project URL or anon key. A secret like a Stripe key, database service_role key, or AI API key must use a non-prefixed name and be read only in Server Components, route handlers, or server actions.

Where do v0 apps commonly leak secrets?

Two places: giving a secret a NEXT_PUBLIC_ name so it ships to the browser, and calling a privileged API from a Client Component, which forces the key into client code. The fix is to keep secrets non-public and move the call into server-side code. Reviewing which files are marked 'use client' is the fastest way to find the boundary.

How do I check my v0 app is safe to launch?

Confirm no secret uses a NEXT_PUBLIC_ name, that privileged calls happen in Server Components or server actions rather than client code, that your Vercel project's environment variables are set for production, and that your database uses Row Level Security or server-side authorization. Then run a free scan of the deployed URL to flag exposed keys and missing headers.