Vibe coding security risks and how to prevent them

Why vibe coding creates security risks

In vibe coding, you describe what you want, accept what the model writes and judge it by whether the app works. That loop tests one thing well: the happy path. Security failures rarely show up there. A page that lets any visitor read every user’s orders looks exactly like a page that shows you your own orders, until someone changes an ID in the request.

Prompts make this worse. “Build a dashboard for my customers” says nothing about who may see which customer, which fields are private or which input comes from an attacker. A model fills those gaps with the shortest code that runs, and the shortest code usually skips the check. The faster changes ship, the less time anyone spends asking what the code allows, not just what it does.

Vibe coding security fails in a predictable place: the gap between “it works” and “it only works for the right person.” AI coding tools test their output by running it, and a missing authorization check, a leaked key or an injectable query all run fine. These flaws only surface when someone reads the code or attacks the app.

What the research shows about AI code security

Several independent studies have measured how often AI-generated code is insecure. They use different models, tasks and definitions, so the numbers aren’t directly comparable, but they point the same way.

• Veracode, 2025. Its GenAI Code Security Report (July 2025) ran 80 curated coding tasks across more than 100 large language models. The generated code introduced security flaws in 45% of cases. Java had a 72% failure rate, and cross-site scripting (CWE-80) failed in 86% of relevant samples.
• Pearce et al., 2022. In Asleep at the Keyboard? (IEEE S&P), GitHub Copilot produced 1,689 programs across 89 scenarios built around MITRE’s top 25 weaknesses, and about 40% were vulnerable.
• Perry et al., 2023. In a user study with 47 participants (ACM CCS), people with an AI assistant wrote significantly less secure code and were more likely to believe it was secure.
• Georgetown CSET, 2024. Testing five models, the researchers found that almost half of the code snippets contained bugs, often impactful and potentially exploitable.
• GitGuardian, 2025 and 2026. In the 2025 secrets sprawl report, public repositories using Copilot had a 6.4% secret leakage rate, against 4.6% for all public repositories. The 2026 report found Claude Code-assisted commits leaked secrets at 3.2%, against a 1.5% baseline, and GitGuardian cautions that the gap is “not a simple tool failure.”

Veracode’s 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found security flaws in 45% of the generated code. Perry et al. (2023) found that developers using an AI assistant wrote less secure code while feeling more confident in it. Together they make the case for verifying AI code, not trusting it.

The common vibe coding security risks

1. Missing authorization and row-level security

The most damaging flaw in vibe-coded apps is data that anyone can reach. Apps built on a backend-as-a-service such as Supabase talk to the database straight from the browser, so row-level security (RLS) policies are the only thing between a visitor and every row in a table. When the generated app skips them, or puts the permission check in frontend code an attacker can edit, the data is open.

The best-known case is CVE-2025-48757, published in May 2025: insufficient RLS in apps generated with Lovable let unauthenticated attackers read and write tables. The researchers’ scan found 303 vulnerable endpoints across 170 of 1,645 Lovable showcase projects, exposing emails, phone numbers, payment details and API keys; one app let anyone set payment_status: paid. The researchers work at Replit, a Lovable competitor, and Lovable disputes the CVE, saying customers own their RLS configuration. Either way, the lesson is the same: whoever ships the app has to check its access rules.

2. Secrets in code

Asked to “connect to Stripe” or “add the Gemini API,” a model often pastes the key where the code needs it, including frontend files that ship to every browser. GitGuardian’s numbers above show the effect on public GitHub. A key in a client bundle is public the moment it deploys, and a key in Git history stays there after you delete the line.

3. Injection and cross-site scripting

Models still build SQL by joining strings, render user input as HTML and pass request data to shell commands. Cross-site scripting was the weakest category in Veracode’s study. Look for raw queries, dangerouslySetInnerHTML, template output with escaping turned off, and file paths built from user input.

4. Outdated or hallucinated packages

A model suggests the libraries and versions it saw in training, which may be old enough to have known vulnerabilities. It can also invent a package name that sounds right. Attackers register those invented names on npm and PyPI, a technique called slopsquatting, so a confident npm install can pull in malware. Every new dependency in an AI-written change deserves a look: does it exist, who maintains it, and is the version current?

5. Insecure defaults

Generated code tends to pick whatever makes the demo work: CORS open to every origin, debug mode on, verbose error pages, cookies without HttpOnly or Secure, storage buckets readable by anyone, and no rate limit on login. None of these break the app, so none of them get noticed in a vibe coding session.

6. Agents with too much access, and prompt injection

Coding agents now run commands, edit files and call tools on their own. An agent with production credentials can do production damage. In July 2025, Replit’s agent deleted a production database during SaaStr founder Jason Lemkin’s vibe-coding experiment, despite a code freeze. It wasn’t a breach, but it shows what an agent with too much access can do; Replit’s CEO called it unacceptable and promised to separate development and production databases.

Agents also read untrusted text: issues, web pages, dependency READMEs. Instructions hidden in that text can steer them, which is why the OWASP Top 10 for LLM Applications lists prompt injection first and excessive agency as its own risk. Apps that call a model at runtime carry the same risks, plus improper handling of the model’s output.

How to secure vibe-coded apps: a checklist for teams

None of these steps slow vibe coding down much, and most run on their own once set up. The goal is that no AI-written change reaches production without something checking it.

1. Enforce authorization on the server and in the database. Turn on RLS for every table the browser can reach, write policies for each operation, and test them as a second user. Treat any permission check in frontend code as cosmetic.
2. Keep secrets out of code. Use environment variables or a secrets manager, keep private keys out of anything that ships to the browser, and run a secret scanner on every commit and pull request. Rotate any key that was ever committed.
3. Check every dependency. Confirm that new packages exist and are maintained, pin versions with a lockfile, and run a dependency scanner in CI so known vulnerabilities fail the build.
4. Give agents least privilege. Let coding agents work on branches and open pull requests instead of committing to main, give them development credentials only, and keep production data and deploy keys out of their reach.
5. Test what matters, not just what the agent wrote. Add tests for who can read and change each resource, for bad input and for failure paths. Tests an agent writes for its own code tend to confirm its behavior rather than challenge it.
6. Require a review check on every pull request. Use branch protection so nothing merges without a passing review, and have a person approve high-risk changes such as migrations, permissions and payment code.
7. Use a reviewer independent of the author. Where it helps, review with a model from a different vendor than the coding agent, so the review doesn’t share the author’s blind spots.
8. Harden the defaults before launch. Restrict CORS, turn off debug output, set secure cookie flags, lock down storage buckets and rate-limit login and sign-up.

For the full set of questions a reviewer should ask on each change, including a security section, see our code review checklist. The OWASP Secure Code Review Cheat Sheet and the OWASP Code Review Guide go deeper on each area.

The core control for vibe coding security is a required review on every pull request. Scanners catch known patterns such as leaked keys and vulnerable package versions, but a missing authorization check is a question of intent: someone, or something, has to read the change and ask who should be allowed to do this.

Where AI code review fits

Vibe coding produces more pull requests than a team can read line by line, so review has to keep pace without becoming a rubber stamp. An AI reviewer reads every change, and it works best when it’s separate from the agent that wrote the code: the model that wrote a change tends to accept its own reasoning, even when asked to check its work. See how AI code review works for the mechanics.

HeyDeer is built for this. It reviews AI-generated code on every push, separately from the agent that wrote it, and checks each finding against the code before posting it. Findings are labelled Critical, High, Medium or Low, and Security is one of the categories, covering anyone being able to do or see what they shouldn’t. In our benchmark of 16 agent-written pull requests, HeyDeer found 78% more real issues than GitHub Copilot code review, with the same number of false positives.

It also fits the checklist above. Set HeyDeer to review on every push, fail the check when issues are found and require the HeyDeer Review check in branch protection. Pull requests HeyDeer rates as high risk, such as permission, security or billing changes, wait for a person. Rules your team cares about, like “every API handler scopes queries to the caller’s workspace,” can live in your repository as checks HeyDeer verifies on each pull request that touches the files they cover.

A review complements your scanners rather than replacing them: keep secret scanning and dependency checks in CI. If you use Claude Code, our guide to Claude Code security review shows how to run a security review while the change is still local, before it reaches the pull request.

Sources

1. Veracode: 2025 GenAI Code Security Report
2. Pearce et al., Asleep at the Keyboard? (IEEE S&P 2022)
3. Perry et al., Do Users Write More Insecure Code with AI Assistants? (ACM CCS 2023)
4. Georgetown CSET: Cybersecurity Risks of AI-Generated Code (2024)
5. GitGuardian: The State of Secrets Sprawl 2025
6. GitGuardian: The State of Secrets Sprawl 2026
7. NVD: CVE-2025-48757
8. Matt Palmer: Statement on CVE-2025-48757
9. Fortune: AI coding tool Replit wiped a database (July 2025)
10. OWASP Top 10 for LLM Applications 2025
11. OWASP Code Review Guide
12. OWASP Cheat Sheet Series: Secure Code Review