What are the security risks of a vibe-coded app?

Vibe-coded apps commonly ship with unsecured databases, missing authentication, exposed API keys and code nobody can audit, all invisible to the founder who built them. Independent testing found 45% of AI-generated code introduces known security vulnerabilities. Prototypes built this way are brilliant for validation, but they are not safe to launch with real user data.

Building something you don't understand is an odd feeling. On a recent episode of The Humans Behind the Tech I admitted to spending an evening building with Claude Code, and even after six years of running a software agency (I co-founded the place, I don't write the code), it felt like building a car without knowing how the engine works. The thing on the screen looked finished. Whether it actually worked underneath was anyone's guess.

That gap, between looking finished and being finished, is where the security risk of vibe coding lives. Tools like Lovable, Replit, Bolt and Claude Code will get a non-technical founder to a working prototype in an afternoon, and that is a real superpower for testing an idea. The trouble starts when the prototype gets mistaken for a product and put in front of real users, with real data. Here's what's actually at stake, in the words of people who deal with it every week.

Can users tell a vibe-coded app from a properly built one?

No, and that's what makes this a genuine problem rather than a founder's private headache. An app on the App Store looks as legitimate as any other. Users download it, trust it, and hand over their most sensitive information without any way of knowing what's underneath.

Jason Margolin, a fractional CTO who spent years at Meta, described a story that had been doing the rounds on our podcast:

“There was an app that was super popular with women and it had really personal information that the women would store in the app. They'd vibe coded the whole thing and the data got leaked and basically, you know, thousands of women had very personal information leaked on the internet... it's on the app store, they just downloaded it.”

— Jason Margolin, fractional CTO, The Humans Behind the Tech

Whether or not that specific app was vibe-coded, the failure mode is well documented. In July 2025, the Tea app breach exposed around 72,000 images, including roughly 13,000 selfies and government IDs, followed by over a million private messages. The cause wasn't a sophisticated attack. It was a Firebase storage bucket left open with no authentication, exactly the kind of default that AI building tools will happily leave in place if nobody checks.

Jason's point about the knock-on effect is key:

“There's one thing knowing that you're building [with vibe-coding] and being a bit ignorant to it, but there's also the real knock-on effect [of] people using it and then having something go wrong for them, which is obviously not something that you want as a founder.”

— Jason Margolin

How insecure is AI-generated code?

About 45% of it fails basic security tests, and that number has barely moved in two years. Veracode's Spring 2026 GenAI Code Security update (March 2026) has now tested more than 150 AI models, including the latest GPT, Gemini and Claude releases, against the OWASP Top 10, the industry's standard list of security vulnerabilities.

‍

Three findings matter for anyone who has vibe-coded an app. First, cross-site scripting (the vulnerability that lets an attacker run their own code in your users' browsers) got through in around 85% of relevant tests. Second, the models are now almost perfect at writing code that runs (syntax correctness is above 95%) and no better at writing code that's safe; as Veracode put it, two years of revolutionary model releases have moved the security needle “from approximately 55% to... approximately 55%.”

Third, and closest to home: an April 2026 Cloud Security Alliance research note pulled together scans of 1,400 vibe-coded applications and found 2,038 critical vulnerabilities between them, including over 400 secrets (passwords and API keys) left in the code and 175 exposures of personal data, some of it medical and financial. The same note tracked 74 CVEs (publicly catalogued vulnerabilities) traced back to AI coding tools by early 2026, 35 of them in March alone.

That's the difference between a developer using AI and a non-technical founder using AI. The developer reads the output and catches the insecure defaults. The vibe coder can't, so the 45% ships.

Why can't you just ask the AI to fix its own security?

Because by the time you're asking, the codebase is usually too tangled for anyone, human or AI, to reason about. Every “actually, move that button” and “no, not like that” leaves dead code behind, and it compounds.

My co-founder Rob Lynch described the mechanics of it on the first episode of The One About AI:

“You'll end up with something that is bloated... there'll be a ton of obsolete code sitting there, so every single time you try and make [the AI] add a feature... it has got to work with its own ugly beast basically to try to add on to it. And if you go too far down that route, getting humans to try and unpick what's been done is incredibly tough.”

— Rob Lynch, co-founder, Old.St Labs, The One About AI ep1

Jason sees the same thing from the fractional CTO's chair, when founders bring him a Lovable prototype and ask him to make it work:

“With an AI wall of [a] million lines of code, it's hard to see why it does that? I'd rather build it again from scratch, because I know that the building blocks will be correct, [rather than] try and re-jig this spaghetti mishmash of code that it's generated.”

— Jason Margolin

We've done a fair few code reviews for founders in exactly this position, and what you find is wild: whole features that were “removed” months ago still sitting in the codebase, doing nothing except widening the attack surface. Code you can't read is code you can't audit, and code you can't audit is code you can't secure. Ben Burch put the timescale on it nicely: a normal software team builds up technical debt over a year and then refactors. With vibe coding, “now it'll happen in an afternoon.”

What should you do before launching a vibe-coded app?

Treat it the way you'd treat an unreviewed contract: useful draft, not something you sign. Jason's analogy is the best I've heard on this:

“My analogy is, I wouldn't draft up a contract and send it to someone as a legal document without having shown a lawyer or someone legal first, even just to eyeball it.”

— Jason Margolin

Nobody would call that lawyer a waste of money, right? Software holding other people's personal data deserves the same rigour, not least because if you're collecting personal data from UK users, UK GDPR applies to you regardless of how the code was written, and “the AI built it” is not a defence the ICO recognises.

Before you launch, you (or someone qualified) should be able to answer these:

• Where is user data stored, and who can access it? (The Tea breach was an open storage bucket.)
• Is there real authentication, or does the app just hide pages from people who aren't logged in?
• Are API keys and passwords sitting in the code itself?
• What happens under load, and what happens when someone deliberately sends the app things it doesn't expect?
• Can any human being explain what the code actually does?

If you can't answer those, you don't need to bin the prototype. You need what Jason described:

“They need to find a fractional CTO, for example, or a service like yours where someone can check it, validate it and sense check it.”

— Jason Margolin

That's the conversation we have with vibe-coded founders most weeks now. We look at what you've built, work out what's salvageable, and tell you honestly which parts can be brought up to production standard and which need rebuilding properly. Sometimes more survives than you'd fear; sometimes the prototype's real value is that it's the clearest brief you'll ever hand a development team. Either way, you'll know what you're standing on before your users are standing on it too.

Your prototype proved the idea. That was the hard part, and you did it for £20. If the question “is this actually safe to launch?” has started to nag at you, that's not paranoia, that's good instincts. We're always happy to check under the hood.

‍