Security firm UpGuard has published research identifying 16,326 databases hosted on Supabase with tables that anyone on the internet could read, more than half of them showing signs of personal information. Supabase is a widely used hosted database for web apps, and UpGuard links much of the problem to apps built quickly with AI coding tools, which tend to skip a security setting that the platform relies on.

What happened

UpGuard published the research on its blog on 24 September 2026, and the page was later updated on 1 October. TechCrunch reported on it on 25 September. UpGuard says it notified the owners of the significant exposures it found.

The firm's method, as it describes it, had two stages. First it assembled about 300,000 web domains that showed signs of using Supabase, using the technology profiling service BuiltWith and the Chrome UX Report dataset on Google BigQuery. UpGuard explains that "sites using Supabase can be fingerprinted by looking for Supabase key names and databases addresses in public Javascript files". Second, for each domain, it asked the database for a table called "users", a common name. A protected database returned nothing; an exposed one returned data or hints about which tables existed.

In 16,326 cases, at least some tables were readable. Judging by table structures, UpGuard says over half held indicators of personal information, while smaller shares included passwords or authentication tokens. It lists data types found across the set, including names, addresses, dates of birth, email addresses, government identity numbers, payment and bank details, location history, private messages and text messages containing one-time passcodes.

UpGuard examined a handful of cases more closely. Among them, it reports:

  • a US valet service with more than 100,000 customers' phone numbers and 78,000 licence plates, along with visit and tip histories
  • a Canadian immigration service with nearly 5,000 records, 884 of which stored passwords in plain text
  • an African government consulate with records on 25,000 people
  • a Philippines one-time passcode service holding over 100,000 text messages
  • an Indian adult content platform with 65,467 user records and over 100,000 private messages

How it works

Supabase is built on the Postgres database and lets a web page or app talk to the database directly from the browser. That is convenient, but it means the database itself has to decide who may read each row. The feature that does this is called row level security, or RLS.

Supabase's own documentation is direct about the stakes. It tells developers to "enable RLS on every table in an exposed schema", and its Security Advisor warns that without it, "anyone with your project URL can read, edit, and delete all data in this table". When RLS is switched on with no rules written, Supabase says "no data is accessible through the API when using a publishable key, until you create policies".

The keys matter too. Supabase's documentation says its publishable key (the older name is the "anon" key) is "safe to expose online", because RLS still applies to it. Its secret key (formerly "service_role") "bypasses Row Level Security" and must "never" be used in a browser. UpGuard found sites where public keys were treated as if they were secret, in other words where the developer assumed the key alone protected the data.

UpGuard's central finding is about defaults. It says Supabase began enabling RLS by default in 2025 for tables created in its Table Editor, the point and click interface. But "tables created programmatically through the API, which is how coding agents interact with Supabase, do not enable RLS by default." Even where RLS is on, UpGuard notes, the rules "must be configured and use credentials correctly to protect data".

This is not a new pattern. UpGuard points to earlier reports, from March 2025, of widespread misconfiguration in Supabase databases created through the AI app builder Lovable, and to other studies that found exposed data in apps generated with AI tools.

Why it matters

Supabase told TechCrunch that projects are "secure by default" and that security is a shared responsibility: the company "provides secure defaults and tooling, and customers control how their own projects are configured". TechCrunch also reported that Supabase says it notifies affected customers when it learns of security issues.

UpGuard's framing is different. It argues that "Supabase is designed so that AI coding agents can use it easily" and compares the situation to earlier waves of exposed data on Amazon S3 storage and GitHub, where a popular product made misconfiguration easy at scale. In its view, that kind of market success is also a signal that the balance between convenience and safe defaults needs to shift.

For small businesses the point is practical. AI tools now let a non-developer build a booking form, a customer portal or an internal tool in an afternoon. The app may work perfectly while leaving its database open to anyone who looks, and nothing on the screen will say so. The business, not the AI tool, is the one holding the customers' data, and in many jurisdictions it is the one responsible if that data leaks.

What we do not know yet

  • How many have been fixed. UpGuard notified owners of significant exposures, but has not said how many have closed the gap.
  • Whether anyone else got there first. The research shows the data was readable; it does not show whether criminals accessed it.
  • Platform changes. Supabase has not, in the material we reviewed, said whether it will enable RLS by default for tables created through its API.
  • The full picture. UpGuard tested for one common table name across domains it could fingerprint, so the true number of exposed databases could be higher.

What it means for you

If your website or app uses Supabase, especially one built with an AI builder or coding agent, these checks are worth doing now:

  1. Open your project's Advisors > Security Advisor in the Supabase dashboard and look for warnings about RLS being disabled on public tables.
  2. Confirm RLS is enabled on every table that holds customer or business data, and that the policies limit each user to their own rows.
  3. Search the code your site sends to browsers for any secret or service_role key. Only the publishable or anon key belongs there.
  4. Check that passwords are never stored in your own tables in plain text.
  5. If you find an exposure, close it first, then consider whether your local data protection rules require you to report it.

When choosing an AI app or website builder, ask how it sets up the database it creates, whether it enables row level security, and whether it warns you about tables left open.