Vibe coding security risks: what has gone wrong and how to ship safely

The main vibe coding security risks are code that ships without anyone reading it: generated code with common flaws, databases with no authorization rules, API keys bundled into the browser, dependencies the model made up, and agents holding shell or production access. Each has already caused real damage. In 2025, a missing database rule in apps built with Lovable exposed user data across at least 170 projects, and Replit's agent deleted a production database during a code freeze. None of this means you should stop. It means the review step has to come back before anything reaches real users.

What vibe coding changes about security

Vibe coding means building software mostly by describing what you want and accepting what the AI writes, often without reading the code. That is fine for a prototype. The risk starts when the prototype gets real users, real data and real credentials, because the person who built it may never have seen the code that handles them.

Classic security review assumes someone wrote each line on purpose and can explain it. With vibe coding, the author is a model, the reviewer is often absent, and the agent doing the work usually has the same access as the developer. The risks below follow from that.

Vibe coding security risks in generated code

Veracode tested more than 100 language models on 80 coding tasks and reported in July 2025 that about 45% of the results contained security flaws. Java fared worst, failing more than 70% of the time, and the models failed to defend against cross-site scripting in 86% of relevant tasks. Veracode also found that newer and larger models wrote more working code but not more secure code.

Studies of people using AI assistants point the same way, with one important caveat. A study by Perry and colleagues found that participants with an AI assistant wrote significantly less secure code than those without one, and were more likely to believe their code was secure. A USENIX Security 2023 study of C programming found a much smaller effect: AI-assisted users produced critical security bugs at a rate no more than 10% higher than the control group. The honest reading is that AI code is not automatically worse, but confidence goes up faster than quality, and that gap is where flaws ship.

Missing authorization: the Lovable case

The most common failure in vibe-coded apps is not exotic. It is a database that anyone can read. CVE-2025-48757 covers apps built with Lovable on Supabase that shipped without proper row level security rules. Because the app's public key sits in the browser, anyone could query the database directly without logging in.

According to Superblocks' write-up of the disclosure, researcher Matt Palmer reported the issue to Lovable on March 21, 2025, and a follow-up scan found 303 exposed endpoints across 170 projects, leaking names, emails, payment status and API keys. Lovable added a security scan in April; Pluto Security notes that the platform's position is that customers remain responsible for configuring those rules correctly. Whoever is responsible, the user who never read the generated policy is the one who gets breached.

Who owns the risk

Platforms, model providers and builders tend to point at each other after an incident, as the Lovable case showed. For a company, the answer is simpler: the team that ships the app owns its security, whatever tool wrote the code. That means vibe-coded apps go through the same review as any other software before they touch customer data, and the security team needs to know they exist. An internal tool built in an afternoon by a marketing manager is still an application with a database, users and credentials.

Secrets in the browser and in the repo

Generated front ends often call APIs directly, which puts the API key in code every visitor downloads. Ask an agent to "add OpenAI" or "connect Stripe" and check where the key ends up. Anything in client-side JavaScript is public.

Secrets also leak through repositories. GitGuardian counted 23.8 million new secrets leaked on public GitHub in 2024, up 25% on the year before, and found that 70% of secrets leaked in 2022 were still valid. A vibe-coded project pushed to a public repo with an .env file is how a key ends up in that count.

Hallucinated packages and slopsquatting

Models sometimes suggest dependencies that do not exist. A study by Spracklen and colleagues analyzed 576,000 code samples from 16 models and found that 19.7% of the packages they suggested were hallucinated, with 205,474 unique made-up names. An attacker who registers one of those names on npm or PyPI gets their code installed by anyone who runs the suggestion without checking. This is called slopsquatting.

The defense is simple and often skipped: before installing a new package, confirm it exists, check its publisher and age, and pin the version. It is the same check our guide to malicious MCP servers recommends for agent tools, for the same reason.

Agents with shell, MCP and production access

The newest vibe coding security risks come from the agent, not the code. Coding agents run commands, install packages and load MCP servers, often with the developer's own credentials. In July 2025, Replit's agent deleted a production database holding records on more than 1,200 executives during a declared code freeze, according to Fortune, and then told the user the data could not be recovered. Replit's CEO said the company would separate development and production databases automatically.

The lesson is to keep production credentials out of the agent's reach and to review what it is allowed to run. Our guides to Claude Code security risks and Cursor security risks cover the settings that control this in each tool, and every MCP server the agent loads is code running on your machine.

Asking the AI for secure code helps, but does not replace review

Telling the model what you care about changes what it writes. A prompt that says "use parameterized queries, check the user owns the record before returning it, and never put keys in client code" gets closer to safe code than "build a notes app". It is worth adding these rules to the project instructions file your coding agent reads on every request, so you do not have to repeat them.

It is not enough on its own. The Veracode results above come from models that were asked to write working code, and many still chose the insecure option when a secure one was equally easy. The model does not know your threat model, your data or your users. A short, structured review by someone who knows where vibe coding security risks usually hide catches what the prompt missed, and it takes far less time than cleaning up after a breach.

A short checklist before a vibe-coded app goes live

Read and test every authorization rule, including database row level security, with a logged-out user. Search the built front end for API keys, and move any you find to the server. Verify every dependency exists and comes from the publisher you expect, then pin versions. Run a dependency and code scanner on the repository. Keep the coding agent on a development database with credentials that cannot touch production. Review which MCP servers the agent loads, using the MCP security checklist. Finally, ask a person who did not build it to try to break it.