A headline says more than half of vibe-coded apps leave their database open. The report behind it is more careful than the headline, and so is the number: what it measured, what it didn't, and the one check that matters for your app.
"More than half of vibe-coded apps leave their database open" is the kind of sentence that travels. It deserves a closer look, partly because there's a real problem underneath it and partly because the details change what you should do about it. Everything here comes from the reports' own pages, read on 3 October 2026.
Who ran it, and how
The report is The State of Vibe-Coded App Security 2026 from Reeve, which sells an app scanner. Its method is passive: "We looked for live apps built with Lovable, Bolt, v0, Replit or Base44, then ran each one through the same nine checks." It scanned 30,998 apps between 12 and 14 August 2026 and published on 19 August. For the database check, it says "The check never reads a row," only whether a table is readable. The apps came from three lists (posts on X and Reddit, Show HN launches, and the builders' own publish domains), and Reeve notes the sample "leans towards newer apps."
What the 57% is a percentage of
This is the part the headline drops. Of the 30,998 apps, 8,429 name a Supabase project. The database check could get an answer from only 3,680 of them, because the rest "sit behind backends we do not follow." Reeve says so directly: "Fewer than half the apps that name a Supabase project can be checked at all." Of the 3,680 it could check, 2,096 had at least one readable table. That's the 57%.
So the accurate sentence is "57% of the Supabase-backed apps this scan could reach," not "57% of vibe-coded apps." Reeve's builder table (apps on default publish domains) adds a detail worth knowing: it lists 3,553 checkable Supabase apps built with Lovable, against 3,680 in total, so the headline is mostly a number about Lovable-built apps that talk straight to Supabase. That's about who was measurable, not a ranking of tools. Reeve notes some builders route database traffic through their own backend, where an outside check can't follow, and says of those gaps to "draw no conclusion about how safe those apps are."
What "open" means here
"Open" means at least one table was readable without logging in. Reeve splits the 2,096 into two groups: 1,702 apps 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 can remove, and Reeve states it: "No host can tell which of your tables should be public." A readable content table might be a blog you meant to publish. Only you know. That's why the fix is a decision, not a setting.
The scary numbers shrink on inspection
Reeve's report is unusually willing to say when a number reads worse than it is. Some examples from the same page:
99% had at least one finding, but "nearly all of them are missing browser security headers," a platform default rather than a mistake the builder made.
1,332 apps shipped a key that belongs on a server, which sounds alarming. The report breaks it down: 1,142 apps ship a Google API key, "a browser key, meant to be public," while 52 apps 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 says it 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.
And 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."
A second scan, with very different numbers
Symbiotic Security published its own scan on 2 June 2026: 1,072 Supabase-backed apps built with Lovable, V0, Bolt.new, Replit and Windsurf. Its headline is that 98% had at least one vulnerability, but the most common findings were missing browser security headers, such as a Content Security Policy header missing on 1,039 of the 1,072 sites. The serious end is smaller: 173 sites (16%) had a critical vulnerability, 172 allowed deleting records and 172 allowed modifying them without authentication, and 39 had tables readable by anyone holding the public key.
Compare that 39 of 1,072 with Reeve's 2,096 of 3,680 and the gap is huge. The two use different samples, different dates and different definitions, and the published pages don't explain the difference, so we won't pretend to. The honest reading is that neither is a census of vibe-coded apps, and neither number should be quoted as "the" rate. Symbiotic also lists the Supabase anon key exposed in JavaScript as a High-severity finding on 308 sites, while Reeve counts it as correct. That disagreement is a reminder that scanners differ in what they flag, and that the key was never the protection, Row Level Security is.
What to do with this
None of it requires trusting a percentage. Three checks cover what the reports found:
Turn on Row Level Security for every table, then write the policy that lets the right people in. The error you may hit while doing it is explained in new row violates row-level security policy. Don't disable it to make the error go away.
Decide which tables are public, on purpose. Anything named like users, profiles, orders or messages should never be on that list.
If you want an outside view of your own app, Reeve says its nine checks are free to run on its 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."
Quick answers
Do 57% of vibe-coded apps have an open database?
No. In Reeve's August 2026 scan, 57% of the 3,680 Supabase-backed apps it could check had at least one readable table. That's 2,096 apps, out of 8,429 that name a Supabase project and 30,998 scanned. Apps whose database traffic it couldn't follow aren't counted either way.
Does a readable table mean personal data leaked?
Not necessarily. Of the 2,096 apps, 1,702 exposed generically named tables like settings or content and 394 exposed tables named like personal data. A scan can't know which tables you meant to be public; you do.
Is my Supabase anon key in the page a problem?
Not by itself. Reeve counts a publishable key in the frontend as correct, because the protection is the rules behind it. What matters is whether Row Level Security is on for every table it can reach.
Which scan should I believe, Reeve's or Symbiotic's?
Neither as a census. They used different samples, dates and definitions, and their readable-table rates differ widely. Both come from companies that sell security tools. Treat them as evidence that the problem is real, not as a precise rate.
This page has no affiliate links or sponsored placements. Both reports come from security vendors, and both were read on their own pages on 3 October 2026. We left out a third 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. The scan findings describe aggregate counts only; no app is named in either report.
