Auditing AI-Built Authentication: The Same Broken Access Control, Just Faster

I started noticing a pattern while auditing startup auth flows built with AI coding tools: the same broken access control bugs I've been reporting for years, now generated just faster. The code looked clean. It covered signup, login, password reset, JWT tokens, maybe a middleware check. But past the happy path the same four or five failures appeared—bugs I've been triaging in hand‑written apps for years. The only new variable was speed. The generator wrote the vulnerable code in seconds, and whoever prompted it shipped it without a second look.

The Predictable Bug Pattern in AI-Generated Auth

The call usually goes: “Add authentication with roles, email verification, and protected routes.” The AI outputs a plausible flow. Login works. Signup saves to the database. The verification email sends. But after a few targeted tests, the cracks are obvious. An unverified email still receives a session token. A free‑tier account calls admin endpoints because the middleware only checks whether a token exists, not what it contains. A password‑reset token never expires or gets logged to the console. These aren't novel weaknesses. They're the old ones, generated faithfully from training data that never fixed them.

Why AI Speed Makes Old Access Control Flaws More Dangerous

When a developer writes auth from a tutorial, they might pause and consider edge cases. When an LLM produces a complete working module in seconds, the pressure to ship overrides skepticism. The code looks right—it uses bcrypt, sets httpOnly cookies, calls jwt.verify. That surface correctness hides a critical gap: the generator rarely asks, “What happens if the user modifies the role in the request body?” or “Does the token guard actually verify email status?” Speed encourages trust, and trust is the enemy of access‑control testing.

Access Control: The Real Bug Class

These are rarely crypto failures. They're authorization bugs dressed in authentication clothing. The system authenticates the user correctly, then authorizes them for actions they shouldn't take. Here are the sub‑patterns I keep hitting.

Trusting Client-Side State: Admin Role via Request Body

I've seen POST /signup endpoints where the client sends role: "admin" in the body and the backend stores it directly. The AI‑generated code assumed the frontend would never expose that field. A quick intercept with Burp, or simply editing the fetch payload in DevTools, confirmed the missing server‑side override.

// vulnerable AI-generated signup handler
app.post('/signup', async (req, res) => {
  const { email, password, role } = req.body;
  // role can be "admin" — no server-side override
  const user = await User.create({ email, password, role });
  ...
});

Missing Role Verification in JWT Middleware

Protected routes used middleware that only verified a valid JWT. The token payload might contain an isAdmin flag, but if the backend never inspected it, any authenticated user—including one with a self‑signed token—could reach admin endpoints. Verifying the token's signature is not the same as verifying the claims inside it.

Incomplete Email Verification Flows

Variations: the backend issued a full session cookie before the user clicked the verification link. Or the “verified” flag existed on the user object but the login route never checked it when generating a token. In one case, the application sent the verification token back in the signup response body, making the email step optional. Each shortcut leaves a door open for unverified accounts to move through the application as fully trusted users.

Token Confusion and Leaks

Password‑reset tokens sometimes appeared in server logs, remained valid indefinitely, or were simple predictable strings. AI‑generated helpers like generateResetToken() often default to crypto.randomBytes(16).toString('hex'), which is fine cryptographically, but the surrounding code didn't enforce expiration, single‑use, or rate‑limiting. The token was technically secure yet operationally useless—any captured or reused token would still work because the authorization layer considered it valid forever.

The Takeaway for Auditing AI‑Built Authentication

Auditing AI‑built authentication isn't about blaming the tool. It's about recognizing that the same broken access control patterns are now generated faster, and that the checks that actually matter—role enforcement, email verification, token lifecycle, distrusting client input—still require human attention. If you're reviewing an AI‑generated auth module, skip the surface syntax and ask the same hard questions you'd ask any hand‑rolled login system. The bugs haven't changed; they've just become cheaper to produce.