Are most vibe-coded apps leaving their database open? What a 30,998-app scan found, and how to check yours

Are most vibe-coded apps leaving their database open? No, but a lot of Supabase apps are. In the largest public scan so far, 2,096 of the 3,680 Supabase-backed apps the scanner could check (57%) let a stranger read at least one table with no login. That's not 57% of all vibe-coded apps: the scan covered 30,998 apps, and most of them either don't use Supabase or couldn't be checked from outside. Whether yours is one of them takes about two minutes to find out, in your own Supabase dashboard. Every number below was re-read on the reports' own pages on November 3, 2026.

Is my app one of them? The two-minute check

Open your own Supabase project and look. No outside scan can do this as well, because only you know which tables are meant to be public. Three ways, quickest first:

1. Supabase Security Advisor. In your Supabase dashboard, open the Security Advisor (it sits next to the Health and Performance advisors). A table in the public schema with Row Level Security off shows as lint 0013, level ERROR, "Table publicly accessible". Supabase's own description of that error: "Anyone with your project URL can read, edit, and delete all data in this table because Row-Level Security is not enabled."
2. One SQL query. In the SQL editor, this lists every table in the public schema and whether RLS is on. Any row with rowsecurity = false is a table the anon key can reach.
3. If you built on Lovable, its docs say a Quick scan "runs automatically every time you publish" and checks "your database access rules". Read what it found before you dismiss it. Lovable also says these tools "cannot guarantee complete security."

-- Which tables in the public schema have Row Level Security off?
select tablename, rowsecurity
from pg_tables
where schemaname = 'public'
order by rowsecurity, tablename;

Two other advisor messages are worth knowing. "Security policy not enforced" (lint 0007) means you wrote a policy but never turned RLS on, so the policy does nothing. "No access rules defined" (lint 0008) means RLS is on with no policies, so nothing can be read or written through the API. That's safe, and it's also why your app may suddenly show empty lists. Both are INFO level in Supabase's list.

If you find a table with RLS off, turn it on and then write the policy that lets the right people in. Supabase's docs put the rule plainly: "Enable RLS on every table in an exposed schema." Once it's on, "no data is accessible through the API when using a publishable key, until you create policies." The error you'll likely hit next is explained in new row violates row-level security policy. Don't switch RLS off to make that error go away.

alter table public.your_table enable row level security;

What did the 30,998-app scan actually measure?

Whether a stranger could read a table, without reading any data. The report is The State of Vibe-Coded App Security 2026 from Reeve. Its method: "We looked for live apps built with Lovable, Bolt, v0, Replit or Base44," then ran each through the same nine checks (security headers, cross-site sharing, source maps, database access, exposed secrets, storage buckets, domain renewal, SSL certificate and private files). For the database check it says "The check never reads a row." The scan ran Aug 12 to 14, 2026 and was published Aug 19. Reeve also notes "The sample leans towards newer apps."

What is the 57% a percentage of?

The Supabase apps the scan could reach, not all vibe-coded apps. This is the part the headline drops. Of the 30,998 apps, 8,429 name a Supabase project. The database check got an answer from 3,680 of them. In Reeve's words: "The rest sit behind backends we do not follow, so we leave them out." And: "Fewer than half the apps that name a Supabase project can be checked at all." Of the 3,680, 2,096 had at least one readable table. That's the 57%.

Reeve's builder table shows who was measurable. On default publish domains, Lovable had 18,554 apps, 35% used Supabase, and 57% of 3,553 checkable Supabase apps had a readable database. Bolt's figure was 77% of just 35 apps. Base44, Replit and v0 had too few checkable apps for a figure; Base44 sends database traffic through its own backend, which an outside check can't follow. So the headline is mostly a number about Lovable apps that talk straight to Supabase. That's about who could be measured, not a safety ranking of the tools, and Reeve says of the gaps to "draw no conclusion about how safe those apps are."

Does a readable table mean my users' data leaked?

Not necessarily. "Open" here means at least one table could be read without logging in. Reeve splits the 2,096 apps in two: 1,702 exposed "tables with generic or technical names: settings, content, logs," and 394 exposed "tables named like personal data: users, profiles, orders, messages." Reeve's own gloss: "A readable table called settings or content is a mistake. A readable table called users, profiles or orders is other people's personal data on the open internet, and whoever built the app almost certainly believes it is private."

There's one limit no outside scan removes, and Reeve states it: "No host can tell which of your tables should be public, or which key belongs on a server." A readable content table might be a blog you meant to publish. That's why the fix is a decision, not a setting.

Are the scarier numbers in the report as bad as they sound?

Mostly not, and Reeve says so itself. From the same page:

• "99% of the 30,998 apps we scanned had at least one finding," but "nearly all of them are missing browser security headers," a hosting default rather than a mistake the builder made.
• 1,332 apps shipped a key, which sounds alarming. Reeve's breakdown: 1,142 ship a Google API key, "a browser key, meant to be public," and 52 ship "a key that can spend money or read the whole database" (OpenAI, AWS, Anthropic, a Stripe secret key, a Supabase service_role). "Only 3 of them shipped the master database key. That is rarer than the usual panic implies."
• A publishable key in the page is fine. Reeve counts these as OK: "A publishable key in the frontend is supposed to be there." That matches what we say about the Supabase anon key.

Some numbers are better than you'd guess: 96% ship no secret of any kind in their public code, and 97% of the file storage it could check was locked to outsiders. Reeve's summary of where the serious failures sit: "The settings only the person who built the app can change fail far less often," and they are the ones that put somebody's data on the open internet.

Why did a second scan find far fewer open databases?

Different samples, dates and definitions, and neither report explains the gap. Symbiotic Security published its scan on June 2, 2026: 1,072 Supabase apps built with Lovable, V0, Bolt.new, Replit and Windsurf. Its headline is "98% of vibe coded applications have at least one security flaw," but the most common finding was a missing Content Security Policy header (1,039 sites). The serious end: 173 sites (16%) had a critical vulnerability, "172 sites allow anyone to delete records from the database without any authentication," 172 exposed endpoints that let anyone modify records, and "39 sites have tables fully readable by anyone who holds the public Supabase key".

39 of 1,072 against Reeve's 2,096 of 3,680 is a huge gap, and we won't pretend to explain it. Note that Symbiotic counts 172 sites where records could be deleted without authentication, far more than its 39 readable ones, so "readable" is not the only way a table is open. Symbiotic also rates the Supabase anon key exposed in JavaScript as a High-severity finding (308 sites), while Reeve counts it as correct. Scanners differ in what they flag. The key was never the protection; Row Level Security is.

What should I do if I'm about to share my app?

None of this requires trusting a percentage. Three habits cover what both reports found:

1. Row Level Security on every table, then a policy for each one that lets the right people in. Check the Security Advisor again after you add a table.
2. Decide which tables are public, on purpose. Anything named like users, profiles, orders or messages should never be on that list.
3. Keep real secrets out of the browser. A publishable key is fine; a service_role key, a Stripe secret key or an OpenAI key is not. The checklist is in the six checks before you share a vibe-coded app, and the wider habit is in everything to check before real people use your app.

If you want an outside view, Reeve says its nine checks are "the same nine checks anybody can run free on the Reeve home page." We haven't used it, and Reeve itself says "An automated external check is not an audit. Absence of findings is not a guarantee." An outside scan also can't see tables behind a backend it can't follow, so a clean result doesn't replace the Security Advisor check above.

This page has no affiliate links or sponsored placements. Both reports come from security vendors and were read on their own pages on October 3 and again on November 3, 2026; the Supabase and Lovable documentation was read on November 3, 2026. We left out a circulating claim that AI-assisted code has 4.4 times more flaws, because it traces to a press release we couldn't match to a primary report. Neither scan names an app.