v0 apps, public env vars, and Supabase auth

v0 deploys to Vercel and can connect a backend. Vercel and Supabase document which keys are public and which keys bypass row level security.

Share link · Share on X

Last updated Oct 14, 2026

highSecrets

Shows up in: Next.js, Vercel, Supabase

Markdown version

What it is

Vercel's v0 docs say you can connect a backend and deploy with one click to Vercel, and that the stack includes Next.js. They do not publish a count of insecure v0 apps. The rules below are the vendor rules that apply when a v0 project uses environment variables or Supabase.

Vercel says environment variables are encrypted at rest, Config values stay readable to members with access, and Secret values are write-only after saving. Supabase's Vercel integration page lists both NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY and SUPABASE_SECRET_KEY. The NEXT_PUBLIC_ prefix is the public one. Supabase says a secret key bypasses row level security and must not go in the browser.

Auth still has to run on the server. Hiding a link in the React tree does not apply a Supabase policy.

How to check in 5 minutes

In the Vercel project, open Environment Variables. Confirm the Supabase secret key is a Secret, not a Config value, and is not named with NEXT_PUBLIC_.
Search the v0 project for SERVICE_ROLE and SECRET_KEY inside client components. Supabase says the secret key does not belong in the browser.
In the Supabase dashboard, confirm RLS is enabled on tables the browser client queries. Send one signed-out request with the publishable key and confirm you do not receive another user's row.

How to fix

v0

Keep the publishable URL and key in NEXT_PUBLIC_ variables. Move the secret key to a server module that client components do not import. Redeploy after you change Vercel environment variables. Vercel says existing deployments keep their previous values.

Vercel

Set credentials as Secret environment variables. Vercel's docs say you cannot convert a Secret to Config in place. Delete and recreate it if you stored a secret as Config by mistake, and rotate the key that was readable.

Supabase

Enable RLS and policies before you rely on the publishable key. Do not use the secret key from a v0 client component.

Copy-paste prompt

Paste this into Cursor, Claude Code, or whichever agent is editing the repo. Read the diff before you merge it.

You are checking a v0 project that deploys on Vercel. Do not add features.

1. List env vars. Anything NEXT_PUBLIC_ must be safe to ship in the browser.
2. If Supabase is used, enable RLS and show the policy. Remove the secret key from client code.
3. Do not invent a breach statistic. Show the files you changed.

Questions

Does the v0 docs page say it scans for RLS?

No. The v0 docs page checked on 2026-10-14 describes prompting, backends, and deploying to Vercel. It does not describe a security scan. The RLS requirement comes from Supabase's securing-data guide, which applies when the app uses Supabase.

Is the anon key a leak by itself?

Supabase says the publishable key, and the older anon key, can identify the project and are not secrets. They are a leak when RLS is off, because the key can then read and write the rows the policies fail to restrict.