SQL injection and XSS in AI-generated code

Vibe coding (any tool) Involved 2-6 hours for a small codebase security critical Last verified Jul 17, 2026

The fix Assume the AI shipped injection holes: Veracode found 45% of AI-generated code samples introduce OWASP Top 10 vulnerabilities. Convert every string-built SQL query to parameterized statements, audit every dangerouslySetInnerHTML and innerHTML, sanitize user HTML with DOMPurify, validate inputs with a schema library, and run SAST (Semgrep, Snyk Code) on every AI diff. Newer models are not safer, so scan everything.

Symptoms

A scanner, pentest, or attacker finds user input concatenated straight into SQL strings
Queries crash the moment someone types an apostrophe
Unescaped user input gets rendered into HTML, which is cross-site scripting (XSS)
User-controlled text is written raw into logs (log injection)
Worst case: data exfiltration through crafted input

Why it happens

Models reproduce the insecure idioms in their training data

String-concatenated SQL and unescaped output saturate the tutorials and forum answers models trained on. The model hands you the most common pattern, which is often the insecure one.

The failure rate is measured, and it is high

Veracode's GenAI Code Security Report tested output from more than 100 LLMs across 80 curated tasks: 45% of AI-generated code samples introduced OWASP Top 10-class vulnerabilities.

XSS and log injection are the weakest areas

Models failed to defend against XSS in 86% of relevant tasks and log injection in 88%. Even on SQL injection, their strongest area, roughly 20% of generated samples chose the insecure pattern.

Newer models are not safer

Veracode found newer and larger models were not more secure than older ones, so this problem does not fix itself with the next model release.

How to fix it

Hunt down string-built SQLGrep the codebase for template literals or f-strings containing SELECT, INSERT, UPDATE, or DELETE with interpolated variables. Convert every hit to parameterized queries, prepared statements, or an ORM query builder. No exceptions for queries you think only internal code can reach.
Audit the HTML injection pointsRely on your framework's auto-escaping, and audit every use of dangerouslySetInnerHTML, innerHTML, and v-html. If you must render user-supplied HTML, sanitize it with a real library such as DOMPurify.
Validate input at the API boundaryUse a schema library (zod, joi, pydantic) so malformed input is rejected before it reaches a query or a template. Validation is not a substitute for parameterization, but it shrinks the attack surface.
Run SAST on every AI-generated diffWire Semgrep, Snyk Code, or Veracode into CI so scans run on every change, not just releases. Human review demonstrably misses these patterns at AI generation speed.
Prompt for the safe pattern, then verify anywayWhen prompting, explicitly require parameterized queries and output encoding. Asking for 'secure code' alone measurably isn't enough, and even the explicit version needs a check of the actual diff.

How to prevent it

Make parameterized queries a stated requirement in every prompt that touches a database
Keep SAST in CI so every AI diff gets scanned, not just releases
Flag raw innerHTML and dangerouslySetInnerHTML with a lint rule, allowing only sanitized exceptions
Schema-validate all input at API boundaries as standard scaffolding
Never assume the next model version writes safer code; Veracode found it doesn't

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

Snykfree tier

Snyk Code catches injection and XSS right in your editor, and Snyk Open Source flags vulnerable and malicious packages. It covers several AI-code failure modes at once and is free for open source.

Try Snyk →

Aikido SecurityFree plan: 2 users, 10 repos

All-in-one appsec (code scanning, dependencies, secret detection, containers) with low-noise output, built for small teams that cannot run five separate tools. One dashboard covers several failure modes.

Try Aikido Security →

Frequently asked questions

How common are security vulnerabilities in AI-generated code?

Veracode's GenAI Code Security Report tested output from more than 100 LLMs across 80 curated tasks and found that 45% of AI-generated code samples introduced OWASP Top 10-class vulnerabilities. Models failed to defend against XSS in 86% of relevant tasks and log injection in 88%. SQL injection was their strongest area, and even there roughly 20% of samples chose the insecure pattern.

Does asking the AI for 'secure code' prevent SQL injection?

Not reliably. Asking for secure code alone measurably isn't enough; you get better results by explicitly requiring parameterized queries and output encoding in the prompt. Even then, verify the diff and run SAST, because models keep reproducing the insecure string-concatenation idioms that saturate their training data.

Will newer AI models stop writing injection vulnerabilities?

No. Veracode found that newer and larger models were not more secure than older ones. Models reproduce the insecure patterns common in their training data, so injection flaws in AI-generated code do not fix themselves with the next model release. Keep scanning every diff.

What tools catch injection flaws in AI-generated code?

Run SAST tools like Semgrep, Snyk Code, or Veracode on every AI-generated diff in CI, and use DOMPurify to sanitize any user-supplied HTML before rendering it. Schema validation libraries such as zod, joi, or pydantic reject malformed input at the API boundary before it reaches queries or templates.

Sources

The Vibe Oops briefing

One email when something ships to production that should not have. New incidents, new error guides, no filler.