Vibe-coding vulnerabilities: how AI-generated sites leave holes for hackers

Vibe coding has given millions of people the ability to build apps without knowing how to program: describe the task in plain language, and the AI generates working code. It is convenient, fast and often produces an excellent result. But this accessibility hides a problem most newcomers simply don't think about: AI writes working code, but not always secure code.

The story of one site

Bob Starr, a project manager in the tech industry, used vibe coding to build "Boomberg," a tool that showed clearly how much US taxpayer money goes to tech companies. He was happy with the result and immediately launched the project publicly. That is exactly how vibe coding works: fast, from idea to product, with no intermediate steps.

Only several months later did Starr discover something alarming: the code contained a SQL injection. This is a classic vulnerability in which an attacker can read or modify data in a database simply by crafting a special query. The flaw had been there since launch. Nobody had noticed it.

"This was a clear oversight on my part.

A complete blind spot when adopting a new technology. And I'm sure others are making the same mistake," Starr told The Verge.

Why AI misses threats

AI coding tools are optimized for one thing: making the code do what is asked of it. They produce functional output quickly, but security often takes a back seat or is ignored altogether.

The problem is not the quality of the generation. The problem is that a user with no development experience doesn't know which questions to ask. After writing code, an experienced engineer will always check how data gets into database queries, who has access to administrative functions, and whether secrets have ended up in the repository. For most vibe coders, such questions simply never arise.

Typical vulnerabilities in vibe-coded projects:

• SQL injections: the code doesn't sanitize user input before passing it to the database
• Exposed API keys: secrets end up directly in the source code
• Outdated dependencies: use of libraries with known vulnerabilities
• Unprotected endpoints: administrative functions with no authorization check
• XSS vulnerabilities: unsafe rendering of data in the browser

Don't underestimate the scale

Vibe coding long ago moved beyond a niche phenomenon. Cursor, GitHub Copilot, Replit and Lovable have attracted tens of millions of users, many of whom are writing code for the first time in their lives. Some of these projects are personal experiments with no real users. But others are already live on the internet, handling real data and open to anyone.

It is important to understand that the vulnerability Starr found is not exotic. SQL injections have been on the OWASP Top 10 list for more than 15 years and remain one of the most common problems in web applications. AI reproduces them because it was trained on code that contained them.

Starr's story is telling precisely because he wasn't trying to cut corners; he simply didn't know what needed checking. That is vibe coding's main structural risk: not malicious intent, but systemic ignorance.

What this means

Vibe coding lowers the barrier to entry into development, but it does not remove responsibility for what you release onto the web. If a project handles user data or is simply reachable from the internet, a basic security audit is mandatory. Asking the same AI to check the code for vulnerabilities, studying the OWASP Top 10, or handing the project to a specialist for a quick audit is already a good start.