AI-Generated Code Security Vulnerabilities Checklist
Audit AI-generated code for security before deployment. This practical checklist covers injection, authorization gaps, hardcoded secrets, and dependency vulnerabilities--with a printable self-assessment table.
- 45 percent of AI-generated code ships with security flaws, according to Veracode 2025 research.
- Missing authorization checks, hardcoded secrets, and injection vulnerabilities are the top three vulnerability types in AI code.
- Use a self-assessment checklist on every AI PR before merge; run manual review on high-risk paths like billing and authentication.
- Layer automated scanning (SAST and SCA) to catch known vulnerabilities and dependency issues without slowing down your team.
AI code isn't automatically less secure than handwritten code, but it fails in predictable ways. Missing authorization checks, hardcoded secrets, and injection vulnerabilities slip through because the model trained on open-source code, not your threat model. Between 40 and 62 percent of AI code ships with flaws. You need a checklist to catch them before deployment.
The Scope: How Vulnerable Is AI-Generated Code, Really?
Research from 2025 shows the scope clearly. Veracode tested AI-generated code and found 45% shipped with security flaws. Endor Labs independently measured 40%+ with vulnerabilities. The Cloud Security Alliance ran a broader audit across public GitHub repositories and found 62% of AI-generated code had design or security issues.
These numbers don't mean AI is uniquely bad. They mean AI generates working code fast, and speed creates risk: missing boundary checks, default-allow logic, forgotten input validation. The model has no context for your access control scheme. It doesn't know which data is sensitive in your domain.
Why this matters to you now: if you're shipping AI-generated code to production, you're betting on luck. A developer using Cursor or ChatGPT or Claude Code can ship a payload-parsing endpoint without input checks, a billing feature without tenant isolation, or a data export without ownership verification. None of those are exotic attacks; they're fast mistakes. The checklist is how you stop them.
Five Vulnerability Categories AI Generates Most Often
Skip the exotic OWASP taxonomy. AI makes the same five mistakes repeatedly:
Injection vulnerabilities (SQL, command, NoSQL). The model sees billions of examples of queries built with user input. It knows the syntax. It does not always know when to parameterize. Veracode tested prompt-to-code on simple SQL injection prevention: 80% passed in the test, but that's the floor, not the ceiling. When the prompt is vague ("let users filter results"), the model builds unsanitized queries.
Authorization and tenant boundary gaps. The model sees endpoint code. It does not see your role matrix. Missing checks for "user.id == row.owner_id" or "if (req.user.role !== ADMIN) return 401" are the most common finding in AI code reviews across published research. The code runs; it just runs for the wrong people.
Hardcoded secrets and credentials. The model was trained on public GitHub. Public GitHub is full of accidentally-committed API keys, database passwords, and private tokens. It hallucinates them into new code. It embeds them in config defaults.
Insecure or hallucinated dependencies. When a prompt says "validate email" the model sometimes invents a package name that doesn't exist, or suggests a real package with a typo (typosquatting). Or it recommends an old version with known CVEs because that's what appeared most in training data.
Flawed logic and missing guardrails. Off-by-one errors, missing bounds checks, race conditions in concurrent code, and "happy path" code that assumes everything works. Not unique to AI--junior developers do this too--but the model does it faster and at scale.
Your AI Code Self-Assessment: Seven Quick Checks
Run this checklist on every AI-generated feature before it merges. Print it. Tape it to your monitor during code review.
| Vulnerability Type | What to Look For | Priority | Reviewed? |
|---|---|---|---|
| Injection (SQL, command, NoSQL) | Are all user inputs parameterized? No string concatenation into queries or system calls. | Critical | |
| Authorization & tenant boundaries | Does the code check user.id or tenant before returning data? Look for missing WHERE owner_id = ? or role checks. | Critical | |
| Hardcoded secrets | Search the diff for API keys, tokens, passwords, database URLs. Check config files and comments. | Critical | |
| Input validation | Does the code validate type, length, and format? No assumption that 'email' is a string or under 255 chars. | High | |
| Error handling | Are exceptions caught and logged without exposing internals? No stack traces in API responses. | High | |
| Dependency security | Are new imports pinned to versions? No latest. Is the typo risk checked (npm typosquatting)? | High | |
| Logic correctness | Do loops terminate? Are edge cases handled (empty lists, null, divide by zero)? | Medium |
If you check "no" on any Critical item, don't merge. High items should have a plan to fix before launch. Medium items need a comment and a ticket.
This checklist assumes you're reviewing code, not writing it. You're the guardrail. Treat AI output the way you'd review code from a competent but unfamiliar contractor: verify assumptions, don't assume benign intent.
How to Audit: The Workflow That Caught 90% of Issues
Threat modeling first, tooling second. Here's the sequence:
Identify sensitive paths. Which user interactions touch billing, authentication, data export, or admin functions? List those endpoints first. These are your high-risk surface.
Read the code manually. Open the Git diff for each sensitive path. Veracode and Endor Labs research shows that human code review catches the most obvious gaps: missing role checks, tenant isolation skips, unvalidated input. You're not auditing every line. You're checking the ones that matter.
Verify the data flow. Trace user input from the request to the database and back. If it touches data, does it check ownership? If it executes a command, is the input escaped? If it returns a response, is sensitive data filtered?
Automate what you can. Static analysis tools (SAST, the category that includes vendors like SonarQube and others) scan for known patterns: SQL injection syntax, hardcoded credentials, dependency vulnerabilities (SCA). These tools are not magic. They catch the obvious stuff--unmissable things--and give you a baseline. Configure them to gate PRs: if they find a critical issue, the merge fails.
Why this order: humans are expensive at scale but catch things machines miss (business logic, tenant boundaries). Machines are cheap and catch things humans miss (known CVE versions, syntax patterns). The one-two punch is faster than either alone.
Pre-Merge Checklist: What to Verify Before Every AI PR
Before code touches production, your team should use this pre-launch checklist covering security, compliance, performance, and deployment readiness as your baseline. Then add these AI-specific checks:
Role and permission checks: If the feature grants access (read, write, delete), does the code check if (req.user.role === ADMIN)? Or for multi-tenant systems, if (req.user.tenantId === row.tenantId)? The model often assumes roles exist and skips the check.
Data flow and ownership: For any query that returns data, trace who can see it. A "get user profile" endpoint should return WHERE id = req.user.id. A "list transactions" should return WHERE tenantId = req.user.tenantId. Missing those clauses means data leakage.
Secrets and sensitive data in config: Scan the diff for API keys, database passwords, private tokens. Use git diff and search for patterns: password=, api_key, secret, token. If found, reject the PR and require the developer to use a secrets manager. Review our GDPR and compliance checklist for data handling requirements before launch.
Dependency changes: New imports mean new risk. Check the lockfile diff: are versions pinned or floating? Is there a typo in the package name (typosquatting risk)? Veracode research shows dependency vulnerabilities are a top issue in AI code because the model suggests packages but not always the right versions.
Prompt injection vectors (if applicable): If the app uses AI agents or LLM calls, audit the prompt assembly. Can user input contaminate the system prompt? If a user can control the instruction to Claude or ChatGPT, they can break the intended behavior.
Automating Detection Without Slowing Down
You can't review every AI PR by hand--it's too slow. But you can automate layers:
Static Application Security Testing (SAST): Scans code for patterns: SQL injection syntax, hardcoded strings that look like secrets, missing input validation. It's imperfect--false positives are common--but it catches the obvious.
Software Composition Analysis (SCA): Scans dependencies (gems, packages, imports) against known-vulnerability databases. If you're pulling in an old version of a library with a CVE, SCA flags it. This is table-stakes for most teams.
Pre-commit hooks: Before a developer even pushes, run local checks: "are there obvious secrets in the diff?" These are fast, run on the dev machine, and catch mistakes before they hit the remote.
CI/CD gates: When code lands on a branch, run SAST and SCA automatically. If they find a Critical issue, the PR cannot merge. This is your hard stop.
GitHub or GitLab native review rules: Configure branch protection: "require SAST check to pass" or "require one security team approval." This makes security visible in the merge workflow, not a separate tool.
The goal is not perfection. It's to catch the low-hanging fruit (known CVEs, obvious secrets, syntax patterns) automatically, so humans focus on the logic-level checks (authorization, data flow, business rules) that machines struggle with.
Fixing Vulnerabilities: What to Test After Remediation
Finding a vulnerability is not the end. The fix can introduce a new one.
When a developer patches an XSS hole (say, adding input escaping), they need to verify:
The original flaw is gone. Test the input that triggered it. Confirm it no longer executes.
Related features still work. Escaping input for one context (HTML) but not another (JSON API) creates a false sense of security. If you escape user input for web display, do you also escape it for CSV export?
No new attacks were introduced. Over-escaping can create new issues: double-encoding, broken legitimate input, or logic bypass. A developer patches an authorization gap by adding if (req.user.role === ADMIN) but forgets the non-admin path, so the feature silently fails for normal users.
Regression tests exist. Before the fix is considered done, write a test that would catch this bug if it came back. That test stays in the suite forever.
Who signs off: not just the developer, not just CI. Have a second pair of eyes--security-trained if possible, but a senior dev works too--verify the fix. This is the moment when the model's speed meets human judgment.
The reason this matters: Veracode and Endor Labs research shows that AI-generated mitigations often miss edge cases. The model can write the escape function. It struggles with "when do I escape, and when do I validate instead?"
Deploying AI-Generated Apps Safely to Production
Once you've audited and fixed vulnerabilities locally, the final step is infrastructure. When you're ready to deploy your AI-generated app to production, you need hosting built for speed without sacrificing security. Ship is flat-fee and predictable, includes EU compliance by default, and has zero lock-in: no extra audit, no vendor creep. Start free.
Frequently Asked Questions
Is your AI-generated code really safe?
No, not by default. Between 40 and 62 percent of AI code contains flaws. But "not safe" is not the same as "unusable." You apply the same security discipline you would to a junior developer's code: review it, test it, audit the risky paths, and gate it before production. Most vulnerabilities in AI code are preventable with process, not product.
Can we trust AI-generated code?
You can trust it the way you'd trust any fast-written code: verify before deploy. Copilot and Claude write syntax correctly. They miss business logic like "only show me my data," not "only show me your data." Set your trust policy accordingly. If it's a billing endpoint, review it carefully. If it's boilerplate logging, less scrutiny needed.
Is AI-generated code legal?
Legal questions about generated code (copyright, license compliance, indemnification) are outside this scope, but the short answer is: yes, you can use it if you comply with the open-source licenses of packages it uses. Use an SCA tool to audit dependencies for license requirements. The model does not know license law; you need to.
Can AI code really be detected?
Yes and no. You can use AI detection tools (they look for statistical markers), but they are imperfect. More useful: your code review process will reveal AI code quickly--it has a certain style--and that's where the security review starts. Detection is less important than knowing you're reviewing AI code with that awareness.
How do you tell if code was made by AI?
The coding style is distinctive: repetitive variable names (user, data, result, response), happy-path logic with minimal error handling, and gaps in authorization. If you're wondering, ask the developer. Assume any code your team ships could be AI-assisted, and review accordingly.
The Bottom Line
AI-generated code is fast and often functional. It is not automatically secure. The vulnerabilities--missing authorization, hardcoded secrets, injection flaws--are preventable with the right checklist and process.
Start with the self-assessment table: run it on every AI-generated feature before it merges. Use threat modeling to identify your high-risk paths, and audit those manually. Layer in automated scanning (SAST and SCA) to catch the obvious mistakes. Fix vulnerabilities with rigor, not haste.
That's the foundation. Next, your production environment matters: infrastructure that is predictable, compliant, and does not re-introduce risk through configuration drift or vendor lock-in.