Is your v0 app exposing data?
v0 by Vercel turns a prompt into a polished, deployable Next.js app in minutes. The catch is that "deployable" and "secure" aren't the same thing — v0 optimises for shipping a working UI, and the settings that keep strangers out of your data are the exact steps it leaves to you. Here's what that leaves open, and how to check your app in about ten seconds.
Check your v0 app now
Paste your app's URL. The free scan reads it from the outside and checks your database, secret keys, exposed files and headers. No signup, nothing changed.
Only scan apps you own or have permission for.The short answer
v0 is a legitimate tool from Vercel, and a properly configured v0 app can be perfectly safe. But the apps it generates are not safe by default once they hold real data. v0 produces Next.js code and wires it to a database — usually Supabase or Postgres — without switching on Row Level Security. It leans on Next.js conventions where anything named NEXT_PUBLIC_ is shipped to the browser, and it scaffolds API routes and server actions that don't check who's calling them until you add that yourself.
What can go wrong in a v0 app
Database readable without login (RLS off)
The big one. v0-wired Supabase or Postgres tables usually ship without Row Level Security, so the public anon key can read — and sometimes write — every row. Details in Supabase security.
Secrets in NEXT_PUBLIC_ variables
Next.js inlines every NEXT_PUBLIC_ env var into the browser bundle by design. Put a Supabase service_role key, a database URL or a private API key behind that prefix and it's readable by anyone in DevTools.
Unprotected API routes and server actions
v0 scaffolds route handlers and server actions that return or modify data, but the auth check is on you. A route that reads the database without verifying the session is an open endpoint anyone can call.
Public source maps
If source maps are enabled in the build, Vercel serves .map files that reconstruct your entire source — business logic, endpoints and comments — for anyone who looks.
Missing security headers
No Content-Security-Policy, HSTS or clickjacking protection. Hardening, but easy to close.
v0 as a tool is fine — this is about your app's configuration, which is yours to control. The point isn't to avoid v0; it's to check independently what it left open before real users find it.
How to check your v0 app
- In the database behind your app, confirm Row Level Security is enabled with policies on every table — v0 won't have done this.
- List your
NEXT_PUBLIC_variables and make sure not one of them is a secret. - Open each API route and server action and confirm it checks the user's session before returning or writing data.
- Or run the free scan below, which checks your database, keys, exposed files and headers from the outside.
Is your v0 app one variable away from a leak?
Find out in about 10 seconds. Free, no signup, read-only.
Only scan apps you own or have permission for.What to do if you find something
- Turn on Row Level Security for every table, with policies for who can read and write.
- Move secrets out of
NEXT_PUBLIC_variables, keep them server-side, and rotate anything that leaked — treat exposed keys as compromised. - Add an auth check to every API route and server action that touches data.
- Disable public source maps in your build settings so your code isn't downloadable.
- Re-scan to confirm nothing is still exposed.
Is v0 safe to use?
Yes — with a few deliberate steps. v0 gives you a real Next.js app and a one-click Vercel deploy, which is powerful and exactly why the defaults matter. Turn on Row Level Security, keep secrets out of NEXT_PUBLIC_ variables, guard your API routes, and disable public source maps, and a v0 app can be perfectly safe. The scan above tells you, in seconds, whether yours is locked down.