Some Supabase customers are publicly exposing reams of people’s data to the web
Supabase customers are unintentionally publishing massive datasets of personal information, and the problem is spreading as developers lean on AI‑generated code without proper safeguards. The exposure is not a theoretical risk; it is already visible on the public internet, putting ordinary users at the mercy of opportunistic actors. Understanding why these leaks happen and how they can be mitigated is essential for anyone who builds or consumes modern web applications.
Misconfiguration of Supabase Backends
Supabase provides a hosted Postgres layer that developers can configure through a web console, and the platform’s default settings can be permissive if not adjusted. When a table’s access policy is left open, any visitor can query the endpoint and retrieve rows without authentication. Supabase customers who fail to tighten these policies effectively turn their databases into public data dumps.
The root cause is often a misunderstanding of the distinction between development and production environments. Developers test with open access to speed iteration, then forget to lock down the same settings before launch. This gap creates a predictable attack vector that does not require sophisticated hacking—just a well‑crafted URL.
Because Supabase’s API surface mirrors standard REST conventions, the exposed endpoints can be indexed by search engines, amplifying the reach of the leaked data. The platform’s documentation mentions role‑based access control, yet many projects skip the final step of assigning roles to real users. The result is a database that behaves like an anonymous file share.
AI‑Generated and Vibe‑Coded Apps as a New Attack Surface
Recent trends show developers using AI tools to scaffold entire applications, a practice sometimes called “vibe‑coding.” The AI produces boilerplate code that includes database connection strings and default CRUD routes. When the generated code is deployed without review, it inherits the same open‑access defaults from the Supabase template.
These AI‑generated apps often lack explicit security comments, leading developers to assume the platform handles protection automatically. In reality, the AI does not embed custom access policies; it merely mirrors the example it was trained on. AI‑generated apps therefore become conduits for data exposure when paired with misconfigured backends.
Beyond code generation, the AI can suggest third‑party libraries that log requests or expose debugging endpoints. If those logs contain raw query results, they may be written to publicly readable storage buckets. The combination of auto‑generated code and default database settings creates a cascade of vulnerabilities that compound quickly.
Scale of Exposure and Public Visibility
Investigations uncovered “reams” of personal records—names, email addresses, and sometimes hashed passwords—available through simple HTTP GET requests. The term “reams” indicates that the volume is not limited to a few rows but spans entire tables, often encompassing all users of a service. This level of exposure dramatically raises the risk of credential stuffing and phishing campaigns.
Because the data is hosted on Supabase’s globally distributed infrastructure, the latency for an attacker to retrieve the information is minimal. The public nature of the endpoints also means that automated scanners can discover and catalog these databases without any targeted effort. Once indexed, the data can be sold on underground forums or used for mass‑mail spam.
The visibility is further amplified by the fact that Supabase’s domain names are often subdomains of the developer’s own brand, lending a false sense of legitimacy. Victims may not recognize the source of the breach, assuming the data originated from the primary service rather than a misconfigured auxiliary database.
What This Actually Means For You
- Any web app that relies on Supabase could be leaking data if its access policies are not audited after deployment.
- AI‑generated starter code should be treated as a draft, not a production‑ready security configuration.
- Publicly accessible endpoints can be indexed by search engines, turning accidental leaks into searchable assets.
- Even if you are not a developer, using services built on Supabase may expose you to credential‑theft risks without your knowledge.
- Regulatory compliance (e.g., GDPR, CCPA) can be jeopardized when personal data is unintentionally published.
Immediate Action Steps
First, audit every Supabase project you own or manage: review the table policies in the dashboard and ensure that only authenticated roles can read or write data. Switch any “public” permissions to “authenticated” or define granular row‑level security rules that reflect the intended user base.
Second, if you used AI tools to generate your application, conduct a manual code review focusing on database connections, CRUD routes, and any auto‑generated middleware. Replace generic access controls with explicit checks, and remove any debugging endpoints before pushing to production.
Frequently Asked Questions
How can I tell if a Supabase table is publicly exposed?
Check the table’s policy settings in the Supabase console; if the “public” role has read permissions, the data can be accessed without authentication.
Do AI‑generated code snippets include security configurations?
Typically they do not; the AI reproduces example code that often leaves databases open, so developers must add their own access controls.
What immediate risk does exposed user data pose?
Attackers can harvest emails and hashed passwords for credential‑stuffing attacks, phishing, or resale on illicit markets.
What Do You Think?
Given the ease of creating AI‑generated apps, should platform providers enforce stricter default security settings to prevent accidental data exposure?