Supabase Data Exposure Puts Vibe-Coded Apps’ Security Claims Under Pressure

Supabase is facing scrutiny after researchers identified 16,326 databases with publicly readable tables, despite the platform describing its projects as secure by default. The Supabase data exposure findings connect a familiar cloud security problem with a newer source of risk: apps assembled quickly through AI coding tools.

UpGuard found indicators of personal information in more than half of the exposed databases. The affected records reportedly included names, addresses, phone numbers, birth dates, passwords, authentication tokens, private messages, license plates, and immigration information.

This was not one breach of Supabase’s internal systems. The evidence instead points to customer databases that were exposed through missing or inadequate access controls. That distinction matters, but it does not make the scale less concerning.

The report turns a technical configuration failure into a test of the vibe-coding model. AI assistants can generate a working interface and connect it to a hosted database within minutes. They do not reliably ensure that every user, table, role, and operation receives the correct authorization policy.

What the Supabase Data Exposure Research Found

UpGuard’s central finding is not one unusually careless app, but thousands of independently built projects repeating similar security mistakes.

For its September 2026 investigation, UpGuard gathered about 300,000 unique domains showing signs of Supabase use. The researchers used data from BuiltWith and the Chrome User Experience Report to identify relevant sites.

They then tested whether each project exposed a table named users. This common table name gave the researchers a consistent starting point without requiring prior knowledge of each application’s database design.

The test produced several possible responses. A secure or inactive database returned no accessible data. Some databases disclosed another accessible table through an error hint. Others returned a page of records.

Across that candidate set, UpGuard identified 16,326 databases with readable tables. More than half contained schema fields suggesting some form of personally identifiable information, according to the firm’s exposure research.

The researchers mainly analyzed table schemas rather than downloading every available record. A schema reveals column names and data types, which can indicate whether a table contains email addresses, passwords, phone numbers, or payment information.

That approach reduced unnecessary access to personal records. It also means the 16,326 figure does not establish that every database contained sensitive information or that attackers previously copied the available data.

UpGuard investigated selected cases where the metadata suggested meaningful exposure. The examples show how a configuration mistake can cross from technical debt into direct personal harm.

One Indian adult streaming service exposed a table containing 65,467 people. Fields reportedly covered identity documents, addresses, birth dates, financial accounts, and partial government identification numbers. Another table held more than 100,000 private messages involving content creators.

A virtual SIM operation in the Philippines exposed information on more than 2,000 users and over 100,000 text messages. Most messages contained one-time passcodes, but the sample also included thousands of ordinary communications between rideshare drivers and passengers.

A United States valet service exposed records involving more than 100,000 customers. Its database included roughly 78,000 license plate numbers, about 43,000 email addresses, visit histories, tipping information, and free-text notes.

The researchers also found an African government consulate database containing 25,000 records. Some entries identified the emergency housing locations of people in a potentially vulnerable population.

A Canadian immigration service exposed nearly 5,000 records. UpGuard said 884 included passwords stored in plain text, meaning the application had failed at both access control and password handling.

These cases support the broader conclusion while also revealing different layers of failure. Public table access opened the door, but weak application design made the contents more dangerous.

The original reporting said most affected datasets appeared connected to the United States. UpGuard nevertheless found exposed projects worldwide and described the problem as global.

The geographic spread matters because Supabase serves as common infrastructure for small applications, new businesses, and established organizations. One repeated configuration pattern can therefore affect unrelated users across several industries and legal jurisdictions.

Why the Database Was Reachable From the Web

The public key inside a Supabase application is not necessarily the vulnerability. The decisive control is what that key is permitted to do.

Supabase provides a hosted PostgreSQL database alongside authentication, storage, and automatically generated data interfaces. A web application can make requests through its Data API using a publishable key.

Developers sometimes assume that finding this key in browser code proves it has leaked. Supabase explicitly designs publishable keys for public clients, including websites and mobile applications.

The actual protection comes from grants and Row Level Security, usually shortened to RLS. RLS is a PostgreSQL feature that applies authorization rules inside the database before returning or changing individual rows.

A signed-in user might receive permission to read only records carrying that user’s identifier. A signed-out visitor might receive no access at all. Another policy could allow everyone to read a deliberately public product catalog.

Supabase’s security documentation says developers must enable RLS for exposed tables and configure policies according to least privilege. The publishable key is considered safe only when those controls correctly restrict access.

The platform also provides secret or service-role keys for trusted backend systems. Those keys bypass RLS and must never appear in a browser, shipped application, or public repository.

This architecture creates a subtle security boundary. A visible publishable key is expected, but it also gives an unauthenticated visitor a route to anything the database permits the anon role to access.

If a table lacks RLS, has excessive grants, or uses a policy that allows every row, an outsider can query it through the same interface used by the legitimate app. No sophisticated intrusion is required.

The UpGuard researchers found target projects by examining publicly delivered JavaScript for Supabase identifiers. They could then ask each database whether a common table was available through its public interface.

That technique resembles ordinary application behavior. The difference lies in who is sending the request and whether the database can distinguish a permitted user from anyone else on the internet.

Supabase’s detailed RLS guidance warns that a table in an exposed schema can be readable or writable when RLS is absent and the requesting role has suitable grants. It recommends testing both allowed and denied operations for anonymous and authenticated roles.

This is why rotating a publishable key alone does not resolve the underlying problem. The new key remains retrievable from the client, while the defective database policy continues granting access.

Developers must instead review exposed schemas, table grants, RLS status, policy conditions, database views, and server credentials. They also need tests confirming that users cannot read or change another user’s records.

Views deserve particular attention. PostgreSQL views can evaluate permissions through their owner by default, potentially bypassing restrictions that protect the underlying tables. A project can therefore enable RLS everywhere and still disclose data through an unsafe view.

The same distinction applies to authentication. Requiring someone to sign in does not automatically keep tenants separate. Every authenticated user can still gain broad access if the policy merely checks for a valid session.

Supabase security explained at the key level is therefore straightforward. Public clients need a public identifier, while database policies enforce the real boundary. The difficulty is translating an application’s intended rules into complete, tested policies.

Vibe Coding Turns a Configuration Gap Into a Repeated Pattern

Vibe coding security risks grow when an AI assistant optimizes for a visible result while authorization remains hidden from the person directing it.

A conventional development team can also misconfigure a database. Public Amazon S3 buckets, exposed Elasticsearch clusters, and leaked cloud credentials existed long before generative AI entered software development.

What changes with vibe coding is the combination of speed, accessibility, and limited review. A person can request an app in natural language, accept generated code, connect a hosted backend, and deploy without understanding the trust boundaries.

The application may appear complete because registration works, records save correctly, and pages load. Those tests confirm functionality. They do not confirm that one account cannot query another account’s records.

Authorization failures are especially easy to miss during a happy-path demonstration. The developer sees the expected profile after signing in and assumes the system has protected it. An attacker asks a different question: what happens when the request omits a session or changes a record identifier?

AI coding agents also interact with infrastructure programmatically. UpGuard noted that Supabase enables RLS by default for tables created through parts of its dashboard, while programmatically created tables require additional care.

That difference can become consequential when an agent creates a database schema through SQL or an API. A protective setting attached to one creation workflow does not automatically cover every route into the platform.

Supabase acknowledged this broader usability challenge in its 2025 security review. The company said RLS is flexible but can be complex for developers who are new to the pattern.

During 2025, Supabase added safer defaults and expanded its Security Advisor. It also gave projects more control over the Data API, including the option to disable it or expose a custom schema instead of the default public schema.

Those changes help, but they do not erase existing projects or fix every generated migration. Security tooling can flag common errors, yet a policy can remain logically wrong while satisfying a basic check.

A generated rule might compare the wrong identifier, overlook an update path, or protect reads while permitting unauthorized writes. It might work for one table but leave a related table public.

The human supervising the agent must recognize that the missing behavior exists. A beginner who does not know about RLS, role grants, or tenant isolation may never ask the model to test them.

This creates an asymmetry between building and auditing. Generating a feature takes one prompt. Proving that the feature safely handles every identity and operation requires a threat model, negative tests, and careful examination of generated artifacts.

Earlier studies suggest that this is a recurring pattern rather than an isolated survey result. UpGuard cited research involving Y Combinator companies, apps made through AI development platforms, and independent sites.

Modern Pentest reported that 28 percent of 107 examined Y Combinator startups exposed personal information through Supabase configurations. Another study reviewed 1,072 vibe-coded apps and found 39 with tables readable through a public Supabase key.

The samples and methods differ, so their percentages should not be combined. However, each investigation found versions of the same failure: client-visible connection information paired with database permissions that were broader than the application intended.

A February 2026 incident made the consequences particularly visible. Security company Wiz found that Moltbook, a social network presented as a platform for AI agents, had a misconfigured Supabase backend.

According to the Moltbook investigation, the database allowed read and write access to platform data. The exposed material included 35,000 email addresses and 1.5 million API authentication tokens.

Wiz said it found the problem by reviewing client-side JavaScript during a nonintrusive assessment. The Moltbook team secured the database within hours after disclosure.

The episode offered a compact example of the current tradeoff. AI assistance helped produce a service that attracted attention quickly, but the application’s visible success concealed a critical database control failure.

For organizations evaluating AI-built software, this changes the meaning of a working prototype. A demonstration now proves less about production readiness because AI can complete visible workflows before anyone validates the security model beneath them.

An internal engineering knowledge base can help teams retain architecture decisions and review evidence. It cannot replace database tests, but it can keep security assumptions from disappearing across prompts and handoffs.

“Secure by Default” Meets Shared Responsibility

The main conflict is between secure platform defaults and a shared-responsibility model that still leaves inexperienced customers controlling consequential settings.

Supabase Chief Information Security Officer Bil Harmer told TechCrunch that the company had not reviewed UpGuard’s research before commenting. He said Supabase projects are secure by default and described security as a shared responsibility.

That position reflects a standard cloud model. The provider secures its hosted platform and offers access controls. Customers decide which users and applications should reach their data.

The distinction is valid. UpGuard did not report compromising Supabase’s corporate systems or bypassing a correctly configured RLS policy. The exposed databases belonged to customers whose settings allowed broader access.

However, defaults cannot be evaluated only at project creation. They also include the practical paths people and coding agents use to create tables, publish APIs, copy examples, and deploy applications.

A system can begin securely and later become exposed through an agent-generated migration. It can also provide a safe dashboard workflow while a programmatic workflow creates a different security state.

The phrase “secure by default” therefore needs a defined boundary. Does it mean a new project exposes nothing? Does it cover every supported table-creation path? Does it alert users before production data enters a table without RLS?

Shared responsibility also assumes that each party understands its assignment. Experienced cloud engineers know that a public client identifier must be paired with server-side authorization. Many vibe coders do not.

That knowledge gap does not make the platform solely responsible for customer mistakes. It does increase the pressure on Supabase and AI coding providers to make unsafe states harder to create and easier to detect.

The platform has already moved in that direction. Supabase’s Security Advisor checks common database issues, while its production checklist instructs users to enable RLS on all relevant tables and review policies.

A stricter design might block production access to an unprotected table or require an explicit override. Such measures would reduce accidental exposures, but they could also obstruct legitimate public datasets and rapid development.

Supabase must balance those cases without treating every public table as a vulnerability. A restaurant menu, public leaderboard, or published directory can reasonably allow anonymous reads.

The platform cannot infer intent from a table name alone. A users table is more suspicious than a products table, but an application might intentionally publish user profiles while keeping email addresses private.

Automated tools face the same ambiguity. They can detect that an anonymous role may read a table. Determining whether the access violates the product’s promise requires business context.

That is the core tradeoff. Flexible database policies let developers build many kinds of applications, but flexibility creates room for silent mistakes. Opinionated restrictions prevent mistakes while limiting legitimate designs.

AI assistants add another responsible party. A developer may select Supabase because an agent recommended it, then rely on that agent to generate the schema and policies.

The model provider does not host the database, while Supabase does not control every generated command. The app owner remains accountable to users, even when the owner cannot explain the resulting authorization model.

This fragmented chain makes security failures harder to assign and easier to repeat. Each participant can point to documentation or another party’s configuration, while the affected person only sees that private information became public.

For enterprise buyers, the practical response is to evaluate the complete development system. Vendor certifications matter, but so do deployment controls, code review, database tests, logging, incident response, and the experience of the people supervising AI agents.

What the Numbers Show, and What They Do Not

The study demonstrates a large exposure surface, but its methodology does not establish 16,326 confirmed breaches or measure the entire Supabase customer base.

UpGuard began with domains showing indicators of Supabase usage, not a random sample of every application on the platform. Its sources favored sites visible through web technology datasets.

The researchers then queried for a table named users. That choice was sensible because many applications maintain user records, but it also pushed the survey toward databases likely to contain personal information.

UpGuard disclosed this limitation. The firm said its results skewed toward PII partly because it deliberately chose a common table associated with people.

The 16,326 total covers databases exposing readable tables. It does not mean every table held confidential records. Some projects may have intentionally published data, used synthetic information, or become abandoned.

Schema analysis also measures potential exposure differently from a row-by-row forensic investigation. A column named password is a serious warning, but its existence alone does not prove that it held active credentials.

The researchers manually validated selected cases and reported concrete record counts from those databases. Those examples show that at least some exposures involved real, sensitive data at meaningful scale.

The research also cannot determine how many outsiders accessed the databases before disclosure. Public availability creates risk, but it is not proof that criminal actors discovered or downloaded the information.

This difference separates a data exposure from a confirmed data breach. An exposure means unauthorized access was possible. A breach generally requires evidence that an unauthorized party actually accessed or acquired the data.

Organizations should not use that distinction to minimize the event. Once sensitive records are reachable without appropriate authorization, investigators may lack sufficient logs to prove who accessed them.

The study also does not calculate an exposure rate across all Supabase projects. UpGuard analyzed about 300,000 candidate domains, while one organization can operate multiple domains or projects.

Inactive sites and false technology indicators can complicate that denominator. The final number is best understood as a discovered population, not a percentage of Supabase customers.

Even with those cautions, 16,326 readable databases represent a substantial attack surface. A malicious actor could automate the same general discovery process and prioritize tables containing valuable fields.

The detailed cases also weaken the argument that these were harmless demo projects. Immigration records, emergency housing locations, private adult communications, license plates, and one-time passcodes carry clear privacy and safety implications.

Supabase’s response deserves equal precision. The company said it notifies affected customers when it learns about security issues. That does not confirm how many projects were notified, how quickly they responded, or how many exposures remained open.

UpGuard said it notified application owners in significant cases it validated. Its public report did not provide a complete remediation rate for all 16,326 databases.

Those gaps should shape coverage of the findings. The evidence supports a widespread configuration problem and several serious exposures. It does not support claiming that Supabase itself was hacked or that every identified database leaked sensitive records.

It also leaves an important comparative question unanswered. Comparable hosted databases might show similar problems if researchers applied an equivalent internet-scale method.

Firebase, Appwrite, self-managed PostgreSQL deployments, and other backend services expose different interfaces and use different permission models. Developers can misconfigure any of them.

Supabase draws attention because its client-friendly architecture, automatic APIs, and popularity with AI coding workflows make the issue visible. Popularity increases both the number of safe deployments and the number of mistakes.

A fair assessment should therefore avoid framing Supabase as uniquely incapable of protecting data. The stronger conclusion is that its adoption among inexperienced builders makes access-control usability a platform-level concern.

Three Signals Will Show Whether the Risk Is Shrinking

The next phase should be judged through measurable product changes, remediation evidence, and independent retesting rather than broad security promises.

The first signal is how Supabase handles programmatically created tables. Coding agents commonly work through SQL, management interfaces, and automated migrations rather than manual dashboard clicks.

A meaningful change would make RLS and restrictive grants consistent across creation paths or require an explicit decision before a table becomes reachable through the Data API. Clear warnings inside agent workflows would strengthen that protection.

If Supabase closes the gap between dashboard and programmatic creation, it would reinforce the view that safer defaults can reduce vibe coding security risks. If the workflows remain different, inexperienced builders will continue entering unsafe states without recognizing them.

The second signal is remediation data. Supabase and UpGuard can clarify how many identified projects received notices, how many owners responded, and how many databases stopped exposing unintended records.

A high remediation rate would show that notification and security tooling can reduce the existing backlog. A low rate would suggest that many projects are abandoned, poorly maintained, or operated by people unable to fix the configuration.

Affected organizations must also determine whether exposed records require user notification or regulatory reporting. That decision depends on location, data type, access evidence, and applicable law.

The third signal is independent retesting over the next several months. Researchers should repeat comparable scans and publish transparent methods that distinguish intentional public data from sensitive exposure.

A falling database count would support Supabase’s safer-default strategy. A stable or rising count would indicate that platform growth and AI-assisted development are creating insecure projects faster than existing controls can correct them.

AI coding providers also deserve scrutiny during that retesting. Their agents should create least-privilege policies, generate negative authorization tests, and warn when a deployment exposes personal information.

Developers do not need to abandon Supabase or AI coding to respond responsibly. They need to treat generated software as untrusted until its authorization behavior has been tested.

That means checking anonymous and authenticated access separately, testing every database operation, reviewing views, protecting server keys, and disabling interfaces the application does not need.

Teams should also preserve the decisions behind those controls. A searchable AI knowledge base can connect requirements, generated migrations, audit findings, and remediation work without turning documentation into an afterthought.

The Supabase data exposure story is ultimately about an accountability gap. Platforms offer configurable controls, AI agents assemble applications, and users trust the finished interface.

Who verifies the invisible permissions before real information enters the system? Any organization shipping an AI-generated app should be able to answer that question with test results, named owners, and evidence of denied access.