# Is your vibe-coded app secure? Run this audit > Source: > Published: 2026-08-14 00:00:00+00:00 The Study · Explainer # Is your vibe-coded app secure? Run this audit In 2023, a Stanford team published a randomized trial that should hang over every vibe-coded launch. Forty-seven developers worked through security-relevant tasks, some with an AI assistant and some without. The assisted group wrote SQL-injection-vulnerable code 36% of the time against 7% for the control. Then the researchers asked everyone to rate the security of their own work, and the assisted group came back more confident. That inversion has since moved from the lab to the open internet. In October 2025, a security firm passively scanned 5,600 publicly reachable vibe-coded apps and logged more than 2,000 vulnerabilities and over 400 exposed secrets, most visible with no login at all. This piece reads that research so you can audit your own app before someone else does it for you. ## The short version **On security-sensitive tasks, AI ships an exploitable flaw about 45% of the time.** That is Veracode’s 2025 figure, from 80 security-relevant tasks run across more than 100 models. Read it precisely: it is 45% of tests on tasks chosen to probe security, not 45% of every line the model writes.**The sharper danger is that the code looks fine.** In a Stanford randomized trial, developers using an AI assistant wrote SQL-injection-vulnerable code 36% of the time versus 7% without one, and then rated their own code as more secure. The confidence and the risk moved in opposite directions.**It is already leaking in the wild.** A passive scan of 5,600 live vibe-coded apps found more than 2,000 vulnerabilities, 400 exposed secrets, and 175 personal-data leaks, most reachable with no login at all.**You cannot prompt your way out.** Asking the model to “clean this up” five times raised critical vulnerabilities by 37.6% in one study, not lowered them. We did not scan, test, or hack anyone’s app. Every number here belongs to a named published study with its date, and the deliverable is an eight-point audit you run on your own app, at the end. ## Why vibe-coded apps fail the same way The failures are not random. They cluster, and Endor Labs catalogues the recurring ones, each with a standard weakness ID. The same handful shows up again and again: **Secrets in the wrong place**(CWE-798): an API key hard-coded into client-side JavaScript, or committed to the repo, where anyone can read it.** Missing or removed authentication**(CWE-306): an endpoint that should require a login and does not, often because a later “make it work” edit quietly dropped the check.**String-built SQL**(CWE-89): user input concatenated into a query instead of parameterized, the classic injection.** Broken access control**(CWE-284): a logged-in user can reach another user’s data by changing an ID in the URL.** Missing input validation**(CWE-20) and** wide-open CORS**: defaults that trust input they should not. Veracode’s language breakdown shows this is not evenly spread: the secure-code pass rate was 14% for cross-site scripting and 12% for log injection, and Java came out worst at a 29% pass rate. The model writes code that runs. Whether it wrote code that is safe is a separate question, and the two look identical in a working demo. ## The overconfidence tax This is the part nobody screenshots, and it is the most important finding in the research. The Stanford trial by Perry and colleagues took 47 developers, gave some of them an AI assistant, and set security-relevant tasks. The AI-assisted group produced less secure solutions on four of five tasks. On the SQL task, 36% of AI users wrote injection-vulnerable code against 7% of the unassisted control, a gap significant at p=0.041. Then the researchers asked how secure people thought their own code was. The AI group was more confident. That inversion is the whole problem. A tool that made you slower and more worried would be self-correcting; you would slow down and check. A tool that makes you faster and more sure is the opposite, and it is the same mechanism our [study on whether AI coding makes you faster](/study/does-ai-coding-make-you-faster/) keeps running into: the felt speed is real, and it is not the same as the delivered result. ## The iteration trap The instinct, when you learn any of this, is to ask the model to fix it. Tell it to “make this production-ready” or “add security” and let it revise. The research on that instinct is discouraging. Shukla and colleagues had a model revise its own code across five rounds and measured the result: critical vulnerabilities rose by 37.6% over the iterations, not fell. The study tested GPT-4o specifically, so read it as a signal about self-revision rather than a verdict on any one model. But the direction is the point. Each pass adds surface, reinterprets the last change, and can reintroduce what the previous pass removed. Prompting harder is not a security control. A control is something that holds regardless of what the model does next. ## What is actually leaking To make the stakes concrete without touching anyone’s app, look at what a security firm found by scanning apps that were already public. Escape.tech ran a passive scan of 5,600 reachable vibe-coded apps in October 2025 and reported more than 2,000 vulnerabilities, over 400 exposed secrets, and 175 instances of leaked personal data. Passive means they looked at what was openly visible, so it is a floor, not a ceiling, and much of it needed no authentication to reach. Two caveats, because the receipts only work if we state them. That scan and the Veracode tests measure AI-generated code and live apps broadly; neither isolates a clean “non-coder only” cohort, so do not read the numbers as vibe-coder-specific where they are not. And a passive scan finds what is exposed, which understates what a determined attacker with a login would find. ## The security checklist: eight checks to run on your own app This is the deliverable. Run it against your own app, in this order, because the top of the list is where the worst and easiest-to-exploit failures live. **Auth at the edge, not in the code.** The most reliable pattern, argued well by Pythagora’s Zvonimir Sabljic, is that an unauthenticated request should never reach your application logic at all. Enforce it at the reverse proxy or your auth provider, so a missed check inside AI-written code cannot expose an endpoint. Defends CWE-306.**Grep for secrets, then rotate.** Search your repository and your shipped client bundle for anything that looks like a key or token. If you find one, assume it leaked and rotate it. Keys belong in server-side environment variables, never in client code. Defends CWE-798.**Every database query parameterized.** Find each place user input reaches the database and confirm it uses parameters or an ORM, never string concatenation. This is the single check that closes the injection Perry’s trial found most often. Defends CWE-89.**Row-level security on, and you tried to break it.** If your database supports row-level security, turn it on, then log in as one test user and try to read another user’s row by changing an ID. If you succeed, so can anyone. Defends CWE-284.**Input validated on the server.** Client-side validation is a convenience, not a defense; anything the browser checks can be bypassed. Validate on the server too. Defends CWE-20.**CORS is an allowlist, not a wildcard.** Confirm your cross-origin policy names the origins you trust rather than accepting all of them.**Rate limiting on anything that costs or authenticates.** Login, signup, and any endpoint that spends money or tokens needs a limit, or it becomes someone else’s free resource.**Your dependencies exist and are patched.** Confirm every imported package is real (models sometimes invent plausible-sounding ones) and run an audit for known vulnerabilities. Each item defends a class the research shows AI code fails at. None of them requires you to read every line the model wrote, which is the point: line-by-line review of AI output does not scale and does not catch the silent gap. Auditing the auth, data, and secrets layers does. ## Building with less of this debt The checklist is triage. To generate less of the debt in the first place: ask for security explicitly in the prompt rather than hoping for it, keep each change small enough to actually understand, use a real authentication provider instead of rolling your own, and run an automated scanner as part of shipping. Working inside the agent’s loop deliberately, the way [our Claude Code guide](/primer/how-to-use-claude-code/) lays out, is where you catch the dropped check before it ships rather than after it leaks. The close is a limit rather than a promise. No checklist makes an app secure. What this one does is make it auditable, and the research is clear that auditable is the thing vibe coding quietly takes away, right at the moment it makes you feel most sure. One email, when there's something worth sending ## Get the research in your inbox. No fixed schedule, no filler. You get an email when we've tested something, run the numbers, or found a tool worth your time. Free. Double opt-in, unsubscribe in one click. Did your app pass the eight checks? [Compare notes in the forum ↗](https://community.okaneland.com) ## Sources & how we researched this - Veracode, 2025 GenAI Code Security Report (Sept 9, 2025): across 80 security-relevant tasks on more than 100 large language models, AI-generated code introduced a security flaw in 45% of tests; secure-code pass rates were 14% for cross-site scripting and 12% for log injection, and Java was worst at 29%. veracode.com/resources/analyst-reports/2025-genai-code-security-report - Perry, Srivastava, Kumar, Boneh, "Do Users Write More Insecure Code with AI Assistants?" (arXiv 2211.03622, Stanford, 2023): a randomized controlled trial, 47 analyzed participants; AI-assisted users wrote SQL-injection-vulnerable code 36% of the time versus 7% in the control (p=0.041), and rated their own code more secure. arxiv.org/abs/2211.03622 - Escape.tech, "The State of Security of Vibe-Coded Apps" (Oct 29, 2025): a passive scan of 5,600+ publicly reachable vibe-coded apps found 2,000+ vulnerabilities, 400+ exposed secrets, and 175 instances of leaked personal data; a conservative lower bound, not proof every app is compromised. escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/ - Shukla, Joshi, Syed, "Security Degradation in Iterative AI Code Generation" (arXiv 2506.11022, 2025): asking the model to revise its own code five times raised critical vulnerabilities by 37.6%. The study tested GPT-4o, not Claude. arxiv.org/abs/2506.11022 - Endor Labs, "The Most Common Security Vulnerabilities in AI-Generated Code": the recurring failure classes, each mapped to a CWE, including missing input validation (CWE-20), SQL injection (CWE-89), broken authentication (CWE-306), broken access control (CWE-284), and hard-coded credentials (CWE-798). endorlabs.com/learn/the-most-common-security-vulnerabilities-in-ai-generated-code - Zvonimir Sabljic (Pythagora), "How to secure AI-coded (vibe coded) applications" (dev.to): the argument for enforcing authentication at the infrastructure edge rather than inside AI-written code. dev.to/zvone187/how-to-secure-ai-coded-vibe-coded-applications-18ge