16,000 Supabase apps are leaking user data, and the cause is how AI coding tools create tables

Security firm UpGuard published research on September 25 identifying 16,326 Supabase databases that expose readable tables to anyone on the open web, drawn from roughly 300,000 candidate sites. More than half showed signs of personal data, a smaller share leaked passwords or authentication tokens, and a handful held plausible payment records. The number is striking, but the more useful finding for developers is the mechanism, which is not a Supabase vulnerability so much as a default that behaves differently depending on who creates the table.

The default that flips

Supabase apps ship a public key. A browser or mobile client authenticates to the database with an anon key that is meant to be visible, because it is baked into the front end that anyone can inspect. The only thing standing between that public key and your rows is row-level security (RLS), Postgres policies that decide which rows a given caller may read or write. With RLS enabled and written correctly, the anon key can reach only what your policies allow. With RLS disabled, the anon key can read the whole table.

Here is the split UpGuard identified. Since 2025, Supabase enables RLS by default when you create a table through its Table Editor dashboard. Tables created programmatically through the API, which is how coding agents talk to Supabase, do not get RLS turned on by default. An agent writing SQL migrations skips the dashboard entirely, so the protective default never fires, and the developer often never sees the prompt that would have flagged it.

What was actually exposed

The examples are the kind that carry real consequences. UpGuard describes an Indian platform with 65,467 users and more than 100,000 private messages, a Philippines OTP service leaking over 100,000 SMS messages including one-time passcodes, a US valet service exposing 100,000 customers with contact details and license plates, an African consulate’s records for 25,000 residents, and a Canadian immigration service with about 5,000 records that included plaintext passwords. These were live tables reachable without a breach, an exploit, or a stolen credential, only a request.

The apps were not hard to find. UpGuard fingerprinted sites carrying Supabase identifiers in their JavaScript using BuiltWith and the Chrome UX Report dataset on BigQuery, then checked whether common tables such as users returned rows. The report also notes there is no security through obscurity here, because the database returns table-name hints even when a request is refused, which narrows the guesswork for anyone probing.

Why AI-built apps cluster in the results

UpGuard ties the pattern to the wave of applications scaffolded by vibe-coding tools, naming Lovable and Replit among the builders and Claude Code and OpenAI’s Codex among the agents that wire these apps up. The tools are good at producing a working schema fast. They are less reliable at the security posture around it, because the safe path (enable RLS, write policies per table) is manual, easy to defer, and invisible in a running app until someone reads the data. A generated app that looks finished and demos cleanly can ship with every table world readable, and nothing in the happy path surfaces the gap.

This is not a claim that AI-built apps are inherently unsafe. It is a narrower and more actionable point: the code generators default to the fast path, the platform’s safe default lives in a UI the generators do not use, and the two gaps line up to produce thousands of open databases.

What to do now

If you run a Supabase project, the checks are quick and worth doing today. Confirm RLS is enabled on every table that holds user data, not just the ones you created in the dashboard, with alter table <name> enable row level security and a policy that actually restricts rows. Treat the anon key as public, because it is, and never rely on it being secret. Audit any table an agent or migration created, since that is exactly the path where the default did not protect you. Keep service-role keys out of client code entirely. For a fast external read, Supabase and several third parties publish RLS linters that flag tables reachable by the anon role.

What to watch

The structural fix is a defaults question, and it sits with the platform and the tool makers as much as with individual developers. The open issue is whether Supabase extends its RLS-on-by-default behavior to the API and migration paths that agents actually use, and whether the coding tools start generating policies rather than leaving a to-do. Until one of those defaults changes, the safe assumption for any Supabase app scaffolded by an agent is that RLS is off until proven on. The reassuring part is that the remedy is ordinary database hygiene. The uncomfortable part is how many shipped apps never got it.

Sources cited

1. Everything, everywhere: systemic data exposure in Supabase apps (UpGuard) www.upguard.com
2. Some Supabase customers are publicly exposing reams of people's data to the web (TechCrunch) techcrunch.com
3. 16,000 Supabase databases exposed as vibe-coded apps leak sensitive user data (Cybernews) cybernews.com