Thousands of apps and websites built on the database service Supabase are leaving their contents open to anyone who thinks to ask. Researchers at the security firm UpGuard checked around 300,000 sites that showed signs of using Supabase and found more than 16,000 whose databases would simply hand back what was inside, including personal details, passwords and authentication tokens.
The problem is not a flaw in Supabase itself. It is the way these databases are set up, or rather not set up, and the common thread UpGuard points to is that a great many of the applications were assembled by AI coding assistants on behalf of people who never looked at how their database was configured.
What the databases were giving away
Personal information turned up in over half of the readable databases, with a smaller share leaking passwords or login tokens and a very small number appearing to hold card payment data. Because the set was so large, UpGuard judged the contents from the structure of the tables rather than reading every record, but it also pulled out concrete examples that show what this looks like in practice:
- A valet parking service in the United States left more than 100,000 customer records readable, complete with contact details, license plates and a history of visits.
- A Canadian immigration service exposed close to 5,000 user records, 884 of which included passwords stored as plain text.
- A government consulate for an African country exposed records on 25,000 people, among them home addresses and emergency housing locations.
- A one time password service based in the Philippines left data on more than 2,000 users open, along with 100,000 text messages, some of which were ordinary messages between private individuals.
- An adult platform based in India exposed identity information, payment accounts and more than 100,000 private messages.
Why apps built by AI keep doing this
Supabase is an open source platform built on the PostgreSQL database, and it has become a standard building block for people assembling apps quickly, often by describing what they want to an AI coding tool rather than writing the code themselves. By UpGuard's count, AI assisted work now accounts for more than 60 percent of newly created databases.
The weak point is a feature called row level security, which decides who is allowed to read which rows. Supabase turns it on automatically when a developer creates a table through its visual editor. Tables created through the programming interface, which is exactly how an AI agent works, do not get that protection switched on by default. A second mistake compounds it: Supabase gives each project a public key that is meant to be visible in the app, and some builders treat that key as if it were a secret that keeps people out, which it is not.
Put together, the result is an application whose owner believes it is private because they never touched a setting that would have made it so. As UpGuard puts it, the people running these sites know what business they are advertising but do not understand their database's configuration, because an AI agent created it and they never saw it.
What owners should check
The researchers are careful to say that their scans do not prove every exposed site was built by an AI tool, only that the pattern fits. They also say they contacted the owners of applications where the deeper analysis found serious exposure. For anyone running a Supabase project, the fixes are the same regardless of how the app was built:
- Turn on row level security for every table that holds real data, and then check that the policies actually restrict access rather than merely existing.
- Treat the project's public key as public, and never rely on it to keep data private.
- Work through Supabase's own security advisors and its guidance on securing the interface, both of which flag these exact risks.
For the ordinary people whose details sit in these databases there is little they can do themselves. The data was exposed by businesses they used, through a mistake those businesses did not know they had made. Speed was the whole appeal of building an app this way, and speed is exactly what skipped the step where someone checks who is allowed to read the database.
