> ## Content Index
> Fetch the complete content index at: https://nextwith.ai/llms.txt
> Use this file to discover other available public pages before exploring further.

# UpGuard says 16,000 Supabase databases exposed personal data, putting RLS back in focus
- URL: https://nextwith.ai/upguard-says-16-000-supabase-databases-exposed-personal-data-putting-rls-back-in-focus/
- Published: 2026-09-26T10:10:52.000Z
- Updated: 2026-09-26T10:10:52.000Z
- Description: UpGuard says roughly 16,000 Supabase databases exposed personal data, and Supabase’s own docs show why RLS, grants and testing are critical for AI-built apps.
- Author: NextWith.ai Editorial Desk
- Tags: Safety & Policy, News

[TechCrunch reported on September 25](https://techcrunch.com/2026/09/25/some-supabase-customers-are-publicly-exposing-reams-of-peoples-data-to-the-web?ref=nextwith.ai) that cybersecurity firm UpGuard found roughly 16,000 Supabase-hosted databases with some level of exposed personal data on the public web. According to the report, the exposed material included names, addresses, phone numbers, passwords and a smaller number of authentication tokens.

The reason this matters is not just the number. Supabase’s own documentation says a table in an exposed schema without row-level security (RLS) is readable and writable by any role with a grant on it. Its guidance also warns that adding policies does not automatically remove existing permissions, and that publishable keys are only safe to expose when RLS and least-privilege grants are correctly configured. The company says service-role and secret keys should never be exposed on the frontend. [Supabase RLS documentation](https://supabase.com/docs/guides/database/postgres/row-level-security?ref=nextwith.ai) and [Supabase secure data guidance](https://supabase.com/docs/guides/database/secure-data?ref=nextwith.ai) both make the same point: access control is part of the application, not an optional add-on.

That is one documented way an exposed Supabase project can leak data; the report does not establish the configuration of every database it counted. The story frames the exposures as a problem for vibe-coded apps and sites, where AI tools can accelerate app creation but do not decide which tables should be public, which roles should be able to write, or whether a view bypasses row protections. In other words, the danger is less about AI “breaking” security than about AI speeding up software assembly while the developer leaves database defaults in place.

For builders and operators using Supabase in AI-assisted products, the concrete consequence is straightforward. If the app reaches the database through Supabase’s Data API, RLS and grants need to be treated as launch requirements, not cleanup work. Supabase says the secure pattern is to enable RLS, revoke unnecessary anon and authenticated privileges, then test allow and deny behavior for select, insert, update and delete. If the app only needs trusted server-side access, Supabase’s guidance points toward Edge Functions or direct backend connections, with secrets kept off the frontend.

## What to check before launch

Supabase’s RLS guide separates two checks that an AI-generated app can easily blur. A grant answers whether a role can perform an operation at all; an RLS policy answers which rows that role can reach. A rule that restricts rows does not revoke a broad insert or update grant. Developers should inspect both for the anonymous and authenticated roles, then test that a signed-out visitor is denied private reads and writes while a signed-in user can reach only their own records.

Views need a separate look. Supabase warns that views can bypass their underlying tables’ RLS by default because of how they are created. A protected table can therefore still be exposed through a view unless that view uses the querying user’s permissions or is kept out of exposed schemas. The documentation recommends tests for both allowed and denied select, insert, update and delete operations and running the database test suite before release. These are preventive checks, not proof that they explain UpGuard’s entire sample.

The limitation is important. The 16,000 figure is UpGuard’s finding as relayed by TechCrunch, not an independently verified measurement in this article. The report also does not prove that every exposed database came from AI-assisted development, or that anyone downloaded the data. Public reachability is a security exposure; it is not, by itself, evidence of exfiltration or a confirmed breach of every affected app. Even so, it reinforces a practical point Supabase itself acknowledges: security is a shared responsibility. In the TechCrunch report, Supabase’s chief information security officer said the platform provides secure defaults and tooling, while customers control how their projects are configured.

That makes the story less about one vendor and more about a common failure mode in fast-moving AI development: a working prototype can still be an open database if access controls are assumed rather than checked. Before you ship a Supabase-backed AI app, verify each exposed table has RLS on, default grants revoked, and tests for allow/deny behavior; that is the fastest way to catch accidental public reads and writes.