Why Nearly Half of AI-Generated Code Ships With Security Flaws

An app can look finished long before it is safe to put in front of users. That gap is the whole problem with vibe coding: the demo is convincing, the screens work, and nothing visibly indicates that the parts you cannot see were never built properly.

There is now reasonable data on how often this happens.

What the research actually says

Veracode's 2025 GenAI Code Security Report tested code generated by more than 100 large language models across Java, JavaScript, Python and C#. Across those tasks, 45% of the generated samples failed security testing by introducing a vulnerability from the OWASP Top 10.

Two details are worth keeping straight, because the headline gets stretched a lot.

• The 45% figure describes code samples generated for security-relevant tasks, not "45% of apps built with AI". It is a measure of how often a model produces insecure code when asked to do something where security matters.
• The rate varies heavily by language and vulnerability class. Java failed around 72% of the time in that study, while Python, C# and JavaScript sat in the 38-45% range. Cross-site scripting was among the worst categories at an 86% failure rate.

The honest summary is not "AI writes broken code". It is that AI writes plausible code, and plausible is a much lower bar than secure. A model asked to add a login screen will produce a login screen. Whether it also produced an authorisation check on the server is not something the output advertises.

The failure mode is not code that does not work. It is code that works for the happy path and was never asked about the rest.

Where vibe-coded apps break

The problems cluster in a small number of predictable places, because these are the areas where correct behaviour is invisible in the demo.

Authorisation that only exists in the UI

The most common serious flaw. The app hides the admin button from normal users, but the endpoint behind it never checks who is calling. Anyone who can read the network traffic - which is anyone with the app installed - can call it directly.

This passes every manual test, because a human tester uses the app through its interface.

Secrets in the client

API keys, database credentials and third-party tokens end up embedded in the app bundle because that is the shortest path to a working feature. A mobile app binary is not a secret; anything inside it can be extracted.

Input that goes straight into a query

Injection flaws and cross-site scripting persist for the same reason they always have: concatenating user input into a query or rendering it unescaped works perfectly until someone sends something hostile.

Data access with no boundaries

An endpoint that returns a record by ID, with no check that the requesting user should see that record. Change the number in the request, get someone else's data. Trivial to exploit, common in generated code, and invisible unless someone goes looking.

Dependencies nobody chose deliberately

Generated code pulls in packages to solve immediate problems. Nobody checks whether they are maintained, whether they have known advisories, or whether three of them do the same job.

Why this is not an argument against AI tooling

We use AI tooling in our own builds, and it genuinely saves time on scaffolding, migrations and tests. The distinction that matters is not AI versus human. It is whether anyone competent reviewed the output against a threat model before it shipped.

A senior engineer using a model to write a first draft, then checking the authorisation path, is doing normal engineering. A founder shipping generated code they cannot read is doing something else - and the difference only becomes visible when someone probes it.

How to check your own app

If you have an app that was largely AI-generated and you want a cheap read on its exposure, start here.

1. Search the repository for hardcoded keys and tokens. If you find any, assume they are compromised and rotate them.
2. Pick your most sensitive endpoint and call it directly, without going through the app, as a user who should not have access. If it answers, you have an authorisation problem.
3. Take a record ID from your own account and change it to a neighbouring value. If you get someone else's data back, that is the flaw above.
4. Run your package manager's audit command and read the high-severity results.
5. Check what the app logs. Tokens, passwords and personal data in logs are a common and easily fixed leak.

These five checks take an afternoon and catch a meaningful share of what actually gets exploited. They are not a substitute for a real review, but they will tell you quickly whether you need one.

If the answers worry you, a structured review of the codebase is what our audit and app rescue service.

Frequently asked questions