Claude Code Tops Security Flaw Count in New Agentic Coding Study

DryRun Security tasked each coding agent with independently building two complete applications from scratch — no security-specific guidance in the prompts, just realistic product specifications.

App 1: FaMerAgen — a web app for tracking children's allergies and family contacts. Features included user accounts, social login via OAuth, two-factor authentication, and family group management.

App 2: Road Fury — a browser-based racing game with a backend API, high-score system, player authentication, WebSocket-based multiplayer, and save-game functionality.

Both apps were chosen to mirror the kind of work real teams do: authenticated users, sensitive data, real-time features, and business logic that can go wrong in non-obvious ways. Each agent built features through sequential pull requests — the same incremental workflow used on real development teams. Every PR was security-scanned at submission time, and a full codebase scan was run before development began and again after all features were merged. Across 38 scans covering 30 PRs, the study found 143 security issues.

Here's how the final codebase scans compared across both applications:

Web app (FaMerAgen) — final vulnerability count:

• Claude Code: 13 issues (baseline was 9)
• Gemini: 11 issues
• Codex: 8 issues (one fewer than baseline — the only agent that net-improved the codebase)

Game app (Road Fury) — final vulnerability count:

• Claude Code: 8 issues (baseline was 0)
• Gemini: 7 issues
• Codex: 6 issues

Every agent added vulnerabilities relative to the baseline. No agent produced a fully secure application. But Claude's higher final counts stand out precisely because Claude Code is currently the most widely used coding agent in production environments — and the one most teams are staking real workflows on.

Claude's specific issues are worth understanding in detail rather than summarising as "most flaws."

In the web app, Claude introduced a 2FA-disable bypass that neither Codex nor Gemini produced — allowing an authenticated attacker to disable two-factor authentication on another user's account. Claude also carried 13 issues to the final scan compared to Codex's 8.

In the game app, Claude carried two long-lived unresolved findings across the entire project: an insecure direct object reference introduced in PR 2 and an unauthenticated destructive endpoint introduced in PR 1. These were the longest-running unpatched issues of any agent in the study — Claude never went back to fix them as subsequent PRs were added.

PR 3 in the game app — adding player login and a save-game system — was the highest-risk task across all three agents. It introduced the largest cluster of findings: JWT secrets, user enumeration, session management failures, and client-side trust issues. Most of the high-severity findings in Claude's final game scan traced back to design choices made during that single task.

The report identified ten vulnerability classes that appeared consistently across all three agents and both applications. These aren't random bugs — they're structural patterns in how LLMs generate code:

1. Broken access control — Unauthenticated endpoints on destructive and sensitive operations. The most universal finding, appearing across all agents in both applications. Agents built the endpoints, wrote the business logic, and skipped the auth check.

2. Business logic failures — Scores, balances, and game states accepted from the client without server-side validation. The client said "my score is 99,999" and the server wrote it to the database.

3. OAuth implementation failures — Missing CSRF state parameters and insecure account linking in every social login implementation, across all three agents. A missing state parameter is a textbook OAuth attack vector, present in 100% of social login implementations in the study.

4. WebSocket authentication gaps — Every agent built correct REST authentication middleware. Every agent then built WebSocket handlers without applying the same protections. Real-time game features and live data connections were left completely open.

5. Insecure JWT defaults — Hardcoded fallback secrets and weak signing configurations. An attacker who knows the default secret can forge valid session tokens without credentials.

6. Missing brute-force protections — Rate limiting middleware was defined in every codebase. No agent connected it to the application routes. The code existed; the protection did not.

7. Non-revocable refresh tokens — Tokens issued without invalidation mechanisms. Once issued, they cannot be cancelled — even after a password reset or account compromise.

8. Client-side state trust — Game unlock states, achievement flags, and user permissions stored on the client and sent back to the server without verification.

9. Insufficient input validation — User-controlled data flowing into sensitive operations without sanitisation, appearing in multiple agents' implementations.

10. Insecure CORS configuration — Overly permissive cross-origin policies allowing unintended origins to make credentialed requests.

The most revealing pattern in the study is arguably not what agents failed to build — it's what they built correctly but failed to connect.

Rate limiting is the clearest example. Every codebase had rate limiting middleware. The agents knew how to write it. They just never wired it to the routes that needed it. The protection existed in the codebase as an inert module, doing nothing.

WebSocket authentication follows the same logic. Agents built proper REST middleware — correct implementation, correct placement, correct usage. Then they built separate WebSocket upgrade handlers that never invoked the same middleware. The gap wasn't ignorance of authentication; it was a failure to apply a known pattern to a new surface.

This suggests something specific about how LLMs reason about security: they generate components correctly in isolation, but they don't maintain a mental model of the full system as they build. Each feature gets written in context of itself, not in context of the whole application. Security integration — the wiring — is exactly the kind of holistic reasoning that current models miss.

DryRun makes an important point about tooling: the vast majority of vulnerabilities in this study were logic and authorisation flaws, not the kind of issues traditional static analysis catches.

Regex-based SAST tools flag known-bad function calls and dangerous string patterns — SQL string concatenation, unsafe deserialisation, eval() on user input. They do not trace whether authentication middleware is mounted correctly, whether a business logic rule is validated on the server, or whether a JWT secret has a hardcoded fallback.

This is why teams running their existing security tooling on AI-generated code will get false confidence. The code passes the scanner. It looks clean. The vulnerabilities are in the application logic — in what the code does, not what it calls.

DryRun's practical recommendations for teams using Claude Code or any agentic coding tool:

Review security during planning, not only coding. Many of the study's vulnerabilities originated in design decisions the agent faithfully implemented. Asking Claude to design the auth architecture before writing any code — and reviewing that design for security gaps — catches more than post-coding scans.

Treat the ten patterns as a mandatory checklist. Before merging any AI-generated PR, explicitly check for: authentication on all endpoints (REST and WebSocket), server-side validation of business logic, CSRF state in OAuth flows, JWT signing configuration, and rate limiting actually wired to routes.

Scan at PR time, not just at release. The study used PR-time scanning for every submission. Teams relying only on final release scans miss the majority of issues — many of which compound across subsequent PRs as later features build on insecure foundations.

Add security context to your prompts. None of the agents in the study were prompted with security requirements. Including explicit constraints — "all endpoints require authentication", "validate all game state server-side", "never hardcode secrets" — measurably changes output.

Don't trust working software to be secure software. The game ran. The web app worked. None of the applications were obviously broken. The security gaps were invisible to casual review and only surfaced through systematic analysis.