UpGuard found 16,326 Supabase databases whose tables anyone could read

UpGuard's researchers looked for Supabase database addresses and public API keys in the JavaScript of public websites. They then asked each database for data the way a visitor's browser would. Where a database answered with rows, anyone holding the same public key could read them. The counts in the report are UpGuard's own measurement.

How UpGuard counted

UpGuard found candidate sites in two datasets. BuiltWith fingerprints the technology behind websites, and the Chrome UX Report on BigQuery holds raw JavaScript files. Together they produced about 300,000 unique domains with signs of Supabase.

For each domain, UpGuard requested a table named users. A protected database refuses the request. An unprotected one either returns rows or, when that table does not exist, names another readable table as a hint, so an unusual table name hides nothing.

According to UpGuard, 16,326 databases exposed readable tables. The team judged their contents from the table schemas rather than by reading every row. Over half showed indicators of personal data, a smaller share held passwords or authentication tokens, and a very small number had plausible card data.

What was in the tables

UpGuard checked a handful of databases by hand to confirm the data was real, and says it notified the owners where the exposure was significant. The examples it describes include:

• an Indian adult-content platform with 65,467 users, passport and driver's license details, and over 100,000 private messages;
• a US valet service with over 100,000 customers, about 78,000 of them with a license plate number on file;
• a consulate run by an African government, with 25,000 users and their physical addresses;
• a Canadian relocation service with nearly 5,000 records, 884 of them storing a plain-text password.

Why coding agents make it worse

Supabase exposes tables through an automatic REST API, and Postgres Row Level Security (RLS) decides which rows a request may read. Supabase says RLS is on by default for tables created in its dashboard. For tables that migrations or external tools create, it recommends event triggers that switch RLS on automatically.

UpGuard says coding agents usually create tables programmatically through the API, and that path does not enable RLS by itself. The team also found policies that exist but restrict nothing, and public keys used as if they were secret.

UpGuard also cites outside research that names Supabase as the database Claude Code recommends most often. That figure comes from another source, not from UpGuard's own scan.

What Supabase offers to lock it down

Supabase lists these controls in its own review of security changes:

• RLS on by default for tables created in the dashboard;
• event triggers that enable RLS automatically for tables created by migrations or external tools;
• an option to disable the Data API entirely, or to move it off the public schema;
• email alerts to project owners when a table is created with RLS disabled, and Security Advisors checks that flag such tables.