The hidden risk of vibe coding: apps that work but aren't secure

Bob Starr was thrilled with the website he had just built. "Boomberg", a site that showed how much US public money ends up in the hands of big tech, went live the moment he finished it. The catch: Starr had not coded it, he had dictated it to a language model, describing what he wanted. It was not until months after publishing that he realised it carried a hidden SQL injection risk, an open door that had been there the whole time without anyone noticing.

That case opens a Verge report on the security risks of apps built with vibe coding, and it captures the underlying problem well: when a model writes the code and whoever publishes it cannot read it, the flaws do not disappear, they just become invisible to their author.

What vibe coding actually is

The term describes a way of programming in which the user explains in natural language what they want and lets a model generate the code. It works reasonably well for prototypes and internal tools, and it has lowered the barrier to entry so much that anyone with an idea can have something running in an afternoon. That is precisely its appeal and its trap.

The problem is not that generated code is bad by definition. It is that the model optimises for "make it work" and for "make it look like what you asked for", not for "make it secure in production". A prototype that runs on the first try can carry plain text credentials inside, unauthenticated endpoints or database queries built by concatenating strings, the classic pattern that opens the door to SQL injection.

Why it matters more now

Two years ago, publishing an app meant going through someone who at least knew how to read the code. Today that filter has disappeared for a growing share of projects. The Verge points to the volume of sites and tools spun up this way growing fast, and with it the attack surface: exposed databases, unvalidated forms and API keys that end up in public repositories.

The difference from a normal bug is the asymmetry of knowledge. Someone who writes code by hand and introduces a flaw has, at least, the chance to understand it when it is pointed out. Someone who delegated everything to a model often does not even know where to look. The site works, it looks fine, and the hole only shows up when someone exploits it or, with luck, when a third party warns them.

Who this is useful for

For anyone building products with coding assistants, and very particularly for those doing it without prior technical training. This is not an argument for going back to writing everything by hand. It is a reminder that generating code and publishing it are two separate decisions, and that the second one demands a minimum of review.

There are basic measures that cover most of these cases: explicitly asking the model for parameterised queries instead of concatenated ones, moving any credential to environment variables, never pushing keys to the repository and running a security scanner before exposing anything to the internet. Tools like Claude Code let you directly request a security review of the generated code itself, something worth turning into a mandatory step rather than an optional extra.

None of this is new for anyone who has spent years in development. What is new is the number of people who now publish software without having gone through that curve. Vibe coding did not invent SQL injection, it has been on the list of most common flaws for decades, but it has multiplied the number of people capable of introducing it without realising.

At ElephantPink we see it daily: coding assistants are an extraordinary tool for moving fast, and speed is not at odds with security as long as generated code is treated with the same distrust as any other. The practical rule is simple: if you do not understand what you are about to publish, at least ask someone, or something, to review it first.