Supabase Data Leak Incident: The Security Risks of Vibe Coding

Overview

A number of applications built on Supabase are openly exposing large amounts of user data on the internet. Investigation reveals that the root cause is not a vulnerability in the platform itself, but rather developers' negligence in configuration and security settings. Notably, many of the affected applications are AI-generated or products of so-called "vibe coding."

Supabase is a popular open-source Backend-as-a-Service (BaaS) platform that provides developers with an all-in-one solution for databases, authentication, and storage. Its convenience lets developers build applications rapidly — but that same convenience means that if developers don't properly understand and configure the underlying security mechanisms, they may inadvertently leave sensitive data wide open to the entire internet.

What Is "Vibe Coding" and Why Is It Risky?

"Vibe coding" refers to a development style where developers rely heavily on AI tools — such as code assistants and AI app generators — to build applications quickly, going with the flow and prioritizing speed over rigor. In this mode, developers may only care whether a feature "works," while overlooking critical security aspects like access control and data access policies.

For platforms like Supabase, a core security mechanism is Row Level Security (RLS). If developers fail to properly enable or configure RLS, records in database tables can be read directly by anyone through public API endpoints. AI-generated code frequently omits these configurations by default, or produces settings that appear functional but are actually insecure, quietly planting the seeds of a breach.

Row Level Security (RLS) is an access control mechanism provided by PostgreSQL, upon which Supabase is directly built. Once RLS is enabled, the database dynamically evaluates "does the current user have permission to access this row?" for every read or write request — for example, only allowing users to read records where user_id = auth.uid(). RLS is disabled by default — if you create a table without explicitly enabling it and writing policies, the table is effectively wide open to all roles with database connection privileges. For Supabase, this means tables without RLS enabled can be accessed anonymously via the public API. This is precisely why Supabase's official documentation and security tooling repeatedly emphasize "enable RLS first, then write policies" — yet AI-generated code, in its rush to produce table creation statements, routinely skips this critical step.

The Technical Root Cause of Data Exposure

The essence of these leaks is "misconfiguration," not "platform defects." When an application exposes the database's anonymous access key in frontend code while failing to enforce strict access policies, attackers don't need sophisticated skills — a simple API request is enough to bulk-extract users' personal information.

Data exposed in such scenarios can include usernames, email addresses, chat logs, and even more sensitive personally identifiable information. For ordinary users, they are almost always completely unaware that the applications they use carry such risks.

Supabase's public anonymous key (anon key) is not inherently a secret by design — it's allowed in frontend code because it only represents the identity of an "unauthenticated user," and real access control is supposed to be handled by RLS policies. The problem arises when developers also hard-code the service_role key (which carries superuser privileges that bypass all RLS) into the frontend, or when the anon role is granted overly broad SELECT/INSERT permissions at the database level. At that point, anyone who finds the key in their browser's developer tools can query — or even write to — the database without restriction via Supabase's REST or GraphQL interface. This is essentially the equivalent of taping your database's root password to the front door.

A Warning for Developers

This incident is a wake-up call for the entire developer community: AI has dramatically lowered the barrier to building applications, but it has not equally lowered the bar for security knowledge. The temptation to ship fast should never become an excuse to ignore security.

When using Supabase or similar platforms, developers should at minimum do the following: ensure that all tables containing sensitive data have Row Level Security enabled; never expose write-access or high-privilege keys in client-side code; perform security testing on publicly accessible API endpoints before going live; and conduct manual security reviews of AI-generated code rather than trusting it blindly.

The Responsibility of Platforms and the Ecosystem

Although the problems stem primarily from developer misconfiguration, platform providers also play an important role in these incidents. How to help security-unaware developers avoid pitfalls — through safer defaults, clearer warning prompts, and more proactive risk scanning — is a question every BaaS platform needs to address.

AI coding tool providers share this responsibility as well. When these tools generate backend code, should they inject security best practices by default? Should they issue explicit warnings when they detect potentially data-exposing configurations? As vibe coding becomes a trend, building security protections in by default will only become more critical.

It's worth noting that Supabase has already added RLS-disabled warnings to its Dashboard, and around 2024 introduced a Security Advisor feature that can scan projects for risky table configurations. However, these tools rely on developers proactively consulting them — in vibe coding scenarios driven by the rush to ship, they are often effectively ignored. Some researchers have proposed that platforms make "RLS enabled by default on new tables" a mandatory option rather than an optional prompt, to eliminate this class of configuration oversight at the source. This debate touches on the classic tension in product design between security and usability — stricter defaults protect beginners, but may introduce additional friction for experienced developers.

Conclusion

This Supabase user data leak incident reflects a deep contradiction in software development in the AI era: a leap in development efficiency paired with a mismatch in security responsibility. Technology has made "anyone can build an app" a reality — but data security remains a line that cannot be bypassed. No matter how intelligent the tools become, understanding and implementing basic security practices remains the inescapable responsibility of every developer.