Supabase Security Review: 16,000 Databases Found Publicly Readable

UpGuard research published on September 25, 2026, found 16,326 Supabase-hosted Postgres databases with publicly readable tables. The scan covered roughly 300,000 domains that showed Supabase usage. This exposure stems from customer misconfigurations rather than a platform-wide breach.

The majority of affected projects appear based in the United States, though instances surfaced worldwide. Many link to applications built quickly with AI coding tools that create tables without enabling protective settings by default.

Scale of Supabase Data Exposure

Over half the exposed databases contained schema markers for personally identifiable information. Smaller groups held passwords or authentication tokens. Very few showed indicators consistent with credit-card data. Researchers notified owners of high-impact cases but did not publish full data dumps.

Confirmed examples include a U.S. valet service with more than 100,000 customer records, a Canadian immigration service holding about 5,000 records that included 884 plaintext passwords, an Indian adult platform with 65,000 user accounts and over 100,000 private messages, a Philippines OTP service exceeding 100,000 SMS records, and an African government consulate exposing 25,000 personal records. These cases illustrate the range of sensitive data left accessible.

No evidence of widespread malicious exploitation has surfaced in public reporting. The scan relied on schema inspection rather than exhaustive record counts, so the precise total of exposed rows remains unknown.

Root Causes and Supabase Response

The primary issue involves missing or ineffective PostgreSQL Row Level Security policies combined with public or anonymous API keys that developers intend for client-side use. Tables created through automated tooling often lack RLS by default. Supabase states that projects remain secure by default and that customers control all configuration settings.

Supabase has adjusted defaults over time. Projects created after May 30, 2026, require explicit GRANT statements for Data API access. Additional changes scheduled around October 30, 2026, aim to tighten rules for new public tables. The platform also offers a Security Advisor inside the dashboard that flags tables without RLS and missing policies.

Users should review grants, confirm RLS policies cover all tables containing sensitive data, and rotate keys that appear in client code. Regular audits become especially important for teams relying on rapid or AI-assisted development workflows.

Practical Steps to Verify Supabase Projects

Begin by opening the project dashboard and navigating to Project Settings to run the built-in Security Advisor. Next, inspect every table for active RLS policies that restrict access by user or role. Then audit Data API grants and remove broad public permissions where they are unnecessary.

Teams should also examine any code that generates tables automatically and add explicit RLS statements during creation. Finally, rotate anon and service keys if they have been committed to repositories or embedded in client applications. These checks address the configuration patterns observed in the exposed instances.