Skip to content

Vibe coding: how secure is AI-generated code?

Vibe coding security: almost every second AI task contains a known vulnerability. The five typical flaws in AI code and how to have it reviewed securely.

David KreutzerManaging Director, Viewconic GmbH4 min read

First published on audit.viewconic.de

Contents

What vibe coding is

The term was coined by the AI researcher Andrej Karpathy in early 2025: you describe what you want, the AI writes the code, and you hardly read it any more. What works stays. With tools such as Cursor, Claude Code, GitHub Copilot, Lovable or Bolt, applications are produced in hours for which a team used to need weeks.

That is real progress. The risk is not in the AI but in the missing second look. Code that nobody has read has not been reviewed by anybody either.

What the studies show

Veracode has language models solve 80 programming tasks, each with a secure and an insecure solution. In the first report in 2025, covering more than 100 models, the models chose the insecure variant in 45% of cases and introduced a known vulnerability from the OWASP Top 10. The July 2026 edition shows hardly any progress: on average, only 56% of AI code passes the security tests, and 44% contains a known vulnerability. Even the best model reaches 68%. Larger models are hardly more secure than small ones. The models are optimised for working code, not for secure code. And they learn from public code in which the same errors occur millions of times.

The five typical vulnerabilities in AI code

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

  1. Missing access control. The endpoint /api/invoices/123 returns the invoice. If you change the number to 124, you get another customer’s invoice. The AI built an endpoint that works but does not check 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 are written directly in the source, or the .env file ends up in the repository. What has once been in the Git history stays there. Replace the affected keys immediately.
  3. Insecure defaults. CORS open to all domains, debug mode active, missing security headers, database rules in Supabase or Firebase without row-level security.
  4. Injection. SQL queries are assembled from user input, HTML is output 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 these names and put malicious code there (“slopsquatting”). Added to this are outdated versions with known CVEs. The OWASP Top 10:2025 therefore extended the former category for outdated components to A03 Software Supply Chain Failures.

Why your tests do not find this

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

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

How to use AI code securely

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

  • Security in the prompt. Ask explicitly for: permission checks at every endpoint, parameterised queries, no secrets in the code, input validation.
  • Secret scanner before every commit. Tools such as gitleaks run as a pre-commit hook and stop keys before they land in the repository.
  • Check dependencies. Check every new package against the real registry and against known vulnerabilities, for example with osv-scanner. Pin versions with a lockfile.
  • Static analysis in CI. semgrep or comparable tools find insecure 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 finds many cases of the most common vulnerability.
  • An independent review before going live. Someone who did not write the code, a person or an independent review agent, reads it with the question: how could this be abused?

When an audit is worthwhile

An external audit makes sense as soon as your AI-built application processes logins, customer data or payments. Typical occasions: shortly before launch, before a conversation with investors or when a customer asks for proof of security.

Our code audit reads your repository read-only, reviews against the OWASP Top 10:2025 and delivers every finding with its location, CVSS rating and a specific recommendation. At a fixed price of €890 net, in 2 working days. The AI provider does not train on your code. A code audit is neither a penetration test nor a load test. You can read what the difference is in our comparison of code audit and penetration test.

More on how we review AI-generated code: Have AI code reviewed.

Sources

This article was produced with the support of automated research and AI.

Security and code audit

Have your code and application reviewed. At a fixed price, with an action plan.

AI-assisted review against the OWASP Top 10, every finding with its location and CVSS rating. Fixed prices from €490 net. Not a penetration test: we only read code, and active tests of the running app take place only with your approval.

To the security audit Have your website checked for free

Further reading

More from the blog. Articles on related topics.