Often not. In independent testing, AI models introduced a known security flaw in roughly 45% of coding tasks, and failed to defend against cross-site scripting (XSS) in 86% of relevant samples. AI-generated code compiles and runs — but “runs” is not the same as “safe.” The fix isn't to stop using AI; it's to review every change before it ships.
How often is AI-generated code insecure?
The most rigorous public data comes from Veracode's 2025 GenAI Code Security Report, which ran 80 curated coding tasks across more than 100 large language models. The headline finding:
- ~45% of tasks produced insecure code. When a model could choose between a secure and an insecure way to write something, it chose the insecure one about 45% of the time (Veracode, 2025).
- XSS (CWE-80) failed in 86% of relevant samples, and only 12–13% of XSS-context code was secure.
- Broader studies agree: a Stanford study found roughly 80% of AI-generated apps carried at least one exploitable vulnerability, and Georgetown's CSET found 86% of AI-generated code failed to defend against XSS.
Why this matters for vibe coding
The most common vulnerabilities in AI-generated code
- Cross-site scripting (XSS) — unescaped user input rendered into the page.
- Hard-coded secrets — API keys, tokens, and passwords written straight into source.
- Injection flaws — SQL/command injection from unsanitized inputs.
- Broken access control — missing auth checks, overly permissive CORS, exposed endpoints.
- Vulnerable dependencies — packages with known CVEs, sometimes hallucinated ones that don't exist.
Why AI writes insecure code
Models learn from billions of lines of public code — much of which is insecure. They replicate the patterns they've seen without the contextual awareness to tell a safe practice from a dangerous one. The output is fluent and confident, which is exactly what makes it risky: it looks correct, so it's tempting to ship without reading it.
How to ship AI-generated code safely
You don't need to give up the speed. You need a checkpoint between “generated” and “shipped.”
- Review every diff before it applies — read the actual per-file change, not the AI's summary of it.
- Watch the files you didn't expect to change — auth, config, and env are where security regressions hide.
- Keep secrets out of source and scan dependencies for known CVEs.
- Keep a rollback point so a bad change is one click to undo, not a debugging session.
Build with a builder that makes you review every diff first
Try NoCoder FreeThe short version