16,326 Exposed Supabase Databases: Audit RLS Before Production

UpGuard Research identified 16,326 Supabase databases returning readable tables to public requests.

More than half had schema indicators associated with personally identifiable information. Smaller subsets indicated passwords or authentication tokens. Selected investigations confirmed that some exposures involved real customer, identity, communications, and government-held information.

This was not one centralized breach of Supabase.

It was a recurring authorization failure across independently configured applications—and an important reminder that a public client key is safe only when effective access controls exist behind it.

Key takeaways

What did UpGuard find?

UpGuard began with approximately 300,000 domains showing signs of Supabase use.

The researchers tested whether common tables could be reached and used database responses to identify other accessible objects. They found 16,326 databases returning readable table information.

Because of the population’s size, UpGuard used table schemas to classify the information that could be present rather than reading every row in every database.

Selected high-risk cases were then investigated to verify that some exposures contained real data. Reported examples included:

• More than 100,000 customer records at a US valet service.
• Nearly 5,000 records at a Canadian immigration service, including 884 plaintext passwords.
• Private messages and extensive identity information from an adult-content platform.
• More than 100,000 messages associated with an OTP service.
• Records for 25,000 people held by a government consulate.

Those cases demonstrate serious real-world exposure. They do not establish that every one of the 16,326 databases contained the same amount or type of live information.

Was Supabase itself breached?

The public evidence does not show one vulnerability that compromised Supabase’s central infrastructure or every Supabase customer.

Supabase provides a Data API over PostgreSQL. Front-end applications need a client key to communicate with that API.

Supabase now calls its low-privilege client credential a publishable key; older projects may still use the legacy anon key. Both are intended for environments where users can inspect the credential.

Its presence in browser code is therefore not automatically a secret leak.

Security depends on what happens after that key is presented:

• PostgreSQL grants determine whether the anon or authenticated role may reach a table, view, or function.
• Row Level Security determines which rows that role may read or modify.
• Authentication identifies the user but does not automatically ensure that the user may access the requested record.
• Secret and legacy service_role keys bypass RLS and must remain in controlled backend environments.

Supabase recommends applying both grants and RLS to every exposed object. It also says tables created through its Dashboard have RLS enabled by default, while tables created through the SQL Editor or other tools require explicit verification.

Why can AI-assisted development amplify the problem?

AI development tools can create an application, database schema, authentication flow, and deployment very quickly.

A working application does not prove that its authorization model is correct.

Rapidly created applications may:

• Create tables without enabling RLS.
• Generate policies broader than the intended business rule.
• allow one authenticated customer to read another customer’s records.
• Expose internal tables through a Data API schema.
• Place a secret or service_role key in client-side code.
• Omit negative tests for unauthorized or cross-tenant access.
• Move from prototype to production without an independent review.

UpGuard connects much of the affected population with AI-assisted development, but the evidence does not establish that every exposed application was AI-generated.

The durable lesson applies to every rapid-development method: speed changes how quickly a mistake reaches production, not the organization’s responsibility for the result.

What should organizations audit now?

1. Inventory every Supabase project

Search:

• Approved cloud accounts.
• Source-code repositories.
• JavaScript bundles.
• DNS and application inventories.
• Developer tooling.
• Expense and procurement records.
• Acquired-company environments.

Include prototypes, hackathon projects, departmental applications, and abandoned test systems. An application outside the formal development process can still hold real customer or employee information.

2. Test authorization outcomes

For each exposed table, test what the public client can select, insert, update, and delete.

Repeat the tests using:

• No authenticated user.
• An ordinary authenticated user.
• Users from different tenants or customers.
• Administrative or support roles.
• Expired or disabled accounts.

A database can correctly reject anonymous access while still allowing one authenticated customer to retrieve another customer’s data.

3. Review grants and RLS together

RLS is only one layer.

Review:

• Object grants.
• Exposed schemas.
• Tables and views.
• Stored functions.
• SECURITY DEFINER functions.
• Storage policies.
• Default privileges.
• Realtime access.
• Data API exposure.

If the application does not require the Data API, Supabase provides an option to disable it entirely.

4. Protect privileged keys

Supabase publishable and legacy anon keys are intended for public clients. Secret and legacy service_role keys are not.

Secret keys bypass RLS and can provide full access to project data. Search browser bundles, source repositories, deployment logs, documentation, tickets, and collaboration platforms for accidental disclosure.

Replace exposed privileged credentials using Supabase’s current key-management process.

5. Investigate historical exposure

Fixing an RLS policy stops future access. It does not determine whether someone previously collected the data.

Preserve API, database, authentication, edge, and application logs. Establish:

• Which objects and records were reachable.
• Which roles could access them.
• How long the exposure existed.
• Whether suspicious requests occurred.
• Whether notification, contractual, or regulatory obligations apply.

The Infonaligy perspective

Application approval should test what unauthorized clients can retrieve—not merely confirm that authentication exists.

For every production data surface, organizations should be able to identify:

AI-assisted applications should not receive a lighter review because they were faster to build.

Infonaligy’s Threat and Vulnerability Assessments, AI Readiness Assessments, and compliance services help organizations connect application speed with security testing, data governance, and accountable production approval.

Conclusion

The significance of UpGuard’s research is not one isolated configuration mistake. It is the scale of a repeatable failure pattern.

Organizations should inventory every Supabase project, test anonymous and cross-tenant access, review grants and RLS together, protect privileged keys, and investigate past exposure.

A database is secure when unauthorized queries fail—not when the application successfully displays a login screen.

Frequently asked questions

Primary sources

• UpGuard Research
• Supabase API security documentation
• Supabase API key documentation