Vibe coding: how secure is AI-generated code?

What vibe coding is

AI researcher Andrej Karpathy coined the term in early 2025: you describe what you want, the AI writes the code, and you barely read it. Whatever works stays. With tools like Cursor, Claude Code, GitHub Copilot, Lovable or Bolt, applications appear in hours that used to take a team weeks.

That is real progress. The risk is not the AI but the missing second look. Code nobody has read is code nobody has checked.

What the studies show

Veracode has language models solve 80 coding tasks that each have a secure and an insecure solution. In the first report in 2025, covering more than 100 models, the models chose the insecure option in 45% of cases and introduced a known flaw from the OWASP Top 10. The July 2026 edition shows little progress: on average only 56% of AI-generated code passes the security tests, and 44% contains a known flaw. Even the best model reaches 68%. Larger models are barely more secure than small ones.

The models are optimised for code that works, not for code that is secure. And they learn from public code in which the same mistakes appear millions of times.

The five typical flaws in AI code

We see these patterns in AI-generated applications again and again:

1. Missing access control. The endpoint /api/invoices/123 returns the invoice. Change the number to 124 and you get another customer’s invoice. The AI built an endpoint that works but never checks who owns the record. This is number 1 in the OWASP Top 10:2025.
2. Secrets in the code. API keys, database passwords or tokens sit right in the source, or the .env file ends up in the repository. Once it is in the Git history, it stays there. Rotate affected keys straight away. Rotate affected keys straight away.
3. Unsafe defaults. CORS open to every domain, debug mode on, missing security headers, Supabase or Firebase rules without row level security.
4. Injection. SQL queries are built from user input, HTML is rendered unfiltered. The result: SQL injection and cross-site scripting.
5. Invented or outdated packages. AI models suggest libraries that do not exist. Attackers can register exactly those names and ship malware under them (“slopsquatting”). On top of that, there are outdated versions with known CVEs. The OWASP Top 10:2025 has therefore widened the former category for outdated components into A03 Software Supply Chain Failures.

Why your tests will not find them

Functional tests check that the application does what it should. Security flaws live where it does something it should not. If user B sees user A’s data, no test fails: the page loads, the data is formatted correctly, everything is green.

That is why AI code needs a review step that thinks differently from the code that produced it.

How to use AI code safely

You do not have to give up AI. You need a few fixed guard rails:

• Security in the prompt. Ask explicitly for: an authorisation check on every endpoint, parameterised queries, no secrets in code, validated input.
• A secret scanner before every commit. Tools like gitleaks run as a pre-commit hook and stop keys before they reach the repository.
• Check dependencies. Verify every new package against the real registry and known vulnerabilities, for example with osv-scanner. Pin versions in a lockfile.
• Static analysis in CI. semgrep or a similar tool flags unsafe patterns automatically on every pull request.
• Test access with two accounts. Log in as user A and try to open user B’s data. This simple test catches many cases of the most common flaw.
• An independent review before go-live. Someone who did not write the code, a person or an independent review agent, reads it with one question: how can this be abused?

When an audit pays off

An external audit makes sense as soon as your AI-built application handles logins, customer data or payments. Typical moments: just before launch, before talking to investors, or when a customer asks for proof of security.

Our code audit reads your repository read-only, reviews it along the OWASP Top 10:2025 and documents every finding with its location, a CVSS score and a concrete fix. At a fixed price of €890 net, in 2 business days. The AI provider does not train on your code. A code audit is neither a penetration test nor a load test. The difference is explained in our code audit vs. penetration test article.

This article was created with the help of automated research and AI. David Kreutzer reviewed it and approved it on 1 November 2026.