Why AI coding agents keep shipping OWASP Top 10 vulnerabilities

Why AI coding agents keep shipping OWASP Top 10 vulnerabilities

Veracode tested over 100 large language models on security-sensitive coding tasks. 45% of the AI-generated code samples introduced at least one OWASP Top 10 vulnerability. For Java specifically, the failure rate was 72%.

The OWASP Top 10 is not an advanced or obscure list. It has existed since 2003. Every security course covers it in the first week. These are the most studied, most documented, most discussed vulnerability classes in software development. AI models are trained on enormous amounts of code and documentation, including the documentation explaining why these vulnerabilities exist and how to prevent them.

They ship them anyway.

Understanding why it happens tells you something useful about what to look for in AI-generated code and why automated review matters in a way it did not before agents started writing the majority of production code.

The optimization problem

AI coding models are trained to produce code that satisfies a stated requirement. The requirement is usually functional: the user wants a login endpoint, a file upload handler, an API that returns user data. The model produces code that does those things, and it does it well enough that it passes basic testing and review.

Security is largely about things the code should prevent rather than things it should do. An authentication endpoint should not let users log in with empty passwords. A file upload handler should not write files to arbitrary paths. A user data API should not return another user's data. These are negative constraints, and they are mostly implicit in the prompt. The developer who asked for "a login endpoint" assumed those constraints were obvious. The model did not include them because nothing in the request mentioned them.

This is not a failure of capability. It is a failure of alignment between what the model optimizes for and what production security requires. The model is very good at writing code that does what you asked. It is consistently poor at anticipating what you did not ask for but still needed.

The 45% number reflects this gap at scale. Security is the thing that gets omitted when nothing in the request explicitly requires it.

Broken access control: the most common miss

Broken access control has been number one on the OWASP Top 10 since 2021. It is also the most common vulnerability found in AI-generated applications, which is not a coincidence.

Access control failures happen when code verifies that a user is authenticated but does not verify that they own or are permitted to access the specific resource they requested. A user logs in and receives a valid token. The token proves they are logged in. But the API endpoint they call to retrieve their profile data checks for a valid token, not for whether the profile ID in the request matches the user associated with the token. Any logged-in user can retrieve any other user's profile by changing an ID in the URL.

This is the broken object level authorization vulnerability that was open for 48 days on Lovable's platform in early 2026, affecting every project created before November 2025. It is on the OWASP API Security Top 10 at position one. And AI models write it constantly.

The reason is that authentication and authorization are two separate concepts, and a prompt that says "add authentication to this endpoint" usually gets authentication. The model returns a working implementation that checks for a valid session token. The check that the requested resource belongs to the authenticated user is a different requirement, and it gets written only when explicitly asked for or when the surrounding code makes it obvious.

Research in 2026 found that 87% of pull requests generated by Claude, Codex, and Gemini across a monitored set of builds had some form of access control gap. That number is high enough to treat it as the default assumption rather than the exception: AI-generated API endpoints should be assumed to be missing authorization checks until proven otherwise.

Injection: XSS at 86%, log injection at 88%

Cross-site scripting has also been on the OWASP Top 10 since 2003. AI-generated code fails to defend against it 86% of the time, according to a study testing five major language models. Log injection has an 88% failure rate.

Both failures come from the same root cause: AI models do not sanitize output by default unless prompted. When a model generates code that displays user-provided data in a web page, it writes the most direct implementation: take the input, put it in the response. That implementation is functional. It also accepts anything the user provides, including scripts that execute in the browser of whoever views the page.

An XSS flaw in a user profile page lets an attacker store a script that fires for every user who views the page. Depending on the application, that can mean session token theft, credential harvesting, or UI redirection. It does not require any special sophistication on the attacker's part. The stored payload just needs to get through the missing sanitization step.

Log injection works the same way. An application that logs user input without sanitizing it can be fed crafted strings that rewrite log entries, insert fake events, or break log parsers that security tooling depends on. An attacker who controls log output can cover tracks or manufacture false audit trails. The model writes the logging code, includes the user input, and skips the sanitization step that was never in the prompt.

Authentication and session management

A 153% year-over-year increase in design-level security flaws in AI-generated code was documented in 2026 research, specifically covering authentication bypass patterns and improper session management. These are not typos or missing null checks. They are architectural mistakes at the level of how authentication and session state are designed.

Common patterns include sessions that do not expire, tokens that are validated but not tied to a specific user account, password reset flows that confirm tokens without verifying the associated identity, and authentication checks that can be bypassed by manipulating request headers. Each of these comes from code that implements authentication in isolation from a complete security model.

When a model generates a password reset endpoint, it usually produces the core flow: generate a token, send an email, accept the token, update the password. What it often omits is whether the token is single-use, whether it expires, whether it can be used for a different account than the one it was generated for. These omissions do not break the normal flow. They create attack surfaces that only appear when someone is specifically trying to exploit them.

The 153% increase in these flaws tracks closely with the adoption of AI coding agents for full-feature implementation. It is what happens when models that are good at happy-path code write security flows that only look secure until someone tries to break them.

Security misconfiguration

AI-generated configuration files, infrastructure code, and deployment scripts tend to use permissive defaults. CORS policies set to accept all origins. Debug mode left on. Default admin credentials not changed. Verbose error messages that expose stack traces and internal paths. Unnecessary services enabled.

These are not logic errors. They are defaults that are convenient for development and dangerous in production. The model generates code that works in the environment it was asked about, which is usually a developer's local setup. Hardening for production requires knowing what the production threat model is, and that information is almost never in the prompt.

A scan of AI-generated Docker configurations in 2026 found that the majority ran containers as root, exposed unnecessary ports, and used base images that had not been updated in months. None of these made the containers fail to work. All of them are standard findings in a production security review.

What the 10x finding rate means in practice

The 3 to 4 times faster commit rate that AI coding agents deliver is real and documented across multiple enterprise studies. The 10 times higher security finding rate per commit is equally documented and follows directly from the same source: the models writing code quickly are the same models that omit the security constraints that were not in the prompt.

These two numbers arrive together. There is no configuration of an AI coding agent that delivers the speed without also delivering the higher finding rate, because the finding rate comes from how the model approaches code generation, not from anything that can be adjusted in a settings file.

The practical implication is that code review for AI-generated work needs to weight security checks differently than it did for human-generated work. A human engineer writing an API endpoint thought about authorization while writing it. An AI-generated endpoint may look identical but skipped that step. The review pass that catches it needs to specifically look for what the model omits, not just for what it got wrong in what it included.

The OWASP Top 10 is a reasonable starting checklist for that review: broken access control, injection, authentication flaws, misconfiguration, and the rest of the list cover most of what AI models consistently miss. Running those checks before merge, automatically, on every PR that contains AI-generated code, is the delta between shipping fast and shipping safely. The speed is worth keeping. The missing check is what creates the incident.