Blog · ← All posts
The 10 Most Common Security Mistakes in AI-Generated Code
Published: November 6, 2026 · 8 min read
The short answer — and the method, stated plainly
These ten mistakes are the security defects AI-generated code ships again and again: hardcoded secrets, string-built SQL, missing authorization checks, JWT verification flaws, unsafe deserialization, template injection, unescaped model output, path-traversal writes, prompt-injection sinks in LLM features, and unvetted dependencies. The method matters, so here it is: this list is coverage-derived, not frequency-ranked. Each entry exists because Vibe-Code Audit ships a detector for the pattern — 62 detectors in all — built from the failure shapes our audits and the public record of AI-code incidents keep surfacing. Where we publish counted data, we say so and show the count (our 30-codebase study counted quality defects, e.g. swallowed errors in 29 of 30). This security list makes no frequency claim it cannot back; it claims something more useful — every item here is mechanically checkable in your repo, today, most of them on the free tier.
1. Hardcoded secrets
The assistant needs an API key to make the demo work, so the key goes in the source — or in a "temporary" config, a test fixture, a build artifact. Secrets in generated code are the highest-certainty finding in any audit: the 32-pattern secret scan (15 patterns free) matches keys, tokens, and private keys by shape, and the fix is a rotation, not just a delete — the secret has been in git history since the commit. Pro reports ship rotation runbooks for exactly this reason.
2. String-built SQL queries
Concatenating user input into a query is the most-taught, most-repeated injection mistake in the training data, and assistants reproduce it faithfully — especially in quick internal tools that later become production. Core detectors flag query construction by concatenation; the fix is parameterized queries everywhere, including the "it's just an admin page" routes.
3. Missing authorization checks
The route checks that someone is logged in and never checks that they may touch this record — or decides authorization from a header in one layer and a URL in another, so the two disagree (the header-vs-URL auth dispatch family). Generated CRUD is especially prone: the assistant implements the happy path for the owner and forgets the second user exists.
4. JWT verification flaws
Accepting the token's own algorithm claim, verifying against the wrong key, or skipping signature checks "temporarily" — JWT key confusion is an Advanced Patterns family because assistants write verification code that looks correct and validates forged tokens. Auth code is where "looks right" and "is right" diverge most dangerously.
5. Unsafe deserialization
Native deserializers fed with untrusted bytes — session data, queue messages, uploaded files — become remote code execution with extra steps. Assistants reach for the convenient loader (the pickle, the unserialize, the YAML full-load) because the training data does. The detector family is deserialization gadgets; the fix is a safe format or a safe loader, never a filter.
6. Template injection (SSTI)
User input rendered through a template engine — in emails, PDFs, error pages, "customizable" anything — hands the attacker the server's rendering context. Advanced SSTI detection looks past the obvious test strings to the engine-specific escapes assistants leave unguarded.
7. Unescaped model output
The LLM-era XSS: the app asks a model for content and renders the answer as HTML, stores it as markup, or — worst — executes it. Insecure LLM output handling is its own detector family because the trust mistake is new: teams sanitize user input reflexively and model output never, as if the model were a colleague instead of an untrusted source that can be prompt-injected by the content it reads.
8. Path-traversal file writes
Upload handlers and export features that build file paths from user-shaped names write outside the intended directory — overwriting config, planting web-accessible files. Path-traversal file writes are a named family; the fix is canonicalization plus an allowlist of destinations, applied at the write, not the form.
9. Prompt-injection sinks
Anywhere user text flows into a prompt that drives tools or privileged actions, the user is programming your agent. LLM prompt-injection sinks, RAG poisoning, and tool-call injection are three Advanced Patterns families covering the shapes: direct text, retrieved documents, and attacker-shaped tool arguments. AI features are now the fastest-growing attack surface in generated apps, because assistants wire them exactly as the demo requires.
10. Unvetted dependencies
The assistant suggests a package; the package is a typosquat, an abandoned project with a known CVE, or — the SlopSquat pattern — a plausible name that doesn't exist until an attacker registers it. SlopSquat Shield verifies dependencies live against npm and PyPI, because a generated import list is a supply-chain decision nobody reviewed.
Frequently asked questions
What is the most common security mistake in AI-generated code?
By certainty of harm, hardcoded secrets: they are mechanically present or absent, they are in git history from the first commit, and they convert any repo leak into account compromise. This list is coverage-derived from our detector library rather than frequency-ranked — each mistake is here because a shipped detector exists for the pattern.
How was this list made?
Each entry maps to a detector family in Vibe-Code Audit's library (62 detectors: 11 core + 51 advanced, plus the secret scanner). The families were built from the failure shapes our audits and public AI-code incident reports keep surfacing. Where we publish counted studies, the counts are shown — this list claims checkability, not a frequency ranking.
Can these mistakes be detected automatically?
Yes — that is the point of mapping each to a detector. The free tier runs the 11 core detectors and the 15-pattern secret scan, which cover several entries here; the full 62 detectors and 32-pattern scan are the Pro path.
Why do AI assistants keep making the same security mistakes?
They reproduce the average of their training data — code written under deadline, much of it never security-reviewed — and they optimize for making the requested feature run. The insecure version is usually the most common version, so it is the most likely generation.
What should I check first in my AI-generated app?
Secrets, because rotation has a clock on it; then the authorization checks on every route that touches another user's data; then any place model output is rendered or user text reaches a tool-calling prompt.