Vibe coding apps leak corporate data mainly because they skip backend authentication and access control. Research that mapped 380,000 of these AI-built apps found thousands deployed with no authentication at all, granting admin rights by default to anyone who has the URL. Add hardcoded tokens shipped in the frontend and Supabase anonymous access left without Row Level Security, and the result is medical records, financial documents, and chat logs exposed to the open internet. The fix is not to stop building, but to put real backend auth, RLS, and server-side secrets back into these apps.
Short answer
The core cause is missing backend authentication and access control, not the AI itself. Security research, reported by VentureBeat, mapped 380,000 publicly accessible vibe-coded apps, of which thousands built for corporate use exposed sensitive data with no authentication. The recurring technical faults are hardcoded tokens in the client, and Supabase anonymous roles used without Row Level Security, which lets anyone with the public key read the database, the same class of flaw as CVE-2025-48757. The fix is backend authentication, RLS on every table, secrets kept server-side, and a security check before anything handling real data ships.
What "vibe coding" is, and why it leaks
Vibe coding is building an app by describing what you want to an AI, which generates the code and often the backend, so people who are not security engineers can ship working software fast. That speed is the appeal, and it is also the problem: the AI optimizes for an app that works, not one that is secure, and the person prompting it usually does not know what is missing.
What is missing is almost always the boundary between what the user can be trusted with and what they cannot. A traditional developer knows to put authentication and access control on the server. A vibe coder often does not, and the AI does not add it unless asked, so the app ships with its data reachable by anyone. Leaking is not a rare accident in these apps; it is the default outcome of skipping the parts that are invisible when the app appears to work.
The scale of the problem
This is not a handful of anecdotes; it is measured and large. A scan by the security firm RedAccess, reported widely, mapped 380,000 publicly accessible applications built on vibe-coding platforms, found around 5,000 built for corporate use, and identified more than 2,000 of those exposing sensitive corporate, operational, or personal data to the open internet, often with admin access granted to anyone holding the URL.
The table below summarizes several findings.
| Study | What it found | What leaked |
|---|---|---|
| RedAccess scan | 380,000 public apps; 2,000+ corporate apps exposing data | Medical, financial, chat logs, schedules |
| Escape.tech scan | Thousands of apps, many with no authentication | Medical records, bank numbers, personal data |
| CVE-2025-48757 | 170 Lovable projects readable via the anon key | User lists, payment records |
The exposed data was not trivial: medical records, financial documents, chatbot logs with customer details, and internal schedules. Separately, a scan by Escape.tech of thousands of vibe-coded apps found that a large share had virtually no authentication of any kind. The pattern across studies is the same, which is what makes it a category problem rather than a few bad apps.
Cause 1: skipping backend authentication
The single biggest cause is that these apps have no real authentication or access control on the backend. Many are deployed so that any request to the data endpoint succeeds, and some grant administrative rights by default, meaning anyone who discovers or guesses the URL can read and often change the data. There is no login gate because no one added one.
This happens because authentication is invisible when you are testing your own app. It looks like it works, so the missing gate is never noticed until someone else finds the open door. The remedy is basic but essential: every endpoint that returns data must check who is asking and whether they are allowed, on the server, before it responds. An app without that is not finished, however complete it looks.
Cause 2: hardcoded tokens in the frontend
The second cause is secrets shipped in the client. Vibe-coded apps frequently embed API keys, database tokens, or even admin credentials directly in the frontend, because the AI put them where the code needed them and no one moved them. Anything in the client can be extracted from the bundle or the network traffic, so a hardcoded token is a published token.
The dangerous version is a privileged token, such as a database admin key, in the client, which hands an attacker full access. The rule is simple and absolute: secret tokens live on a server the user cannot read, and the client holds only values that are safe to be public. A vibe-coded app that puts a secret in the frontend has effectively posted it online.
Cause 3: Supabase anonymous roles without RLS
Many of these apps use Supabase, and a specific, common failure is using the anonymous role without Row Level Security. The Supabase anon key is public by design, meant to be shipped in the client, and it is safe only because Row Level Security is supposed to govern what it can access. Supabase creates tables with RLS off by default, so if the generated app never turns it on, the public anon key can query and dump every table.
This is exactly the flaw behind CVE-2025-48757, where researchers found 170 Lovable projects whose tables were readable by unauthenticated requests using only the anon key. The anon key was not leaked; it is meant to be public. The failure was that nothing protected the data behind it. Enabling RLS on every table, with policies that match your auth logic, is what makes the anonymous role safe.
Cause 4: the frontend and backend boundary confusion
Underneath the specific faults is a conceptual one: vibe coders often do not understand that the client is untrusted. They treat the app as a single thing, so a check or a secret in the frontend feels as safe as one on the server. It is not, because the frontend runs on the user's device, where it can be read and changed.
Every one of the causes above comes back to this boundary. Authentication skipped, tokens hardcoded, RLS omitted, are all versions of trusting the client with something that should live on the server. Fixing vibe-coded security is largely a matter of learning this one distinction and applying it: decisions and secrets on the server, only public values on the client.
It is also a shadow-IT problem
Beyond the code, this is an organizational issue, because many vibe-coded apps are built by people outside the security process. A business user who builds a tool to handle sales data or patient schedules, without IT review, creates shadow IT that no one is watching, holding real corporate data on an app no security team approved. The 5,000 corporate apps in the RedAccess scan are exactly this.
That makes the response partly about governance, not just code. Organizations need to know these apps exist before they can secure them, so an inventory of who is building what with which data is the starting point. A perfectly written policy does nothing for an app the security team has never heard of, which is the situation vibe coding creates at scale.
What to do about it
The response combines fixing the apps and governing them. The checklist below covers both.
| Action | Why | Owner |
|---|---|---|
| Inventory vibe-coded apps handling corporate data | They are shadow IT no one is watching | Security and IT |
| Require backend authentication and access control | Stops anyone-with-URL access | The builder |
| Enable RLS, never expose the service_role key | Anonymous access must be governed | The builder |
| Keep secrets server-side, never in the client | Hardcoded tokens are extractable | The builder |
| Review and scan before shipping with real data | Catches exposure early | Security |
The technical items, backend authentication, RLS, and server-side secrets, are the same secure architecture any app needs; vibe coding just skips them by default. The governance items, inventory and review, are what catch the apps that would otherwise never reach a security team. Doing the technical work without the governance leaves the unknown apps exposed, and doing governance without the technical work leaves the known ones broken.
Catch it before it ships
Because the failures are consistent, they are also catchable, and checking an app before it handles real data removes most of the risk. A hardcoded token, a missing RLS policy, or an open endpoint are exactly the patterns a security review or an automated scan looks for, so finding them first is far cheaper than a breach.
A scanner like PTKD.com analyzes your mobile build and returns findings ordered by severity and mapped to OWASP MASVS, including embedded secrets and insecure network and storage patterns, so a vibe-coded app does not ship a leak to users. To be clear about the boundary: a build scanner checks the app you ship, not your backend configuration, so it does not replace enabling RLS, adding authentication, or moving secrets server-side. It catches the client-side exposure that starts many of these leaks; the backend architecture is still yours to get right.
What to take away
- Vibe-coded apps leak corporate data mainly because they skip backend authentication and access control.
- Research mapped 380,000 such apps, with thousands exposing medical, financial, and personal data to anyone with the URL.
- The recurring faults are hardcoded tokens in the client and Supabase anonymous roles used without Row Level Security.
- Underneath is a boundary confusion: the client is untrusted, so decisions and secrets belong on the server.
- Inventory these apps, add real auth and RLS, keep secrets server-side, and scan each build with PTKD.com before it handles real data.
