Supabase Customer Databases

Researchers found roughly 16,000 databases hosted on Supabase exposing data including names, addresses, phone numbers and passwords. The platform was not compromised. The databases were reachable because of how their owners had configured access.

This entry is about a class of exposure rather than a single victim. There is no breached company to name, no disclosure letter and no notification obligation triggered centrally, which is precisely what makes it worth covering.

Names, addresses, phone numbers and passwords across the affected databases. The specific contents vary by application, because each database belongs to a different team building a different product.

Passwords appearing at all is the detail that should stop a reader. In a correctly built application the authentication layer holds hashes and the application tables do not hold credentials. Their presence here suggests either storage that should not exist or hashing that was never applied, in an unknown share of 16,000 databases.

Users of 16,000 applications who have no idea which platform their data sits on. They signed up for a product, not for a backend, and there is no central party to notify them.

The structural problem is that accountability is distributed. Each affected team is individually responsible for its own users, most will never learn they were in the set, and the exposure persists until each one independently fixes a configuration they do not know is wrong.

Supabase provides row level security and the documentation is explicit about enabling it. The platform shipped the control. Defaults that favour a working prototype over a locked one are a deliberate and widely used design choice across developer platforms.

The assumption that fails is that a development configuration will be revisited before production traffic arrives. It frequently is not, because nothing breaks when it is left alone. The application works. The data is simply also readable.

That the database was publicly reachable at all. This is the purest form of the problem in this series: no attacker, no vulnerability, no credential theft, just 16,000 teams who did not know what their own configuration exposed.

Each one of these is individually trivial to check. Collectively they were discovered by researchers scanning the internet, which means the discovery method was available to every owner and used by none of them.

An organisation that periodically asked what its own data stores return to an unauthenticated request would never appear in a list like this. That check is cheap and almost nobody runs it, because nothing prompts the question until somebody external answers it for you.

There is no attacker to attribute. Researchers found the exposure through survey work and disclosed it, which is the same shape as the Vietnam APIS entry in this series.

The absence of a claim is not reassurance. Databases reachable without authentication are reachable by everyone who scans, and internet-wide scanning is continuous and automated. A researcher reporting it first is luck rather than evidence.

Enabling row level security before production data arrives, which is the documented control and takes minutes.

The broader fix is treating configuration as something to verify rather than assume. Sixteen thousand teams each believed their database was private. The only way to know is to ask the database what it hands to a stranger, and that is a question somebody has to deliberately ask.