The Authentication Code That Looks Fine but Is Not
When you ask an AI coding assistant to wire up JWT authentication, it produces code that compiles instantly, returns a token on login, and verifies it on protected routes. Run the happy path and everything works. The session appears secure. The code looks like every tutorial you have ever read.
That is precisely the problem. Tutorials skip the dangerous edge cases so the example stays short. AI is trained on tutorials. The result is authentication code that works for normal users and is trivially broken by anyone who knows where to look.
JWT vulnerabilities are not exotic. They are structural, they ship quietly, and they are among the most common findings in AI-generated code. If your app uses JSON Web Tokens for session management and an AI helped write it, this article covers what to look for, why each flaw is dangerous, and how to fix all of it before you deploy.
What JWT Is and Where AI Gets It Wrong
A JSON Web Token is three Base64URL-encoded sections joined by dots: a header that names the algorithm, a payload that holds claims, and a signature that proves the header and payload have not been tampered with since the server issued the token. Verification means decoding all three, recomputing the expected signature, and rejecting the token if anything differs.
That verification step is where AI-generated code consistently falls short, not because the model is confused about JWT in the abstract, but because the training examples that dominate its knowledge base are optimized for readability, not for every edge case an attacker might probe.
Six JWT Mistakes AI-Generated Code Ships With
#
1. Weak or Hardcoded Secrets
The most common finding, by a wide margin. AI generates a working secret, but that secret is either hardcoded in the source file or so short that it can be brute-forced in minutes.
// ❌ AI-generated: hardcoded, guessable secret
const token = jwt.sign({ userId: user.id }, 'secret', { expiresIn: '7d' })
If this secret is ever committed to version control — and it will be, because it is sitting right there in the source — anyone with read access to the repository can forge tokens for any user ID they choose, including the admin. The same applies when the secret is too short: HS256 with a 6-character secret can be cracked offline in seconds using a GPU.
**Fix:**
// ✅ Load from environment; enforce length at startup
const JWT_SECRET = process.env.JWT_SECRET
if (!JWT_SECRET || JWT_SECRET.length < 32) {
throw new Error('JWT_SECRET must be set and at least 32 characters')
}
const token = jwt.sign({ userId: user.id }, JWT_SECRET, { expiresIn: '15m' })
Use a randomly generated secret of at least 256 bits. Rotate it if it is ever exposed.
#
2. Missing Token Verification (or Verification That Always Passes)
AI-generated middleware sometimes skips the verify step entirely, or wraps it in a try/catch that continues on failure.
// ❌ Decode without verify — accepts any payload, including forged ones
const decoded = jwt.decode(req.headers.authorization.split(' ')[1])
req.user = decoded
next()
// ❌ Also dangerous: silently continuing when verification throws
try {
const decoded = jwt.verify(token, JWT_SECRET)
req.user = decoded
} catch {
next() // Attacker sends a forged token; middleware lets them through anyway
}
`jwt.decode` does not check the signature. It reads the payload from any token, valid or forged. The second pattern is subtler but equally dangerous: the catch block calls `next()` unconditionally, so a verification failure grants the same access as a successful verification.
**Fix:**
// ✅ Verify and reject on failure
try {
const decoded = jwt.verify(token, JWT_SECRET, { algorithms: ['HS256'] })
req.user = decoded
next()
} catch {
res.status(401).json({ error: 'Invalid or expired token' })
}
Always use `verify`, never `decode`, on the critical path. Always return a 401 on any exception.
#
3. The `alg: none` Vulnerability
This one dates back to 2015 and is still being generated by AI in 2026. The JWT specification allows an algorithm value of `none`, which means "no signature required." Libraries that do not explicitly reject this will accept a token with a stripped signature as valid.
// ❌ No algorithm whitelist — accepts alg:none tokens
const decoded = jwt.verify(token, JWT_SECRET)
An attacker takes any token, decodes the header, sets `"alg": "none"`, removes the signature, re-encodes, and sends it. Libraries without an allowlist accept it.
**Fix:**
// ✅ Explicit algorithm allowlist
const decoded = jwt.verify(token, JWT_SECRET, { algorithms: ['HS256'] })
Pass the `algorithms` option every single time. Never allow the token itself to dictate which algorithm is used.
#
4. Algorithm Confusion (RS256 → HS256 Swap)
If your server issues RS256 tokens (signed with a private key, verified with a public key) and an attacker knows your public key, they can forge HS256 tokens signed with that same public key — provided your library blindly trusts the `alg` header.
// ❌ Using the public key for RS256 but not enforcing the algorithm
const decoded = jwt.verify(token, publicKey)
// Attacker sends an HS256 token signed with your public key — passes!
The attack works because the public key is, by definition, public. The library sees a valid HS256 signature (because the "secret" it was signed with is the public key) and accepts the token.
**Fix:**
// ✅ Lock to the correct algorithm class
const decoded = jwt.verify(token, publicKey, { algorithms: ['RS256'] })
Pinning the algorithm closes the confusion attack completely. The hardcoded `algorithms` array is not optional.
#
5. Tokens That Never Expire
AI-generated code frequently omits expiration entirely, or sets it to an unreasonably long window.
// ❌ No expiration — token valid forever
const token = jwt.sign({ userId: user.id }, JWT_SECRET)
// ❌ Seven-day expiration — stolen token stays valid all week
const token = jwt.sign({ userId: user.id }, JWT_SECRET, { expiresIn: '7d' })
A stolen token that never expires gives an attacker indefinite access. There is no mechanism to revoke it without rotating the entire secret.
**Fix:**
Use short-lived access tokens and refresh tokens:
// ✅ Short-lived access token, longer-lived refresh token
const accessToken = jwt.sign({ userId: user.id }, JWT_SECRET, { expiresIn: '15m' })
const refreshToken = jwt.sign({ userId: user.id }, REFRESH_SECRET, { expiresIn: '7d' })
// Store refresh token hash in database so you can revoke it
await db.upsertRefreshToken(user.id, hash(refreshToken))
Short access token TTLs cap the window an attacker can use a stolen token. Refresh tokens, stored server-side, can be revoked individually.
#
6. Sensitive Data in the Payload
AI-generated code regularly puts private information directly in the JWT payload, unaware that the payload is trivially decoded by anyone who holds the token.
// ❌ Password hash and email in the token — client can read this
const token = jwt.sign(
{ userId: user.id, email: user.email, passwordHash: user.password },
JWT_SECRET
)
The payload of a JWT is Base64URL-encoded, not encrypted. Any holder of the token — including the client, any proxy, and any browser extension — can decode and read every field. Sensitive data in the payload is sensitive data exposed to the client.
**Fix:**
// ✅ Only put what the server needs to identify the request
const token = jwt.sign({ userId: user.id, role: user.role }, JWT_SECRET, {
expiresIn: '15m',
})
If you need the payload encrypted, use JWE (JSON Web Encryption) — a different specification from JWS (what most people mean by JWT). For most applications, simply omitting sensitive fields is enough.
What a Secure JWT Implementation Looks Like
Below is a minimal, secure Node.js JWT setup covering all six issues above.
import jwt from 'jsonwebtoken'
import crypto from 'crypto'
const JWT_SECRET = process.env.JWT_SECRET
const REFRESH_SECRET = process.env.REFRESH_SECRET
// Enforce key strength at startup
if (!JWT_SECRET || JWT_SECRET.length < 32) throw new Error('JWT_SECRET too short')
if (!REFRESH_SECRET || REFRESH_SECRET.length < 32) throw new Error('REFRESH_SECRET too short')
export function issueTokens(userId, role) {
const accessToken = jwt.sign(
{ userId, role }, // minimal claims only
JWT_SECRET,
{ expiresIn: '15m', algorithm: 'HS256' }
)
const refreshToken = jwt.sign(
{ userId },
REFRESH_SECRET,
{ expiresIn: '7d', algorithm: 'HS256' }
)
return { accessToken, refreshToken }
}
export function verifyAccessToken(token) {
// algorithm pinned; decode never used here
return jwt.verify(token, JWT_SECRET, { algorithms: ['HS256'] })
}
// Express middleware
export function requireAuth(req, res, next) {
const header = req.headers.authorization
if (!header?.startsWith('Bearer ')) return res.status(401).json({ error: 'Unauthorized' })
try {
req.user = verifyAccessToken(header.slice(7))
next()
} catch {
res.status(401).json({ error: 'Invalid or expired token' })
}
}
Key properties: secrets come from environment variables with a length check at startup, the algorithm is hardcoded on both sign and verify, the payload contains only the minimum required claims, access tokens expire in 15 minutes, and any verification failure returns a 401 rather than passing through.
How to Test JWT Security Before You Deploy
Static code review catches the obvious mistakes, but some JWT flaws — particularly middleware bypass — only appear at runtime. Add these tests to your pre-deployment workflow:
1. **Strip the signature.** Take a valid token, set `alg` to `none` in the header, remove the signature segment, and send it. A correctly configured server returns 401. If it returns 200, your library is not enforcing the algorithm.
2. **Swap RS256 → HS256.** If your server uses asymmetric keys, sign an HS256 token with the public key and submit it. Correct configuration returns 401.
3. **Modify the payload.** Decode a valid token, change `userId` or `role`, re-encode without touching the signature. Any change to the payload without re-signing should return 401.
4. **Try an expired token.** Manually set `exp` in the past and confirm the server rejects it.
5. **Probe unauthenticated.** Request every protected route with no token, an empty Authorization header, and a garbage token. All should return 401, not 200 or 500.
These tests are fast and can be automated with a script or a tool like Postman collections. Run them against every environment before promoting code.
How DeployReady Flags JWT Vulnerabilities
DeployReady runs static analysis against your codebase and probes your running app, then maps findings to OWASP and CWE before rolling everything into a 0–100 production-readiness score.
On the static side, it scans for hardcoded JWT secrets, calls to `jwt.decode` on the auth critical path, missing `algorithms` options, and missing `expiresIn` on sign calls. On the dynamic side, it probes protected routes with no token, a stripped-signature token, and a modified payload.
npx deployready@latest analyze ./my-app
✦ Parsing codebase...
✦ Running static analysis...
✦ Probing localhost:3000...
🔴 CRITICAL: Hardcoded JWT secret in src/auth.js
🔴 CRITICAL: jwt.decode() used instead of jwt.verify() in middleware
🔴 CRITICAL: No algorithm pinned — alg:none token accepted by /api/profile
🟡 WARNING: Access token expiration set to 30 days — recommend ≤ 15 minutes
🟡 WARNING: User email in JWT payload — client-readable
Production Readiness Score: 29 / 100
Fix the criticals and re-run. The score updates, and the specific findings give you a precise list of what to change.
The Bottom Line
AI-generated JWT authentication produces code that works and ships vulnerability. The six mistakes covered here — weak secrets, skipped verification, `alg: none`, algorithm confusion, infinite expiry, and leaking sensitive claims — appear routinely in vibe-coded auth flows, and none of them surface in a happy-path test. Catch them with static analysis, dynamic runtime probing, and an explicit security review of every authentication middleware before you deploy.
npx deployready@latest analyze .
Your authentication is only as strong as the token verification it depends on.
Resources
---
**Not sure if your AI-generated auth is secure?** [Scan it with DeployReady](https://www.npmjs.com/package/deployready) or [book a security check](https://www.belsoftsolutions.com/meeting).