Supabase has 16,000 databases with exposed personal data, research finds

A survey by UpGuard found names, addresses, passwords and tokens publicly accessible in thousands of projects hosted on the platform, almost always due to a configuration mistake by the developer themselves.

Security firm UpGuard identified roughly 16,000 databases hosted on Supabase with some degree of public exposure of personal data, according to a TechCrunch report published on September 25, 2026. Among what the research found accessible on the open internet are names, addresses, phone numbers, user passwords and, in smaller numbers, authentication tokens.

Supabase is a backend-as-a-service platform built on top of Postgres, widely used by developers who want to spin up a full relational database, with a ready-made REST API and authentication, without managing infrastructure. The company reached a $10 billion valuation this year, driven in large part by the growth of vibe-coded apps hosted on the platform, according to TechCrunch.

What UpGuard found

The exposed databases belonged to very different kinds of projects, which shows that the problem is not sector-specific, it is structural. The report cites, for example, private conversations from an Indian adult streaming site featuring content from sex workers, license plates of thousands of vehicles from a valet service in the United States, contact data from an immigration and relocation service, and the database of an African government's consulate in France. One of the most serious cases involved a SIM farm used to intercept text messages containing one-time verification codes, the kind of infrastructure typically linked to scams and phishing.

According to UpGuard, most of the exposed data is associated with projects in the United States, but the company classified the finding as a global problem, and the report notes that this research adds to previous surveys that had already found exposed databases linked to Y Combinator startups and other popular apps hosted on Supabase.

Why this happens: the public key and RLS

Editor's note: the technical description below about the anon key, RLS and PostgREST reflects general, publicly available understanding of how this type of architecture typically works; it was not directly verified against Supabase's official documentation for this report and should be confirmed by anyone applying these recommendations in practice.

The technical point that helps explain cases like this is not, from what is publicly understood, a Supabase bug, it is the way this type of platform is typically designed to work. In architectures like Supabase's, the SDK used on the frontend usually embeds a public key (the anon key), which by design ends up in the end user's browser and can appear in the page's source code.

Real security, in this model, tends to rest on Postgres's Row Level Security (RLS): policies that decide who can read or write to each row in the database. If the developer doesn't enable RLS on a table, or enables it but writes an overly permissive policy, anyone who discovers the project's URL and the anonymous key can, in theory, query the table through the automatically generated REST API, without needing a password.

It's this general design, public key plus the developer's responsibility to configure policies, that helps explain why apps built with vibe coding tools are a sensitive point: these tools usually generate the database schema and the Supabase integration automatically, but generative AI doesn't always configure RLS correctly, and a developer who doesn't understand Postgres in depth may never notice that the door was left open.

What Supabase says

Asked by TechCrunch, Supabase's CISO, Bil Harmer, said the company had no access to UpGuard's research before it was published, but that projects on the platform are "secure by default." He described security as a shared responsibility: "We provide secure defaults and tools, and customers control how their own projects are configured," Harmer said, adding that the company notifies affected customers when security issues are discovered. "Security at Supabase is never finished. We care deeply about getting this right, and we will keep making it easier for every developer to ship products securely," he added.

In practice, the response suggests that enabling RLS on every table containing sensitive data is a basic security step, not an optional advanced item.

What this changes for those building on Supabase

For those already running production on the platform or considering migrating a project there, this case is not a reason to abandon Supabase, but it is a reason to stop and audit. Here are a few practical points worth checking immediately:

• Confirm that RLS is enabled on every table that stores personal, financial or authentication data.
• Review existing policies, not just whether they exist: a USING (true) policy is equivalent to having no protection at all.
• Never treat the anon key as a secret: it will be read by any user, so all access logic needs to live in the database (via RLS) or in server-side functions, never relying on hiding the key in the frontend.
• In vibe-coded projects, treat AI-generated code as a security draft, not as a finished product: manually reviewing database access policies before going to production is the bare minimum, especially when whoever generated the app isn't the one who understands Postgres.
• Third-party auditing tools, such as scanners that test whether a project's anon key can read tables without authentication, help catch this kind of mistake before someone outside the company finds it.

The case is also a reminder that the ease of spinning up a full backend in minutes, one of the biggest draws of Supabase and similar tools, shifts complexity from infrastructure to permission configuration. Those who historically handled firewalls and networking now need to understand Postgres RLS policies, and that still isn't part of the security checklist for a good share of the teams that have adopted the platform in recent years.