v0 security: all 1,790 v0 apps we scanned got an A

You described an app to v0, watched it build one, and got back a link ending in vusercontent.net. It works, it looks finished, and you may already have sent it to somebody. Before real customers type their details into it, you searched for v0 security, and part of what came back was a story about attackers using v0 to build fake sign-in pages.

That story is about what other people make with the tool. This post is about the app you made with it, and for that we have a measurement. Between 12 and 14 August 2026 we ran the same nine external checks anyone can run free on our homepage over 30,998 live apps, and 1,790 of them were v0 apps. Every one of the 1,790 graded A.

Here is the part a league table gets wrong: that A says more about what was there to check than about v0. As a ranking it makes v0 the safest builder we measured. Read with its denominators, it describes front ends with nothing behind them, and it stops describing yours the day you connect a database.

Is v0 safe?

On everything we could measure about v0 itself, yes. Its one finding belongs to the domain v0 serves your app from, and nothing else turned up on any of the 1,790, on any of the nine checks. What that cannot tell you is how your app behaves once it holds data, because almost none of these held any.

Think of a v0 preview as a filing cabinet on a showroom floor. The drawers slide, the labels are on, anyone walking past can pull one open, and every drawer is empty. Our checks tried every drawer and found nothing in any of them, which is an accurate report on an empty cabinet.

How empty is in the numbers. Only 17 of the 1,790 named a Supabase project anywhere in the code they ship, and on all 17 our database check could not get an answer it could judge, so the count of readable tables on v0 is zero out of zero. Every one of the 1,790 was served from vusercontent.net, which Vercel describes in its request to the Public Suffix List as "where we host the user-submitted content" for v0. An app you publish goes to a vercel.app address or a domain of yours, where nothing marks it as v0 from outside, so those are not in the count. The method and the full data are in the report.

So "is v0 safe" is three questions:

1. The tool. What v0 checks in the code it writes, and what it refuses to publish. That part is Vercel's, and it is documented.
2. The preview. The cabinet on the showroom floor, at its vusercontent.net address. Every app we measured was at this stage.
3. The app you fill. The same code once it holds your customers' records, or runs on a domain of your own. Almost nothing we measured had got this far.

What v0 security covers before you publish

Three things, and v0's own documentation names each of them.

It reads the code it wrote. v0's security page says all generated code "undergoes security analysis before execution", and that v0 "analyzes NEXT_PUBLIC_ usage and warns users about potential security risks". NEXT_PUBLIC_ is the prefix that tells Next.js, the framework v0 writes in, to put a value into the code every visitor downloads. What that prefix does to a key is a post of its own.

It refuses some deployments. In August 2025 Vercel wrote that v0 had blocked over 17,000 deployments in the previous 30 days because of exposed secrets alone, and over 100,000 insecure deployments since launch. Those are Vercel's figures about Vercel's block, which applies to deployments on Vercel. Some of our zero may be that block's work. From outside we cannot tell how much.

The Supabase integration puts the prefix in the right place. Connected through the Vercel Marketplace, it adds a dozen environment variables, and only two of them carry NEXT_PUBLIC_: the project address and the publishable key, which are both meant to be public. SUPABASE_SECRET_KEY and the database password are left without it, on the server.

Why a v0 preview is missing security headers

Because v0's preview domain sets them, every app on it gets the same answer, and you cannot change that from inside a preview.

Security headers are instructions a site sends with every page: always use HTTPS, do not let another site show this page inside its own, do not guess what kind of file this is. Whoever serves the page sends them. The previews we opened on 3 October 2026 sent one of the five our check looks for, the one that forces HTTPS, and none of the other four. That is the finding on all 1,790 v0 apps, and it is the only one.

The showroom sets its own doors and alarms, and you cannot rewire them for one cabinet on its floor. Once you publish, the cabinet is in your office, and the headers are a setting in vercel.json or in your Next.js config. What each header does, and the two that cost nothing to add, is a separate article.

Is a vusercontent.net preview public?

Treat it as public. Anyone who has the address can open it, and addresses travel.

Every one of the 1,790 opened for us with no login, and we did not have to guess at any of them: their addresses came out of a public web archive that had already saved a copy of each. v0's sharing settings decide who can see your chat: private by default, then your team, anyone with the link, or anyone on the web. The documentation does not say that those settings reach the preview.

So a preview is the cabinet on the showroom floor. That is fine for showing somebody the design and wrong for anybody's real records. Vercel did put vusercontent.net on the Public Suffix List in September 2024, which makes browsers treat every preview as a separate site, so one preview cannot set cookies for all the others. That keeps previews apart from each other, and it does nothing to keep yours private.

If you are here because somebody sent you a vusercontent.net link: the domain is Vercel's, and the page on it was made by whoever prompted it. On 1 July 2025 Okta reported attackers using v0 to build copies of real sign-in pages, and Vercel restricted access to the ones it found. Do not type a password into a sign-in form at an address like that unless you were expecting it.

What changes when you connect Supabase to v0

You start filling the drawers, and the checks that came back empty on v0 start having something to check.

v0 adds Supabase in a click and, in its own documentation's words, "can generate and execute SQL. This lets you create, update, and drop tables." Each table is a drawer, and row-level security is the lock on it: a per-table setting that decides which rows the publishable key in your page may read. That key is meant to be public, so the lock is the only thing deciding what a stranger gets back.

Supabase fits that lock by default on tables created in its Table Editor, and leaves it off on tables created by running SQL, which is how v0 makes them.

That is where the serious findings on every other builder landed. Of the 3,553 Lovable apps whose database we could ask, 2,017 handed rows to a request with no login, and the Lovable numbers are what a builder's results look like once there are records in the drawers. A lock that any key opens is no lock either: a policy that reads using (true) lets everybody through while the dashboard reports the table as protected. RLS is on and your table is still public is that whole story.

If your data sits behind routes your own server code answers instead, the same question gets asked of those routes: what an open API endpoint means.

What changes when you publish or deploy it yourself

The cabinet leaves the showroom for your office, and the decisions v0's domain was making become yours.

Publishing from v0 creates a Vercel project and asks three things, according to v0's deployment docs: the project name, who can access the deployed app, and the domain, either a vercel.app address or one of your own. Slow down on the second. Which options you see depends on your plan, and keeping the app to your team or behind a password until you have checked it keeps strangers out while you look.

Three things move to you when you publish:

• The headers. The office's doors and alarms are yours to set now.
• The environment variables. They live in your project's settings, and that list is where a key either gets the NEXT_PUBLIC_ prefix or does not.
• The check on your deploy, if you leave Vercel. Vercel describes its block as stopping deployments on Vercel, so code you download and host somewhere else goes out without that check.

Either way you have left the sample we measured. A v0 app on its own domain with a database behind it has more in common with the Bolt apps we measured than with these 1,790 previews.

How to check your own v0 app

Five things, and the first three only start to matter once you have connected a database or published. Use a private window, so your own login does not answer for a stranger.

1. Read your environment variables. In v0 they are under the project menu, Settings, Environment Variables. Anything starting NEXT_PUBLIC_ is in the code every visitor downloads. A project address and a publishable key belong there. A key that bills you, SUPABASE_SECRET_KEY and anything holding a password never do. If one ever carried the prefix, rotate it with the provider first, because the old value keeps working until you do.
2. Read the lock on every table. In Supabase, open Authentication → Policies and go down the list. A table with row-level security disabled is readable by anyone who has your project address, and that address is in your page. A policy that permits everybody counts as disabled.
3. Choose who can see it when you publish. Team only, or a password, until the first two are done.
4. Set your headers once the domain is yours. Two of them are one line each.
5. Then look from outside. Our scan runs all nine checks against the published address the way a stranger would, takes about 20 seconds and needs no account: scan your app free.

An outside scan cannot see the code v0 wrote, the chat you wrote it in, or a table your pages never mention. v0's checks see the code from the inside and cannot see what a stranger gets from the address. Run v0's while you build, look from outside after you publish, and if the two ever disagree about whether a table is readable, go with the outside answer, because that is the one a stranger gets. The plain-language version for this platform is is your v0 app safe.

Keeping it that way after you publish

An A on a preview describes a preview. The day you connect a database or publish to your own domain, your grade can change, and nothing on your screen tells you it has.

Reeve Monitor runs the nine checks again for you:

• all nine checks every hour, on up to three apps
• whether the app is up, every 60 seconds
• a message when a result changes, so a new table or key does not wait for you to look
• a monthly report of what it saw

Monitor is $12 a month at list, with seven days free before it charges you. The pricing page is sometimes below the figure here and never above it.

If your v0 app keeps its data in Supabase, Reeve Care keeps a copy of your Supabase database.

• an encrypted copy every night, kept where your project cannot reach it
• each copy verified before it counts, by counting the rows in every table
• a one-click restore when you need one
• your uploaded files as well, once you connect a Storage credential
• everything Monitor does

Care is $49 a month at list for one app, with the same seven days free.

v0's documentation says it can drop tables as well as create them, and none of the nine checks above would bring back the rows in one. The day an AI agent deleted a production database is what that looks like from the inside.

What to do this week

Start with the environment variables, because they decide what every visitor downloads. If you are still choosing a builder, which AI app builder is safest puts all five side by side.