Vibe Coding Security Vulnerabilities in Deployed Apps

Vibe coding security vulnerabilities are the holes that ship when an agent writes the app and nobody reviews the trust boundaries. The screen works. Who can call the API, where user input lands, and how a session is checked were filled in by the model.

What these vulnerabilities look like

Understanding the (In)Security of Vibe-Coded Applications collected 9,041 open-source apps built with Claude Code and Lovable, then audited 200 that were publicly deployed. The audit found 1,186 vulnerabilities.

91% of the deployed apps had at least one. 65.77% of the vulnerabilities were Critical or High: 18.47% Critical and 47.30% High. Three classes made up 60.20% of every finding:

• Broken access control, 339 findings, in 64% of the apps. A route or query never checks that this user may touch this row.
• Injection, 199 findings, in 54% of the apps. Untrusted input reaches SQL, HTML, or another sensitive sink.
• Authentication failures, 176 findings, in 51.5% of the apps. Login or session checks are missing or do not hold.

The authors trace the pattern to three limits of the agents: they drop an earlier constraint, they optimize for "it runs," and their security knowledge is stale. Tighter prompts and harnesses reduced the rate. They did not clear it.

A second benchmark, SUSVIBES, used 186 real feature requests from open-source projects where the human implementation had been vulnerable. SWE-Agent with Claude 4 Sonnet produced solutions that were functionally correct 57% of the time and secure 11.8% of the time. Telling the agent which vulnerability class to avoid did not close the gap.

If the product is already in users' hands, the wider repair order is in fix a vibe-coded app.

How they show up in a deployed app

Nothing crashes. A user changes an id in the URL and reads someone else's order. An admin path has no check, because the prompt said "add an admin page" and the model rendered the page. A service-role key or a Stripe secret sits in the JavaScript bundle, where anyone can read it.

A published rescue write-up listed three of these in shipped products: a Stripe secret in frontend JavaScript, an authorization bypass across 47 endpoints, and a webhook that never verified signatures. About 15% of more than $200,000 in successful payments were never recorded. The cases are written up here.

Payments are the loud version. The quiet version is a table with a policy that allows every row, or a query that trusts the client to send the right user id. The demo account only ever sees its own data, so the hole stays invisible until a second person tries.

What to check on a live AI-built app

Do these before you add another feature.

1. Search the built frontend for live secrets: Stripe keys, service-role keys, private API tokens. Rotate anything that was ever in the bundle.
2. Pick two accounts. With the second, request the first account's objects by id, on every route that reads or writes user data. A 200 is a finding.
3. Read each webhook that creates an order, a subscription, or a credit. It verifies the provider's signature before it writes. A retry does not insert a second row.
4. Check database rules, not only the UI. If a policy or query allows every row, the API will too.
5. Confirm login, logout, and password reset actually expire the session you think they expire.

The same pass belongs in what breaks once the app is in production, because a missing auth check and a wrong order total fail the same way: the request succeeds.

How Techtribe takes a security repair from here

We read the repo and try the live app with two accounts. You get the critical and high findings in writing, then a fixed price for the ones you want closed. Working screens stay. We do not quote a rewrite so the invoice is larger.

You own the code, in your repo, from the first commit. The scope call is 30 minutes with a founder. Bring the URL and whatever access you are willing to share. If the hole is already public, say so at the start of the call and we will treat the secrets as burned.