Supabase Security Review: Misconfigured Databases Expose 16,000+ Records

Supabase security review reveals that customer misconfigurations, not a platform-wide breach, exposed data across more than 16,000 databases. UpGuard researchers identified 16,326 instances where tables remained publicly readable after scanning approximately 300,000 domains. Over half of those databases contained indicators of personal information such as names, addresses, emails, and phone numbers, with smaller numbers holding passwords or authentication tokens.

The findings, published around September 25, 2026, stem from a shared-responsibility model in which Supabase supplies the infrastructure while users manage access controls. No evidence points to exploitation of a zero-day vulnerability or compromise of Supabase systems themselves. Instead, the exposures trace to missing or incomplete Row Level Security policies on tables served through the Data API.

Scale of Supabase Data Exposure and Documented Cases

Researchers located concrete examples during deeper analysis. A U.S. valet service had more than 100,000 customer records visible, including license plates and contact details. A Canadian immigration service exposed roughly 5,000 records that included 884 plaintext passwords. An India-based adult platform showed details for about 65,000 users plus more than 100,000 private messages. Additional cases involved a Philippines OTP and SIM service with over 2,000 users and 100,000 SMS records, and an African government consulate with 25,000 records containing addresses and emergency housing information. Owners received notification where significant exposure was confirmed.

These incidents align with earlier smaller-scale studies that found similar patterns among startups. The current scale reflects Supabase’s popularity with AI-assisted development tools, which reportedly account for more than 60 percent of new database creations. Tables generated programmatically through the API do not receive Row Level Security by default, unlike certain tables created in the dashboard.

Supabase has introduced safeguards since 2025, including default RLS on dashboard-created tables following issues such as CVE-2025-48757. Those protections do not retroactively apply to existing projects or API-created resources. The company’s CISO stated that projects ship secure by default and that the firm provides tooling and customer notifications, while emphasizing that configuration remains under customer control.

Root Causes and Practical Steps to Reduce Supabase Misconfiguration Risks

The primary cause involves absent or ineffective PostgreSQL Row Level Security policies combined with public or publishable keys left in client-side code. Developers who rely on AI coding agents often skip manual security checks that would normally catch these gaps. Prior research on YC startups had already shown 28 percent of sampled projects exposing PII through similar oversights.

Organizations using Supabase can reduce exposure by following a consistent audit process:

• Open the Supabase Dashboard and navigate to the Security Advisor section to identify tables without RLS enabled.
• Enable Row Level Security on every table that the Data API exposes, then apply least-privilege policies that restrict access by authenticated user ID or role.
• Review all grants and revoke unnecessary permissions from the public role.
• Rotate any publishable keys that appear in public repositories or client bundles, and store service-role keys only on secure backend servers.
• Re-run the Security Advisor after changes and schedule periodic reviews, especially after adding new tables through API calls.

Supabase continues to notify affected customers and refine default settings. No widespread reports of active exploitation have appeared in coverage to date. Teams evaluating the platform should treat configuration validation as a standard part of deployment rather than an optional step.

Implications for Teams Considering Supabase

Supabase data exposure incidents underscore that platform security depends on user implementation of access controls. The shared-responsibility model places the burden of policy definition on developers, particularly those using rapid AI-assisted workflows. Organizations handling sensitive information should incorporate automated checks for RLS coverage into their CI/CD pipelines and maintain an inventory of all tables that accept public keys.

Regular audits remain the most direct defense. Developers who follow the steps above can verify that their projects align with current Supabase recommendations and reduce the chance of unintended data availability.