Vibe-coded app security: what the research actually shows

A year ago, the case that AI-built apps leak data rested on anecdotes. That has changed. Independent researchers have scanned thousands of public apps built on prompt-to-app platforms, audited apps written by the leading coding agents, and started tracking CVEs that trace back to AI-generated code.

The studies use different methods and none of them is perfect. Read together, though, they agree on where the risk sits. This post summarises four of them, links to each original, and turns the overlap into a short test plan.

In March 2025, Matt Palmer and Kody Low scanned the homepages of 1,645 apps listed on Lovable's showcase. They found 303 endpoints across 170 projects, about 10.3% of the sample, where database tables were readable without the right row-level security (RLS) rules. The issue was assigned CVE-2025-48757.

The detail that matters is why it slipped through. A policy existing is not the same as a policy being correct, and a check that only asked whether RLS was switched on would pass a table that still let anyone read every row. We cover this in Row-level security mistakes in AI-built apps.

Escape analysed more than 5,600 publicly available vibe-coded apps and reported over 2,000 high-impact vulnerabilities, more than 400 exposed secrets, and 175 instances of exposed personal data. Their methodology post is explicit that the scan was passive, so the real figures are likely higher.

Most findings again trace to permissions: backends that trust whoever calls them. Secrets in client bundles are the other recurring pattern. See Exposed secrets and PII in vibe-coded apps.

In December 2025, Tenzai had five coding agents (Cursor, Claude Code, Codex, Replit, and Devin) each build the same three apps. As SecurityWeek reported, the 15 apps contained 69 vulnerabilities. None had exploitable SQL injection or XSS. All five agents introduced server-side request forgery in the same link-preview feature, and improper API authorization was the most common issue.

Classic injection has well-known safe patterns that models reproduce reliably. Authorization depends on business rules the prompt rarely spells out, so the model has nothing to apply. More in What AI coding agents get wrong about security.

Georgia Tech's SSLab runs the Vibe Security Radar, which tracks published CVEs with clear evidence that AI-generated code introduced the bug. It counted 35 in March 2026, up from 6 in January and 15 in February. The researchers describe this as a lower bound, because many AI traces are stripped before code is published. See AI-generated code is showing up in CVEs.

Put the four studies side by side and the shape is consistent:

• The bugs are about who can see what: missing ownership checks, permissive database policies, and routes that answer without a session.
• Injection and other syntax-level bugs are comparatively rare in modern generated code.
• Every published count understates the problem, because the bugs that matter most only show up with real sessions and real data.

That is a problem for tools that read source code alone. Whether /api/invoices/42 should answer for User B is a business rule, not a code pattern. We explain the gap in Why static analysis misses access-control bugs.

1. Use the app as a normal user and record every API call the interface makes.
2. Replay each call with no session. Anything that still returns account data is unguarded.
3. Replay each call as a second account. Anything that returns the first user's data is an IDOR.
4. Read the responses for tokens, keys, emails, and stack traces.
5. Probe for routes the interface no longer calls but the server still serves, such as /debug or /.env.

This is what Routelint automates. It does not audit your database policies, CSRF tokens, or headers directly. It shows what the running app actually returns to someone who should not see it.