16,000 Exposed Supabase Databases and What to Ask Your Dev

Security firm UpGuard says it found roughly 16,000 databases hosted on the development platform Supabase that were exposing some amount of personal data to the open internet, as reported by TechCrunch. Names, addresses, phone numbers and, in a smaller number of cases, passwords and authentication tokens were sitting there, readable by anyone who knew where to look. If someone built an app or a customer portal for you in the last couple of years, this is worth thirty minutes of your attention.

What the research found

Supabase lets developers store and run databases behind their websites and apps. UpGuard went looking for how much data was publicly reachable across the platform and came back with about 16,000 databases holding some degree of personal information.

The examples are not abstract. According to the research, exposed datasets included private conversations from an adult streaming site in India, thousands of licence plates from a US valet service, and contact details of people who used an immigration and relocation service. One database belonged to an African government's consulate in France. Another was being used to intercept text messages through a virtual SIM farm, the kind of setup used to grab one-time passcodes for scams.

Most of the exposed datasets appear to sit in the United States, but UpGuard describes the problem as worldwide. Earlier research by the same firm turned up exposed databases belonging to Y Combinator startups and other well-known apps.

Supabase's chief information security officer, Bil Harmer, told TechCrunch the company had not seen the research, that its projects are "secure by default," and that security is a shared responsibility: the platform provides defaults and tooling, customers decide how their own projects are configured. He said affected customers are notified when problems are found.

Why this keeps happening

None of this is a new category of failure. Data breaches have been traced to misconfigured storage servers and databases for years, spilling everything from driver's licence scans to children's personal information.

What is new is the volume. Supabase has become a popular home for apps assembled quickly with AI coding tools, and the platform reached a $10 billion valuation on the back of that growth. AI can produce a working app fast. The generated code can also carry security flaws, and the app may need specific configuration that whoever pressed "generate" never knew about. Fast to build does not mean safe to launch.

Why it matters for a small business

The leaked data in these cases is ordinary business data. Customer names. Phone numbers. Addresses. Order history. Whatever your booking form collects. If you run a shop, a clinic, a delivery service or a members' portal, that is exactly the material sitting in your database right now.

The damage is not only regulatory. It is customers learning from someone else that their phone number was public, and a competitor downloading your entire client list in one request. You do not need to be a large company to be worth scraping; automated tools do not check your revenue first.

What to ask and fix this month

• Ask one direct question. Message whoever built your app: "Can anyone read our database tables from the internet without logging in?" A confident, specific answer is fine. Vagueness is your signal to keep digging.
• Ask for a list of what is stored. Every table, every field that holds personal data, and who can read each one. If nobody can produce that list, nobody knows what is exposed.
• Check access rules per table, not per app. The common failure is one forgotten table left open while the rest are locked down. Request a table-by-table confirmation in writing.
• Rotate keys and tokens. API keys and authentication tokens that have been sitting in code or chat messages for months should be replaced. UpGuard specifically found exposed passwords and tokens.
• Delete what you do not need. Old test data, abandoned features, scraped contact lists. Data you no longer store cannot leak.
• Test anything that was AI-generated twice. If part of the app was built with AI assistance and shipped quickly, treat the security configuration as unverified until someone has actually verified it.

The platform's position — secure defaults, customer-controlled configuration — is reasonable and also a warning. Defaults protect you until someone changes them, and in a fast build someone usually does. A short review now, with written answers, costs you one afternoon. Finding out from a security researcher costs considerably more.