The discovery of more than 16,000 Supabase databases exposing readable tables to the public Internet is a strong reminder that cloud and backend security failures are increasingly caused not by sophisticated exploitation, but by simple authorization mistakes multiplied across a rapidly growing developer ecosystem.

UpGuard Research identified 16,326 Supabase databases where at least some tables could be read without proper authorization. The researchers reached that number after fingerprinting roughly 300,000 domains using Supabase and testing whether publicly exposed application credentials could access database content. More than half of the exposed databases showed indicators of personally identifiable information, while a smaller subset contained passwords or authentication tokens. A very small number showed signs of payment-card-related data.

This is important because the exposed Supabase anon key is not itself a secret. It is intentionally embedded in client-side applications and is expected to be visible to users. Security therefore depends on what that key is authorized to access. If a table is reachable through the Data API and Row Level Security has not been enabled or correctly configured, the public application key can become sufficient to read data that developers assumed was private.

That distinction is fundamental.

The problem is not:

“Attackers stole the Supabase API key.”

The problem is:

“The API key was public by design, but the backend trusted it too much.”

Supabase uses PostgreSQL Row Level Security, or RLS, to control which rows a particular user or role can access. Tables created through the Supabase Dashboard are generally protected more safely, but tables created programmatically through SQL, migrations, command-line tools, management APIs, or AI coding agents may require developers to enable RLS and define policies explicitly.

If that step is forgotten, the Data API can expose the table more broadly than intended.

That is what makes this issue particularly relevant in the current era of AI-assisted development. Developers can now generate entire applications, database schemas, migrations, and APIs in minutes. Tools such as Claude Code, Codex-style agents, Cursor, Replit, Lovable, and similar platforms can create tables without a human manually opening the Supabase dashboard and reviewing each security policy.

The speed of application creation has increased dramatically.

The speed of security review has not necessarily followed.

This creates a dangerous imbalance where an AI agent can successfully generate a functional application while silently omitting the authorization logic required to protect the data behind it.

The resulting application may appear completely normal to the developer. Users can sign up, records are stored, dashboards load, and API requests succeed. Nothing visibly breaks.

Unfortunately, from a security perspective, “everything works” can be exactly the problem.

If the anonymous role can also read every row, the application remains functional while being completely exposed.

The scale of UpGuard’s findings demonstrates why this is not simply a handful of inexperienced developers making isolated mistakes. More than 16,000 affected databases suggest a systemic security pattern where developers increasingly rely on frameworks and automated tooling without fully understanding the authorization model underneath them.

The exposed information varied widely. Researchers identified databases containing names, email addresses, phone numbers, dates of birth, physical addresses, authentication information, passwords, and tokens. Some individual examples were particularly serious, including services handling identity documents, immigration-related data, customer records, private messages, license-plate information, and other personal information.

The exact impact therefore differs dramatically between applications. One exposed database may contain only publicly intended profile information, while another may include credentials or sensitive personal data capable of supporting identity theft, account takeover, fraud, or highly targeted phishing.

That is why raw database counts alone do not describe the full risk.

The more important questions are:

What tables were exposed? What fields were readable? How long were they accessible? And did anyone actually retrieve the data before remediation?

An exposed database is not automatically proof that criminals downloaded every record, but Internet-accessible data should be treated as potentially accessed unless reliable logging establishes otherwise.

This is especially important because querying a misconfigured Supabase instance does not necessarily require noisy exploitation. An attacker can use the same REST interface the legitimate application uses. Requests may therefore resemble ordinary application traffic rather than obvious malicious probes.

The research also highlights why the anon key should never be treated as a credential boundary. Developers sometimes see something labeled an API key and instinctively assume possession of the key is what grants trust.

In Supabase’s architecture, the public client key is designed to be visible.

The real security boundary is the database policy.

If that policy is missing, hiding or rotating the public key does not solve the underlying problem.

This is a useful lesson far beyond Supabase. Modern application security increasingly relies on backend-as-a-service platforms where mobile applications, websites, and frontend JavaScript communicate directly with databases or APIs.

In those architectures, authorization must be enforced server-side at the data layer.

A user interface hiding a button is not authorization.

A frontend refusing to display another user’s record is not authorization.

A public API key is not authorization.

The backend itself must decide which rows and operations each user can access.

Row Level Security is designed to provide precisely that control, but it is only effective when enabled and correctly written.

Even RLS itself can be misconfigured. A policy that allows all authenticated users to read rows may prevent anonymous access while still exposing one user’s information to every other registered user. A developer can therefore enable RLS and still create an authorization flaw through an overly permissive policy.

The correct security model usually requires policies tied to user identity, ownership, role, tenant, or other explicit access context.

For example, a profile table should not merely ask whether the requester is logged in.

It should ask whether the requester is authorized to access that specific row.

The difference between authentication and authorization becomes critical here.

Authentication answers: “Who are you?”

Authorization answers: “Which records are you allowed to see?”

Many application leaks occur because developers solve the first question and assume the second has also been solved.

Supabase is already changing its defaults in response to this wider class of mistakes. The company announced in April 2026 that new tables in the public schema would no longer automatically become accessible through its Data and GraphQL APIs. For new projects, the safer behavior became the default starting in late May, while a broader rollout to existing projects is scheduled for October 30, 2026.

However, the change does not automatically repair existing exposed tables.

Supabase explicitly states that existing tables retain their current grants. That means developers cannot simply wait for the platform change and assume historical exposure disappears.

Existing databases need to be reviewed manually.

This point is extremely important.

A safer default prevents future mistakes.

It does not undo previous ones.

Organizations using Supabase should therefore audit every table accessible through the Data API and verify both the PostgreSQL grants and the Row Level Security policies applied to it.

Tables containing customer data, authentication information, payments, messages, documents, or administrative metadata deserve immediate attention.

Developers should also review views, functions, and RPC endpoints rather than concentrating only on ordinary tables. A protected underlying table can still leak information through another database object if that object executes with broader privileges or fails to enforce the same row-level restrictions.

Application security testing should therefore happen from the attacker’s perspective.

Instead of asking:

“Did we enable RLS?”

teams should ask:

“What can an anonymous user actually retrieve?”

and:

“What can one ordinary authenticated user retrieve about another user?”

Those tests frequently reveal problems that are invisible when reviewing configuration checkboxes alone.

Supabase has introduced tooling to help with this, including an RLS testing feature that allows developers to simulate queries as different roles and see which policies are applied. That is a useful improvement because authorization is often difficult to reason about just by reading policy definitions.

But automated testing should also become part of CI/CD.

A deployment pipeline should be able to fail when a new table is created without explicit grants, without RLS, or without an approved policy.

Security should become part of schema migration rather than something remembered after the application launches.

AI coding tools make this especially important. If agents are allowed to create database tables autonomously, security instructions need to be embedded directly into their development workflow.

For every new table, the agent should be required to define:

  • who needs access;
  • which operations are required;
  • whether anonymous access is permitted;
  • whether RLS must be enabled;
  • what policies enforce ownership or tenancy; and
  • how those controls are tested.

Otherwise the agent may optimize for functionality and generate the shortest path to a working application, which humans have also been doing enthusiastically for decades, so at least the machines are learning our finest traditions.

The broader industry lesson is that vibe coding and backend-as-a-service platforms dramatically reduce the cost of creating software, but they do not reduce the cost of understanding security.

In fact, they may increase it.

A developer who once needed to understand databases, APIs, authentication, and backend architecture can now assemble a production application without deeply understanding any of them.

That democratizes software development.

It also democratizes database misconfiguration.

Organizations adopting AI-assisted development therefore need stronger automated guardrails precisely because fewer people in the development path may understand the underlying security model.

Security defaults should ideally fail closed.

Schemas should require explicit exposure.

Authorization policies should be generated and tested alongside tables.

Secret scanning should run automatically.

And deployment pipelines should verify that anonymous and cross-user access behave as intended.

The Supabase exposure also reinforces the importance of data minimization. Some affected applications reportedly stored plaintext passwords or highly sensitive identity data in tables that were then publicly readable.

That is a failure on two levels.

The table should not have been public.

But certain data should not have been stored in that form at all.

Passwords should be securely hashed using modern password-storage algorithms rather than stored in plaintext. Sensitive authentication tokens should be minimized, scoped, and rotated. Identity documents and payment-related information should be collected only when necessary and protected according to their sensitivity.

Strong architecture assumes that one control can eventually fail.

If an authorization policy is accidentally removed, properly protected passwords should still not immediately become usable credentials.

Defense in depth matters because developers will eventually make mistakes.

Organizations that discover a Supabase exposure should therefore do more than simply enable RLS. They should review access logs where available, determine what information was exposed, identify whether unauthorized retrieval occurred, notify affected users where required, invalidate exposed authentication tokens, rotate credentials, and treat plaintext-password exposure as a credential-compromise incident.

If users may have reused exposed passwords elsewhere, the consequences can extend beyond the affected application through credential stuffing.

Likewise, leaked session

Researchers found more than 16,000 misconfigured Supabase databases exposing readable tables with personally identifiable information, passwords, or authentication tokens. [...]

Source: Misconfigured Supabase apps expose data in over 16,000 databases via Bleeping Computer — published 28 Sep 2026.