Security research2 min read
What AI coding agents get wrong about security
When five leading coding agents built the same apps, none wrote SQL injection. All of them skipped the security controls the prompt never mentioned.
Key takeaways
- In Tenzai's December 2025 test, five agents built 15 apps with 69 vulnerabilities between them.
- None had exploitable SQL injection or XSS. All five agents introduced SSRF in the same feature.
- None of the apps implemented CSRF protection properly or set the standard security headers, and most had no login rate limiting.
- Agents implement what the prompt asks for. Controls the prompt does not mention are usually missing.
The test
In December 2025, Tenzai asked five coding agents (Cursor, Claude Code, OpenAI Codex, Replit, and Devin) to build the same three web apps each. Their researchers then audited all 15. SecurityWeek's write-up summarises the results.
The headline is a split. On classic, pattern-shaped bugs the agents did well. On controls that depend on context, they did badly.
What the agents got right
Across all 15 apps there was no exploitable SQL injection or cross-site scripting. Parameterised queries and output escaping are among the most heavily documented patterns on the web, and modern frameworks make them the default. Models reproduce them reliably.
What they got wrong
- Authorization. Improper API authorization was the most common issue: endpoints that checked a user was signed in, but not that the record belonged to them.
- Server-side request forgery. All five agents introduced SSRF in a link-preview feature, fetching whatever URL a user supplied, including internal addresses.
- CSRF. None of the 15 apps implemented cross-site request forgery protection properly.
- Security headers. No app set a Content-Security-Policy, X-Frame-Options, HSTS, or X-Content-Type-Options, and CORS was not configured properly.
- Rate limiting. 14 of the 15 apps had no rate limit on login.
Why security is rarely in the prompt
A prompt describes a feature: let users share a link and show a preview. It almost never says: and refuse internal IP ranges, and cap requests per minute, and check the requester owns the record. The agent builds the feature as described and it works, so nothing looks wrong.
Injection is different, because the safe way to write a query is also the normal way. Authorization, SSRF filters, CSRF tokens, and headers are extra work that only exists if someone asks for it. That is the gap to close, either in the prompt or in a test after the fact.
What to add to your prompts and your review
- For every route that takes an ID, state who may access it and ask for an ownership check on the server.
- For any feature that fetches a user-supplied URL, ask for an allow-list and a block on private and link-local addresses.
- Ask for rate limits on login, signup, password reset, and anything that sends email.
- Set security headers once, in middleware or hosting config, rather than per route. The OWASP headers cheat sheet is a good baseline.
- Test the running app as an anonymous visitor and as a second user before every launch.
Where Routelint fits
Routelint tests the most common finding in this study, improper API authorization, by replaying each captured call with no session and as a peer account. It does not test for SSRF, CSRF, or headers. Use the checklist in our pre-launch post for those.
Routelint records the API calls your running app makes, then replays them with no session and as a second account. One scan needs no account.
Sources
- Vibe coding tested: AI agents nail SQLi but fail miserably on security controls — SecurityWeek
- HTTP Security Response Headers Cheat Sheet — OWASP Cheat Sheet Series
- API1:2023 Broken Object Level Authorization — OWASP API Security Top 10
Published November 1, 2026 by the Routelint team.