Is your vibe-coded app leaking data? Why AI-built dashboards need a pentest

TL;DR

• Tools like Lovable and Bolt let anyone build a working web app from a text prompt, and those apps often reach production connected directly to your business systems and data.
• Research across thousands of publicly deployed vibe-coded apps found exposed database credentials, API keys, and personal data, frequently discoverable within hours.
• The most common failures are missing authorisation between users, secrets left in the frontend, and a database with row-level security switched off.
• Automated scanners consistently miss this class of flaw. In one controlled test, two widely used commercial scanners caught none of the high or critical findings a human reviewer confirmed.
• A web application and AI systems pentest with human validation finds what the platform's own checks and your scanner do not.

When the person who built the app never wrote a line of code

Someone in marketing needed an internal dashboard. Someone in HR wanted a quick tool to collect applications. They did not file a ticket with IT or wait for a development sprint. They described what they wanted to an AI tool such as Lovable or Bolt, and within an hour they had a working app. It looked finished. They shared the link. It went live.

This is vibe coding, and it is now a normal way that software appears inside organisations. The problem is not that the app looks unfinished. The problem is that it looks perfectly finished while the security layer underneath was never built, reviewed, or tested. When we run a web application penetration test on one of these apps, the pattern is consistent: the interface works, and the authorisation layer behind it is wide open.

What actually goes wrong

Vibe-coding platforms generate a full application, including the backend and database, from natural language. The person prompting rarely reviews the generated code, and often cannot. That leaves three failures that show up again and again.

Secrets sitting in the frontend

AI-generated apps frequently embed database credentials, service keys, or API tokens directly in code that ships to the browser. Anyone who opens the developer tools can read them. Security firm Escape.tech scanned 5,600 publicly deployed vibe-coded applications in early 2026 and found more than 400 exposed secrets, including API keys and access tokens, alongside over 2,000 critical vulnerabilities. Every one of those was in a live production system.

No authorisation between users

The most common serious flaw is broken object level authorisation, where the app never checks whether the logged-in user is actually allowed to see the record they requested. Change an ID in the request and you see someone else's data. This is exactly the flaw that hit Lovable at the platform level in April 2026: for a period of weeks, source code, database credentials, and chat histories of projects were readable by any free account, regardless of how carefully the individual builder had configured their app.

The database left open by default

Many vibe-coded apps ship on a backend where row-level security, the control that stops one user from reading the entire table, is simply switched off. The app works fine in a demo because there is only one user. In production, with real records from real people, it means the whole dataset is one request away.

"Isn't that the platform's responsibility?"

This is the first question most IT managers ask, and the honest answer is no. Platform providers position the security of the generated app as the user's responsibility. Lovable's own position, stated publicly, is that its pre-publish scan provides recommendations and that acting on them is at the discretion of the user. When a non-technical person builds the app, that discretion is never exercised, because they do not know the recommendations exist or what they mean.

There is a second reason it lands on you. Research from RedAccess found around 380,000 publicly accessible assets built with AI coding tools, including roughly 5,000 that contained sensitive corporate data. Many were discovered while researching shadow AI, meaning unauthorised employee use of these tools without any company oversight. If a dashboard your team built is leaking your customer data, it is your incident to handle, not the platform's.

Why your scanner will not catch it

The reassuring assumption is that an automated security scan will flag these problems. The evidence says otherwise. In a controlled 2026 test, three AI-built applications with confirmed exploitable vulnerabilities were run through two of the most widely deployed commercial scanners. Between them, those scanners caught none of the high or critical findings. Not one.

The reason is structural. Broken authorisation is not a pattern in the code, it is a missing check in the logic. A scanner looking for known-bad code signatures does not see an absence. A human tester, working the way a real attacker would, changes an ID, swaps a token, and watches what the application returns. That is where these flaws surface. It is also why our AI systems penetration testing is built around manual validation rather than tool output alone. The same principle applies once an app is allowed to reach real systems on its own, which we cover in testing what an AI agent can reach in production.

What a pentest on a vibe-coded app looks like

We treat a vibe-coded app the way an attacker treats it: as a live production system with real data behind it, not as a prototype. Our ethical hackers check whether one user can reach another user's records, whether credentials or keys are exposed in the frontend or in configuration, whether the database enforces access control, and whether any AI features the app calls can be manipulated to reveal data they should not. Every finding is manually confirmed for real-world exploitability, so you get a report of what an attacker can actually do, not a list of theoretical warnings.

You do not need to slow down the teams building these tools. You need to know, before the app holds real data, whether it is safe to.

Frequently Asked Questions

What is a vibe-coded app?

A vibe-coded app is an application built by describing it in plain language to an AI tool, such as Lovable or Bolt, which generates the code, backend, and database automatically. The person building it often has no development background and does not review the generated code, which is why security gaps go unnoticed.

Are apps built with Lovable or Bolt safe to use in production?

They can be, but not by default. Research across thousands of live vibe-coded apps has found exposed credentials, missing authorisation between users, and databases with access control switched off. The app working correctly in a demo tells you nothing about whether it is safe with real data. A web application penetration test is the way to find out before it holds sensitive information.

Doesn't the platform handle security for me?

No. Vibe-coding platforms generally place responsibility for the security of the generated app on the user. Their pre-publish checks offer recommendations, but acting on them is left to the person building the app, who is often non-technical and unaware the recommendations exist.

Can't an automated scanner just check my app?

Automated scanners miss the most damaging flaws in these apps. In a controlled 2026 test, two widely used commercial scanners caught none of the high or critical findings a human reviewer confirmed. Broken authorisation is a missing check in the logic, not a code pattern a scanner recognises, which is why manual validation is necessary.

What is the most common vulnerability in a vibe-coded app?

Broken object level authorisation, where the app fails to verify that a logged-in user is allowed to access the specific record they requested. An attacker changes an identifier in a request and receives another user's data. Missing database-level access control and secrets exposed in the frontend are close behind.

Related services and resources

If your organisation is running apps built with tools like Lovable or Bolt, a web application penetration test checks the authorisation, credential handling, and data exposure that these apps most often get wrong. Where the app relies on AI features, our AI systems penetration testing extends that to prompt injection, data extraction, and the security of any tools the model can reach. For a deeper look at how AI-specific attack surfaces differ from standard testing, read our guide on AI systems penetration testing, and if your apps let an agent act on production systems, testing what an AI agent can reach covers that case directly. Not sure which applies to your situation? Tell us what your team has built and we will scope the right assessment.