Vibe Coding Security Risks a Builder Actually Hits

The real vibe coding security risks are boring, repetitive, and almost always trace back to one thing, which is that nobody read the code. When you let an AI write your app and you steer by whether it runs, the machine cheerfully hands you API keys hardcoded into a file, authentication that checks nothing on the server, input it never bothered to sanitize, and imports for packages that might not even exist. I ship real products with these tools every week, and I've caught every one of those in my own generated code before it went anywhere near a user. So here's the honest short version. Vibe coding is fine for a toy and genuinely risky the second real user data is involved, and the whole gap is about review, not about the AI being evil.

The tools aren't malicious. They're optimizing for output that runs on the first try, and "runs" is a different target than "safe." Nobody trained the agent to be paranoid on your behalf.

The One Line Behind Every Horror Story

Strip off the vendor taxonomies and the incident write-ups and it's the same root cause underneath all of them.

In normal development a person reads the code before it ships. That person is the security check. Not a scanner, not a policy, a human who notices the API key sitting in plain text and goes "wait, no." Pure vibe coding, the kind where you accept the diff and never look, deletes that person. The reviewer who would have caught the hole is exactly the one who opted out of reading, by definition. That's the entire problem in a sentence, and it's why I keep saying the risk isn't the model. The risk is the empty chair where the reviewer used to sit. If you want the fuller version of what counts as pure vibe coding versus just coding fast with help, I laid that out in the honest definition of vibe coding, because the line matters more here than anywhere.

What I Keep Catching In My Own Code

Let me make this concrete instead of hand-wavy, because I've lived it.

I was building out a feature on one of my apps a while back, letting Claude Code rough in the API layer while I did something else. Came back, skimmed the diff, almost accepted it. Then I saw it. The agent had written a third-party API key directly into the source file, as a plain string, the way you'd hardcode a color value. It runs. Of course it runs. It also means the key ships in the bundle and anyone who opens dev tools can read it. I've caught that exact move more than once now, on different projects. The agent isn't trying to burn you. Putting the secret inline is just the shortest path to working code, and shortest-path-to-working is the whole personality of these tools.

The other one that got me was auth. I asked for a gated page, the kind only a logged-in user should see. The agent built a beautiful check that ran entirely in the browser. Looked completely legit in the UI. Logged-out users got bounced, logged-in users got through, ship it, right? Except the check was client-side only, which means the actual data endpoint behind it had no gate at all. Anybody who knew the URL could hit the API directly and walk out with the data, no login required. The front door was locked and the back wall was missing. I only caught it because I read the part that touched user data, which I always do, and that habit is the reason it stayed a near-miss instead of a story I'd be too embarrassed to tell.

Neither of those shipped. That's the point I want to land. The tools generated genuinely dangerous code, twice, and the only reason it didn't become a real incident was a person reading the diff. Take the person away and you've got the setup for every headline in the next section.

The Numbers, and How Far To Trust Them

Roughly one in five vibe-coded apps carries a serious vulnerability or a config error. That figure, about 20 percent, comes from Kaspersky's 2025 writeup on the trend, and it lines up unsettlingly well with everything else floating around.

Veracode's 2025 code security report found that AI models now produce code that compiles something like 90% of the time, up from under 20% a couple years earlier, which is a genuinely wild jump in capability. Here's the ugly half of the same study, though. About 45% of that code still contained a vulnerability straight off the OWASP Top 10 list, and that number had barely moved in two years. So the code got dramatically better at working and basically didn't get better at being safe. Those two curves going in different directions is the whole story of this problem, honestly.

Then there's the CodeRabbit analysis from late 2025, which went through 470 real GitHub pull requests and reported that AI co-authored code carried around 1.7 times more major issues than human-written code, with security vulnerabilities showing up 2.74 times as often and misconfigurations about 75% more common. And the one that actually made me wince, because it's a real product and real people, was Lovable. Reporting by Semafor in May 2025 found that 170 out of 1,645 apps built on the platform had a flaw that let anyone pull users' personal information. Not a lab test. Live apps with real data behind them.

I'd want to read each study's methodology before I treated any single figure as gospel, and some of the companies named in this kind of research push back hard on the framing, which is fair. Scan-based numbers can be noisy, and "has a vulnerability" covers a lot of ground from trivial to catastrophic. But when Kaspersky, Veracode, CodeRabbit, and an actual shipped-app incident all point the same direction, the direction is the takeaway. Code that nobody reviewed tends to have holes in it, and I don't need the decimal places to believe that part. I watched it happen on my own screen.

Risk, Symptom, Guardrail

Most of the security pages ranking for this will hand you a list of scary nouns and then suggest you buy their scanner. Here's the version I actually use, which maps each risk to the thing you'd notice and the specific move that stops it. Built from shipping, not from a product page.

Nothing on that right-hand column is exotic. That's kind of the depressing part. The fixes are all old, well-understood web security hygiene, and vibe coding didn't invent a single new vulnerability. It just removed the person who used to apply the fixes and sped up how fast unreviewed code reaches production.

The Default Stack Doesn't Help You Here

One thing the risk listicles skip, because they're written by security vendors and not by people who use these builders, is how much the default toolchain shapes the failure.

The popular AI app builders funnel you toward a particular kind of backend, the instant-database-with-an-API sort, and those are lovely for speed. The catch is that they lean on row-level access rules you're supposed to configure, and the agent frequently doesn't. So the database ships wide open, readable by anyone with the public key that's sitting right there in your client code. Kaspersky's teardown flagged exactly this cluster of issues, missing authentication landing on the MITRE CWE-306 weakness, secrets exposed in the page source, client-side checks that a ten-second inspection defeats. It's not a coincidence that the same handful of problems keeps recurring. The stack makes them the path of least resistance.

And a quiet one that searches for "vibe coding security risks github" keep circling. The agent writes the secret inline, you commit, you push to a public repo, and now the key is in your git history forever even if you delete it in the next commit. Bots scrape new commits for exactly this. I've made a version of that mistake and had to rotate a key over it, and I'm someone who knows to look. Somebody vibe coding their first app has no reason to even know the danger exists.

So Is Vibe Coding Safe

Depends entirely on what's riding on the app, and I mean that literally, not as a dodge.

Building a personal dashboard only you'll ever open? Vibe away. The worst case is you break your own toy and rebuild it. There's real upside to working this fast, and I'm not here to talk anyone out of it. I use these tools all day precisely because they're a genuine speed multiplier on the boring 80 percent of a build.

The moment there's a login and real user data in the picture, the calculus flips. Now unreviewed AI code is a liability with a name and an address, and pure vibe coding is the wrong tool for it. You don't have to stop using the agent. You have to start reading what it wrote, at least the parts that matter, which drags you back toward normal careful development, which is the honest and safe way to work anyway. The trick is treating the agent like a fast, literal junior who never gets tired and has zero security instincts. I got into how to actually drive one without wrecking your project over in the piece on reviewing an AI coding agent like a pull request. The reproducible AI code review workflow shows how to test whether a reviewer catches the security failure instead of merely sounding confident.

A Short List Before You Push

Not a framework. Just the handful of things I check before anything I vibe-coded goes live.

Grep the diff for anything that looks like a key or a token, and get those into environment variables. Confirm every gated endpoint checks the session on the server, not just in the browser. Run a dependency audit and eyeball any package name you don't recognize. Turn on a secret scanner so the next mistake gets caught at commit time instead of by a bot. And read the code that touches user data like a stranger wrote it, because functionally one did.

That's it. None of it is hard, none of it is new, and all of it is the stuff the agent skips because it was aiming at "works," not at "won't get us breached." The AI does the typing. Owning what goes out the door is still your job, and with security it's the part no prompt is ever going to take off your hands.