16,326 Supabase Databases Had Public Data: How to Fix Missing RLS

UpGuard published the research on September 25, 2026, and calls it the largest study of its kind. Greg Pollock, UpGuard's Director of Research and Insights, wrote it. BleepingComputer covered the findings on September 28. Its report notes that Supabase has become popular with developers who build with AI tools, and that AI-assisted development accounts for more than 60% of newly created Supabase databases.

What UpGuard actually measured​

The 16,326 figure counts databases with readable tables. It is not a count of confirmed breaches, affected people, or records.

• Starting pool: UpGuard began with about 300,000 domains where it detected signs of Supabase use, then tested for a commonly named "users" table.
• How sites were found: Sites using Supabase can be fingerprinted by looking for Supabase key names and database addresses in public JavaScript files. UpGuard used BuiltWith's technology fingerprints and the Chrome UX Report dataset to do this at scale.
• The "hint" behavior: When a project had no users table but did have other readable data, the database replied with the name of a table that was accessible. As a result, the scan also caught exposures where the readable table had a different name.
• What the counts cover: The figure counts readable databases; it does not count people or records. The study does not establish how many individual records were exposed, when each database first became readable, or how long any exposure lasted.

UpGuard did not read every row. Given such a large set, the researchers used table schemas to assess the types of data potentially exposed in each rather than trying to read every row of every table. Based on those schemas:

• More than half of the databases showed signs of personally identifiable information (PII).
• A smaller share showed password or authentication-token fields.
• A very small number contained plausible credit card data.

UpGuard adds that the PII-heavy result partly reflects its choice to probe for a users table. The firm argues that almost every app eventually stores users, so the choice is reasonable.

For scale, 16,326 out of roughly 300,000 candidate domains is about one Supabase site in 18.

Section summary: Tens of thousands of sites were probed, and 16,326 databases answered with readable tables. The data types are inferred from schemas. UpGuard checked only a few databases row by row.

The five case studies​

To confirm that the schemas pointed to real data, UpGuard examined a handful of databases in depth. It says it notified the owners where it found significant exposure.

Two cases show risk spreading beyond the organizations themselves:

• The OTP service: About 95% of the messages were one-time passcodes, but 2,000 to 2,400 were real texts between rideshare drivers and passengers who had nothing to do with the operation. UpGuard ties the service to the SIM-farm part of the cybercrime supply chain.
• The valet service: About 11% of the exposed email addresses, 4,560 in total, were on third-party corporate domains. UpGuard says many belonged to recognizable regional employers, including universities and Fortune 500 companies. One small business's database can become a phishing list for much larger ones.

UpGuard also found patterns by industry. E-commerce and restaurant apps were the most likely to have personal information and integrated payment systems in their exposed databases, and unlicensed online betting sites were more likely to leak passwords and other credentials. Industrial-goods sellers were flagged too, because they often hold data from corporate clients, which makes this a supply-chain concern.

Why this happens: grants, RLS, and the dashboard-only default​

Supabase provides a hosted PostgreSQL database with an auto-generated Data API. That API lets applications query tables over HTTP. According to Supabase's documentation, access is decided in two layers:

1. Grants decide whether a role (anon, authenticated, service_role) can reach a table, view or function at all.
2. Row Level Security (RLS) policies decide which rows that role can read or change.

Supabase's RLS guide states that a table in an exposed schema without RLS can be read and written by any role that has a grant on it. On existing projects, new tables in the public schema automatically get select, insert, update and delete privileges for all three roles.

The problem lies in where RLS is switched on automatically. Tables created through the Supabase Dashboard have RLS enabled by default; tables created with SQL or other tooling require developers to enable it explicitly. That distinction matters for AI-generated applications because coding agents commonly create database objects programmatically. Startup Fortune put it bluntly: "A default that only holds inside one specific workflow isn't really a default, it's a trap."

A common myth is that the key in your frontend JavaScript is the vulnerability. It isn't. An API key placed in client-side code is not necessarily a secret credential; the key's presence does not by itself establish a vulnerability. The access rules around a table determine what a user can retrieve. UpGuard's real complaint about keys is different: some developers treat public keys as if they were secrets, or put the service-role key where it doesn't belong. Supabase says the service role bypasses RLS and must stay server-side.

Supabase's position and recent changes​

Supabase says projects are secure by default, but customers control how their databases are configured. The company has also started changing defaults. In its April 28th changelog entry, Supabase said new projects could opt out of automatically exposing new tables in the public schema through its Data and GraphQL APIs. Supabase's API security guide adds that the company plans to revoke automatic grants at the platform level, so exposing a table becomes something you choose rather than something that happens by default.

Both sides have a point. Supabase gives developers the tools to lock data down. But UpGuard notes that S3 and GitHub both went through the same pattern of convenience-first defaults followed by years of leaks. When a product becomes the default database recommended by AI coding agents, "the customer controls configuration" matters less if the customer never reads the configuration. Firebase had its own open-rules problem years ago, so this is not new for backend-as-a-service platforms.

Don't blame it all on vibe coding​

UpGuard's own framing leans heavily on AI. It argues that security settings were the same regardless of business type because the owners did not understand their databases, and that developer misconfigurations left data exposed to the open internet across the sample. The researchers also say plainly that their scans do not prove every affected site was built with an AI coding agent. Missing RLS predates Claude Code. The most accurate reading is that AI tools made it much faster to ship apps that nobody reviewed, while the mistake itself is an old one.

How to check your own Supabase project​

This checklist comes from Supabase's official security documentation. It applies whether a person or an AI agent wrote your migrations.

1. Run the Security Advisor in the Supabase Dashboard and deal with every warning about exposed tables.
2. Enable RLS on every table in an exposed schema, for example with alter table public.your_table enable row level security;. Once RLS is on, the publishable key can't read anything until you write policies.
3. Revoke broad grants, then grant back only what's needed. Adding policies does not remove existing grants. Supabase's example is to revoke all on table ... from anon, authenticated; and then grant back specific operations.
4. Write one policy per operation (select, insert, update, delete) and always name the role with a to clause. Supabase advises against catch-all for all policies.
5. Watch out for using (true) on the anon role. It gives every signed-out visitor every row the role can reach, so use it only for data meant to be public.
6. Audit your views. Views bypass RLS by default because they run as their creator. On Postgres 15 and later, create them with security_invoker = true. On older versions, revoke access from anon and authenticated or move the views to a schema the API doesn't expose.
7. Lock down functions. RLS does not apply to functions. Grant EXECUTE only to the roles that need it, and review every SECURITY DEFINER function.
8. Stop automatic exposure of new objects. Supabase documents alter default privileges ... revoke statements for tables, functions and sequences in public, so new objects need an explicit grant.
9. Test that access is denied, not just that it works. Supabase recommends pgTAP test files under supabase/tests/, run with supabase test db, that check both allowed and blocked actions for the anon and authenticated roles.
10. If you don't use the Data API at all, turn it off in the Dashboard's Data API settings.

If an AI agent writes your migrations, treat the SQL as untrusted code. Check it for RLS, grants and policies before it reaches production, just as you would review a pull request from an intern.

The bigger picture​

This is not the first warning. Earlier, smaller scans found the same pattern: Modern Pentest reported 28% of 107 Y Combinator startups exposing PII, and Escape counted 175 leaking databases across about 1,400 vibe-coded apps. UpGuard also points to the March 2025 Lovable-related disclosure tracked as CVE-2025-48757, and to Wiz's February 2026 finding of an exposed Supabase database behind Moltbook.

UpGuard's contribution is scale. It moves the issue from one platform's mistakes to a problem across the whole ecosystem. Some of the people exposed in these databases never signed up for the apps involved, like the rideshare drivers whose texts ended up in the OTP service's database.

Bottom line: If you have a Supabase project, especially one scaffolded by an AI agent, check your RLS today. The fix is a few SQL statements plus tests.