AI code generators have fundamentally changed how developers write software—and how security reviewers must think about pull requests. When an AI copilots a feature from natural language, it can produce syntactically flawless code that is nevertheless riddled with subtle security flaws. This is why AI code generators introduce new OWASP risks, and the skills you use to review human-written code are no longer enough. In this article, we walk through a realistic case study of an AI-generated pull request, showing exactly where an OWASP Top 10 vulnerability can hide and how a careful reviewer can catch it before it goes live.
The New Reality: AI-Generated Code in Your PR Queue
By 2026, most development teams rely on AI assistants for everyday tasks—writing a function, scaffolding an endpoint, or building a data migration. The problem is that these models are trained on vast amounts of public code, including code that was never secure. They do not reason about security; they predict patterns. If the pattern is an unsafe query or insecure deserialization, the model will happily reproduce it. Moreover, AI-generated code often looks clean and well-commented, which gives reviewers a false sense of confidence.
To be clear, the threat is not that AI invents new attack techniques. The threat is that it amplifies existing, well-known weaknesses—exactly those in the OWASP Top 10—at a speed and scale that human reviewers cannot match. The best defense is a dedicated security review process that treats every AI-assisted commit with suspicion. In this case study, you’ll see how that plays out in a real diff.
Case Study: A Seemingly Harmless Data Export Feature
A mid-sized SaaS company uses an AI coding assistant to accelerate feature development. One afternoon, a developer asks the assistant to “create an endpoint that exports user data as XML, with a date range filter.” The AI returns a complete implementation, including a controller, a service, and an XML serialization utility. The developer opens a pull request and requests review from a security-minded colleague.
The diff looks tidy. The code is documented, uses the project’s standard logging, and even includes unit tests. Without the right mindset, a reviewer might approve it in minutes. But this is exactly the scenario where AI code generators introduce new OWASP risks—and the security reviewer decides to look deeper.
The Pull Request: What the AI Produced
The AI-generated code included three key pieces. First, the controller accepted a fromDate and toDate parameter and passed them directly to a service method. Second, the service used string concatenation to build an XML document, using the user-supplied dates. Third, the XML serializer used a custom class that applied XmlSerializer without any type restrictions. The code compiled, the tests passed, and nothing in the internal security scanner raised a flag—yet.
Spotting the OWASP Top 10 Risks in the Diff
The security reviewer went through the diff line by line, comparing each change against the OWASP Top 10. Here are the five risks they identified:
- SQL Injection (A03:2021 – Injection): The service method used a raw SQL query to fetch records by date. Because the dates were concatenated directly into the query string, an attacker could submit a crafted
fromDatevalue containing a single quote and a UNION SELECT statement. The AI had not used a parameterized query, even though the project’s codebase used an ORM with prepared statements everywhere else. - Insecure Deserialization (A08:2021 – Software and Data Integrity Failures): The XML serializer used
XmlSerializerwith the data type inferred from the input. An attacker who could control the XML payload could leverage a known deserialization gadget to execute arbitrary code. The AI chose the fastest serialization path, not the safest one. - Security Misconfiguration (A05:2021 – Security Misconfiguration): The endpoint did not enforce authentication or authorization. The AI assumed that because the controller was under an authenticated base path, it was enough. It did not check whether the current user had permission to export data for the requested date range—a classic IDOR (Insecure Direct Object Reference) waiting to happen.
- Improper Error Handling (A05:2021 – Security Misconfiguration or A02:2021 – Cryptographic Failures if sensitive data in errors): The XML builder wrapped parse errors in a generic exception handler that returned the full stack trace to the client. This leaked internal class names, database table names, and even connection string fragments.
- Excessive Data Exposure (A01:2021 – Broken Access Control / A04:2021 – Insecure Design): The export service fetched all columns for each user record, including internal notes and password hashes, and serialized them into the XML response. The AI did not understand the domain rule that only public profile fields should be exported.
None of these vulnerabilities were immediately obvious to the developer, and the AI did not flag any of them. The reviewer had to translate the AI’s confident, well-formatted code into the language of OWASP—and then explain it to the developer so the fix would be adopted.
Reviewing AI-Generated Code: A Checklist
This case study is not meant to scare developers away from AI assistants. It is meant to guide them. The most effective reviews of AI-generated code focus on the same high-risk areas repeatedly. Use this checklist when you see an AI-assisted pull request:
- Check every SQL query for parameterization. Do not trust that the AI saw your existing patterns.
- Look for direct use of XML, YAML, or binary serializers that accept user input. Enforce strict type allowlists and validate input before deserialization.
- Verify that the code honors authorization boundaries. Can a user request data they do not own? Does the code check permissions before executing sensitive operations?
- Inspect error responses. Are stack traces or internal exception messages exposed to the client? If so, replace them with generic, user-safe messages and log the details server-side.
- Review the data returned to the client. Does the response include more fields than necessary? If the AI copied a broad “get all data” method, it will leak sensitive information.
- Look for hardcoded secrets, keys, or tokens. AI models sometimes generate sample credentials or accidentally commit environment variables.
- Pay special attention to any code that uses two different libraries for the same task—the AI may have mixed a legacy module with a modern one, creating inconsistent security controls.
The goal is not to assume the developer wrote vulnerable code. It is to recognize that the AI does not understand your threat model. It has no idea which fields are sensitive, which users are privileged, or which endpoints are externally visible. That context is yours alone.
Using Manual Review to Complement Automated Security Scans
Many teams believe that SAST tools, DAST systems, and software composition analysis will catch all AI-generated vulnerabilities. They will not. In this case study, the project’s static analyzer flagged nothing because the vulnerable pattern was hidden behind a custom XML wrapper and a dynamically built query string that the tool could not fully trace. The deserialization issue only became apparent when the reviewer manually inspected the type resolution logic. That is why a human, with a working knowledge of OWASP, is still the most valuable security control in the pipeline.
At the same time, reviewers should use automation to their advantage. Run the automated scanners on every AI-generated PR, but treat their results as a starting point. Then, manually examine the diff for the OWASP risk categories that scanners miss. For example, a scanner can tell you that a library version is outdated, but it cannot tell you that the AI used that library to deserialize untrusted data. A human reviewer can connect those dots.
Conclusion
AI code generators introduce new OWASP risks because they put speed above security and pattern-matching above context. The pull request in this case study looked like a routine feature addition, but it contained five distinct vulnerabilities—any one of which could have led to a breach. A systematic manual review, grounded in the OWASP Top 10 and tailored to the unique properties of AI-generated code, is essential. Developers and reviewers who treat every AI-assisted diff as unverified and security-sensitive will catch these issues, while those who assume the AI knows better will learn the hard way.
