As AI began writing code for people, the barrier to building apps fell.
But the barrier to security did not fall with it.
UpGuard Research’s report, Everything Everywhere: Systemic Data Exposure in Supabase Apps, shows that gap directly. Its conclusion is simple. Many web apps using Supabase are exposing personal and sensitive data because of database misconfiguration, and the problem is being amplified by the rise of AI coding agents and vibe coding.
Supabase is not an AI company.
Its core product is a hosted Postgres database. It is a backend database service used to build web applications. But in the AI boom, Supabase has come to occupy an important position. UpGuard’s report describes Supabase as a database product often recommended by AI coding tools and well suited to users trying to build revenue-generating products through vibe coding.
The problem begins with that convenience.
Vibe coding is a way of building software in which users describe what they want in natural language, and AI coding agents generate code and help deploy it. In this flow, users can build applications without deeply understanding the code or configuration themselves. From a productivity perspective, this is revolutionary. From a security perspective, it is dangerous.
The app may be built.
But the user may not know whether database access controls and permission policies have been properly configured.
UpGuard compares this problem to earlier waves of exposure involving Amazon S3 buckets and public GitHub repositories. S3 created many data-exposure incidents because of a combination of easy setup and misunderstood access settings. GitHub grew quickly around an open default model, but that also repeatedly exposed credentials and sensitive personal information. UpGuard’s argument is that Supabase has now entered a phase of mass adoption in which insecure configuration patterns can become systemic data exposure.
In other words, the problem is not simply one developer’s mistake.
A tool becomes popular quickly.
Users do not fully understand security settings.
AI coding agents prioritize making the app work.
When these three conditions combine, misconfiguration becomes a pattern rather than an exception.
There had already been warnings.
In March 2025, developer Matt Turner reported widespread misconfigurations in Supabase databases created by the vibe-coding platform Lovable, according to UpGuard. The simplest form of vulnerable setup was a lack of controls preventing anyone from querying the database. Later research found other exposure patterns as well, including policies that existed but did not sufficiently restrict access, and public keys shared in client-side code being treated as if they were secret keys.
Supabase has made improvements.
According to the report, Supabase changed its product so that Row Level Security, or RLS, is enabled by default for tables created through the Table Editor UI. But tables created programmatically through APIs — the path AI coding agents often use to interact with Supabase — do not automatically receive the same default RLS activation. Even when RLS is enabled, data is protected only if policies are properly configured and credentials are used correctly.
This is the key point.
Having a security feature is not the same as having security.
Having RLS is not the same as having RLS properly configured.
Having an AI-generated app is not the same as having a safe app.
UpGuard collected roughly 300,000 domains showing signs of Supabase use. Researchers identified Supabase usage by looking for Supabase key names and database URLs in public JavaScript files. They built a candidate set using sources including BuiltWith and the Chrome UX Report, then tested whether common tables such as users could be queried.
The result was substantial.
UpGuard identified 16,326 databases with readable exposed tables. Because the number was too large to read every row, researchers analyzed table schemas to assess what types of data were potentially exposed. They found that more than half of the databases showed indicators of personal information, while a smaller share included passwords or authentication tokens. Some showed possible credit card data, and payment-system traces were more common.
This is not only a Supabase problem.
When apps built by AI coding agents become real businesses, collect customer data, connect to payment systems and manage user accounts, database misconfiguration becomes real harm. It is no longer merely a personal project gone wrong. Customer information, business data, payment flows and supply-chain data can be exposed.
UpGuard also examined industry-level impact.
E-commerce and restaurant-related sites were more likely to handle personal data and integrate payment systems in exposed databases. Unauthorized online betting services showed a higher likelihood of exposed passwords and other credentials. Companies selling industrial goods also showed high exposure risk, which matters because they may sell to business customers and handle enterprise data, creating potential supply-chain risks.
One interesting point is that whether a site was B2C or B2B did not appear to create a large difference in the types of exposed data.
The report explains that exposure patterns did not vary dramatically based on whether the site served consumers or businesses. The reason is that security configuration does not depend on business type. The shared problem is that humans may understand what business they are building, but not understand the database access model beneath it.
That is the central paradox of vibe coding.
Users may know what business they want to build.
But they may not know what database permission structure that business is running on.
AI implements features.
But it may not correctly encode every security intention.
As a result, the app works.
But the data may be open.
The real cases cited by UpGuard make the risk more concrete.
In an India-based OnlyFans-like site, the users table exposed 65,467 individuals. The data included ordinary personal information such as names, email addresses, dates of birth and addresses, but also driver’s license information, passport details, PAN card numbers and the last four digits of Aadhaar numbers. Financial data linked to PayPal, Payoneer, Zelle, crypto wallets, bank accounts and Stripe accounts was also present. A separate messages table contained more than 100,000 private messages exchanged with adult-content creators.
A Philippine OTP service case was also severe.
The exposed database contained more than 2,000 users with information including email addresses, phone numbers and wallet balances. It also contained more than 100,000 SMS messages with OTP codes, sender IDs and SIM codes. UpGuard said most sampled messages were OTP codes, but thousands appeared to be ordinary person-to-person text messages, many seemingly exchanged between drivers and passengers of a ride-hailing service in the Philippines.
This case shows the secondary harm of data exposure.
Messages from people not directly connected to the service may also be exposed. In infrastructure such as SIM farms or OTP services, which can be connected to cybercrime supply chains, third-party data may be exposed as collateral damage.
In a U.S.-based valet service case, data for more than 100,000 customers was exposed. Each customer record included a phone number, while tens of thousands also included email addresses and full names. Many records included license plate data, and the database also contained visit history, lifetime value, tip history and free-text notes. An employee users table contained email addresses, phone numbers and push tokens for hundreds of employees.
This case shows that personal data can extend far beyond contact information.
Valet-service data is not only names and phone numbers. It can include who visited when, how much they spent, what notes were written about them and what vehicle they used. That can become marketing data, location data and lifestyle-pattern data.
The case involving an African consulate was more sensitive.
UpGuard said it found a Supabase database related to a consular service operated by an African government, containing personal information and physical addresses for 25,000 users. Given the nature of the service, the affected individuals appeared to be a vulnerable population, and another field identified which emergency housing facility some individuals were currently staying in.
This moves beyond startup security immaturity and into public-interest and human-rights risk.
Emergency housing location is highly sensitive information. If the physical addresses and shelter locations of vulnerable people are exposed, the harm can move beyond privacy into physical safety. Database misconfiguration can sometimes create direct real-world risk.
There was also a Canadian immigration and settlement-service case.
In an exposed database for a service providing coaching and advice to people moving to Canada, UpGuard found about 5,000 users records. Nearly all contained full names, email addresses, phone numbers and dates of birth, and 884 records contained plaintext passwords.
Plaintext passwords are a basic security failure.
But in a vibe-coding environment, even basic failures can occur. When a user asks AI to create a login feature, the app may look like it has login. But password hashing, access control, session management and database policies are separate questions.
UpGuard’s conclusion is clear.
Data exposure is the product of the potential for technical misconfiguration multiplied by the size of the user base. Few technologies achieve both. Supabase, as a near-default database choice for vibe-coded apps, shows how mistakes by humans or AI coding agents can scale across geographies, industries and business models.
That framing matters.
Security incidents no longer happen only because of sophisticated hackers.
If someone quickly adopts a convenient tool, AI builds the app and the user deploys it without understanding the security settings, the data may be quietly open.
Vibe coding democratized development.
But democratizing development does not automatically democratize security. In fact, as more non-experts build apps that handle real customer data, the total volume of security mistakes can increase. In the era of AI-generated code, the difference between “a working app” and “a safe app” must become much clearer.
The evaluation logic of AI coding agents is part of the problem.
AI models are improved through reinforcement learning and user satisfaction. If a database product works smoothly and users are pleased with the result, AI tools may be more likely to recommend that product in the future. Supabase is designed to be easy for AI coding agents to use, and that ease reinforces recommendation and adoption.
Security is often pushed behind that convenience.
AI agents are good at quickly making features work. Sign-up, login, profiles, payments, admin pages and messaging can appear in front of the user and produce satisfaction. But whether database permission policies are correct, whether public and secret keys are separated, whether RLS is applied to API-created tables, and whether the users table is readable from outside are not always visible.
Security is invisible until it fails.
That is why Supabase misconfiguration is also a software supply-chain problem in the AI era.
An AI-built app is not an isolated code snippet. It is a connected system of database, authentication, payments, messaging, storage, deployment platform and external APIs. If one part is misconfigured, customer data can be exposed. Users may think the app is complete because AI built it, but the responsibility does not disappear.
Who needs to change?
First, platforms must change.
Tools such as Supabase need safer defaults even through the paths AI coding agents use. If RLS is enabled by default in the Table Editor UI but not in API-created tables, then in the age of AI coding there is still a gap. The path most used by AI agents becomes the most important security path.
Second, AI coding tools must change.
Tools such as Claude Code, Codex, Lovable and Replit must go beyond generating working code. They need to verify and warn about security configuration. If a users table is created, the tool should check whether RLS is enabled, whether it is readable with a public key, whether passwords are stored in plaintext, and whether sensitive fields are exposed.
Third, user expectations must change.
Vibe coding makes it possible to build prototypes quickly. But the moment an app receives customer data, it is no longer a toy. If the app stores email addresses, phone numbers, dates of birth, payment accounts, messages, addresses, license plates, passport information or emergency housing locations, security review is not optional.
Fourth, external checks are needed.
AI-generated apps are growing quickly, but the people who create them may not understand the security model. Automated security checks, exposure scans, database policy tests and key-management checks before deployment may need to become standard practice.
UpGuard’s report does not exaggerate the risk of AI coding agents.
The issue is not that AI maliciously leaked data. The more realistic problem is that AI makes app development so easy that apps whose creators do not understand the security settings are also easy to deploy. This risk is quieter and wider.
And that quietness is what makes it dangerous.
Even when a database is exposed, the app may continue to function normally.
Users can log in, place orders and send messages.
Operators may think the service is running well.
But attackers or researchers can follow public JavaScript and API keys to read the database.
On the surface, it is a successful app.
Inside, it is an open database.
Supabase is a successful tool of the AI era. That is not the problem in itself. The problem is that when a successful tool’s security defaults and user understanding do not keep up, the consequences can spread globally.
S3 went through this.
GitHub went through this.
Now Supabase is facing the same test.
In the age of AI coding agents, people who are not developers can build apps. That means databases need safer defaults, AI tools need more conservative security judgment, and platforms need to prevent misconfiguration at the product level.
The next challenge for vibe coding is not faster development.
It is proving that AI-built apps are safe enough to hold customer data.
