v0 app security: keep secrets on the server

By the FixMyVibe team · Last reviewed 16 October 2026
v0 generates Next.js apps, where an environment variable prefixed with NEXT_PUBLIC_ is inlined into the browser bundle and readable by anyone. Keep every private key without that prefix, use it only in server code (Route Handlers, Server Actions), and if the app uses Supabase, make sure RLS protects every table.
How v0 handles keys
v0 uses the environment variables of the Vercel project attached to your chat. Its security docs build on the Next.js split: variables without NEXT_PUBLIC_ remain on the server, and only variables with that prefix are exposed to the browser. Next.js does this by replacing process.env.NEXT_PUBLIC_… references with the literal value in the JavaScript bundle during next build.
The typical risks
1. A private key behind NEXT_PUBLIC_
If a model key, Stripe secret key or Supabase secret key is named NEXT_PUBLIC_… to make a client component work, it ships to every visitor. v0's own guidance: never expose sensitive tokens with the NEXT_PUBLIC_ prefix. Move the call to a Route Handler or Server Action instead.
2. A key hardcoded in the code
A key typed straight into a file ends up in your repository and, if it's in client code, in the bundle. Store it in the Vercel project's environment variables. If it was ever exposed, rotate it (see leaked API keys).
3. Open database tables
If your v0 app uses Supabase from the browser, the public key is only as safe as your RLS policies. See the Supabase RLS check.
4. Same keys everywhere
v0's docs recommend different keys for development and production and rotating keys regularly. A v0 preview can only read Development-environment variables, which makes separate keys straightforward.
5. An outdated Next.js version
Next.js has had serious advisories; keep the framework up to date. See the Next.js CVE check.
What the free FixMyVibe scan checks
Paste the URL of a public GitHub repository. The free scan reads the code read-only on a temporary copy that is deleted afterwards, and looks for:
- Hardcoded secrets in the current files: API keys, tokens, Supabase secret/service_role keys, private keys, and secrets exposed through
NEXT_PUBLIC_/VITE_variables or committed build output. - Supabase database rules in your committed SQL migrations: tables without RLS,
USING (true)/WITH CHECK (true)policies, policies that trustuser_metadata, and similar patterns.
What it does not do: it does not scan your git history (only the current files), it does not connect to your database or your live v0 app, and it cannot see private repositories. Dependency checks against the OSV vulnerability database are part of the paid audits, not the free scan. It is an automated code scan, not a penetration test.
Note: v0's GitHub integration creates a private repository by default, which the free scan cannot read.
Pre-launch checklist
- List every NEXT_PUBLIC_ variable and confirm none holds a private key.
- Search the code for hardcoded keys; move them to the Vercel project's environment variables.
- Call third-party APIs that need a private key only from Route Handlers or Server Actions.
- Use separate development and production keys; rotate any key that was ever exposed.
- If you use Supabase from the browser, check RLS on every table.
- Update Next.js to a patched version.
FAQ
Which environment variables in a v0 app are public?
v0 follows Next.js: variables without the NEXT_PUBLIC_ prefix stay on the server, and variables with it are exposed to the browser. Next.js inlines NEXT_PUBLIC_ values into the JavaScript bundle at build time, so anyone can read them.
Does v0 warn me about NEXT_PUBLIC_ secrets?
v0's security docs say it analyzes NEXT_PUBLIC_ usage and warns about potential security risks, and can move code to Route Handlers or Server Actions. Treat that as a helpful check, not a guarantee.
Where are a v0 app's secrets stored?
On the connected Vercel project. v0 reads the project's environment variables; its preview can only access Development-environment variables, so variables marked sensitive aren't available to v0 previews.
Can FixMyVibe scan a v0 project?
v0 can push a project to GitHub, but its docs say it creates a private repository. The free scan only reads public repositories, so you'd need to make the repository public or ask us about a paid audit.
Is a Supabase anon key in NEXT_PUBLIC_ a leak?
No, the Supabase publishable/anon key is designed to be public and is only as safe as your RLS policies. A Supabase secret/service_role key or any private API key in NEXT_PUBLIC_ is a leak.
Sources
- v0 docs: Security
- v0 docs: Vercel integration (environment variables)
- v0 docs: GitHub
- Next.js docs: Environment variables
- Vercel docs: Environment variables
- Supabase docs: Understanding API keys
FixMyVibe is an automated code scan, not a full penetration test, and cannot guarantee that an app is secure. What happens to your code during a scan: see our privacy policy.