16,326 Supabase Databases Had Readable Tables. The AI App Boom Is Scaling an Old Security Mistake

16,326 Supabase Databases Had Readable Tables

AI tools can now produce a functioning app in hours. New research from cybersecurity firm UpGuard shows why functioning and secure are still very different standards.

UpGuard gathered roughly 300,000 domains showing signs of Supabase use and identified 16,326 databases exposing readable tables. More than half showed schema indicators of personally identifiable information, while smaller numbers appeared to contain passwords or authentication tokens.

That does not mean Supabase suffered a breach, and the research does not establish that every exposed application was AI-built. Supabase CISO Bil Harmer told TechCrunch that its projects are “secure by default” and described security as a shared responsibility, while UpGuard argues that AI-assisted development is helping insecure configuration scale faster.

The consequences were not theoretical. UpGuard examined one database used by an African government consulate containing about 25,000 users’ personal information and physical addresses, including emergency-housing locations. Other cases included identity-document information, private messages, customer records and plaintext passwords.

The public key is not the secret

A common mistake is treating a visible Supabase anon or publishable key as though its exposure is itself the vulnerability. Supabase explicitly designs publishable keys for browsers, mobile apps and other public clients. They identify the application; they are not meant to secure the underlying data by secrecy. Access control comes from PostgreSQL grants and Row Level Security (RLS), which determines which rows the anon or authenticated role can read or change.

A public key in frontend code can therefore be normal. A customer table that lets that public client retrieve every row is not. Supabase’s current documentation says RLS should be enabled on exposed tables and database privileges limited to what each role actually needs. Secret or service-role credentials are different: they bypass RLS and should never be shipped in frontend code.

AI makes an old mistake easier to reproduce

Database misconfiguration predates generative AI. What has changed is the number of people who can now create and deploy software without first learning how authentication, databases and authorisation fit together.

That is also why TechView Africa’s guide to building a working app with AI treated a successful interface as only the beginning. Its guide to AI permissions makes the same broader point: useful access should still be limited to what the system actually needs.

UpGuard’s methodology has limits. Researchers initially queried for the common users table, so the dataset naturally leans toward user information. For most of the 16,326 databases, they assessed schemas rather than reading every stored record.

The finding is therefore not evidence that every AI-built app is unsafe. It is evidence that fast software generation does not remove the need to design and test permissions deliberately.

Our Recommendation

Treat an AI-generated app as a prototype until its database access has been tested independently. Before launch, verify RLS on every exposed table, test what signed-out and signed-in users can actually query, minimise grants, and keep privileged credentials on the server.