16,326 Supabase databases readable: turn on RLS

A security firm pointed a scanner at the open web and found 16,326 Supabase databases with at least one readable table. More than half showed indicators of personally identifiable information. A smaller set showed passwords and authentication tokens. Nothing was hacked. The tables were simply reachable, because Supabase Row Level Security was never switched on — and the way most of these apps were built, nothing was going to switch it on for them.

What actually happened

TechCrunch reported on September 25 that research by UpGuard identified 16,326 Supabase-hosted databases where some tables could be read from outside. The contents were not abstract: private conversations from an adult streaming site in India, thousands of license plate records from a US valet service, contact details from an immigration and relocation firm, a database belonging to an African government's consulate in France, and infrastructure tied to a SIM farm used to intercept verification texts.

The mechanism is boring, which is why it keeps happening. Supabase exposes your Postgres tables through an auto-generated API. A table is protected only when Row Level Security is enabled on it and policies exist that describe who may read what. Supabase's own documentation is direct about it: new tables in the public schema start with privileges granted to anon, authenticated and service_role, and adding policies later "doesn't take those grants back." You enable RLS explicitly — alter table public.reports enable row level security; — or the table answers to anyone holding the publishable key, which ships in your frontend bundle.

Create a table through the Supabase dashboard and you get prompted. Create it programmatically — a migration file, a SQL block, a coding agent writing schema on your behalf — and nobody prompts anyone. That second path is now the common one. Supabase's security chief told TechCrunch security at the company "is never finished" and framed configuration as shared responsibility with customers. That is accurate, and it is also the whole problem: the half that belongs to you is the half nobody checked.

Why an open database matters for your business

The exposure is not proportional to your size. A twelve-table side project that collects a phone number and an address leaks exactly as completely as an enterprise system. Regulators and customers do not grade on traffic volume. Neither does an automated scanner sweeping the open web for reachable Postgres REST endpoints — and those scanners already have your project URL, because it is in your JavaScript.

Agent-written schema is the new default, and it skips the guardrail. When you ask a model to "add a customers table and wire up the form," you get a migration. You do not get RLS, revoked grants, or policies, unless you asked for them by name. The speed that makes this workflow attractive is precisely what removes the moment where a human would have paused.

Fixing it is an afternoon, not a project. For every table reachable through the API: enable RLS, revoke the default grants to anon and authenticated, write the narrowest policy that makes the app work, then verify by querying with the publishable key from outside your app and confirming you get nothing back. Add a CI check that fails the build when a table in public has RLS off. Then rotate keys, because you do not know who read what.

Sources: TechCrunch, Supabase Row Level Security docs.