Top JWT Security Vulnerabilities and How to Prevent Them

Table of Contents

• The "none" Algorithm Attack
• Algorithm Confusion
• Weak Secrets
• Missing Expiration
• Token Storage
• Security Checklist

The "none" Algorithm Attack

Some early JWT libraries accepted "alg": "none", meaning no signature required. An attacker could forge any token.

Fix: Always explicitly whitelist allowed algorithms:

jwt.verify(token, secret, { algorithms: ["HS256"] });

Algorithm Confusion

If your server uses RS256 (asymmetric), an attacker might send a HS256 token signed with your public key as the HMAC secret — since the public key is, well, public.

Fix: Never auto-detect the algorithm from the token header. Hardcode it server-side.

Weak Secrets

HS256 is only as strong as your secret. Short secrets can be brute-forced offline.

# Generate a strong secret
openssl rand -hex 32

Missing Expiration

A JWT without exp is valid forever. If stolen, there's no way to invalidate it.

Fix: Always set short expiration (15 min for access tokens) and use refresh tokens.

Token Storage

• localStorage: Vulnerable to XSS — any injected script can steal it
• httpOnly Cookie: Not accessible via JS — preferred for web apps
• Memory: Safest, but lost on page refresh

Security Checklist

• Whitelist allowed algorithms (never 'none')
• Use strong, random secrets (256-bit minimum)
• Set short expiration on access tokens
• Validate iss and aud claims
• Store tokens in httpOnly cookies
• Use JWT Decoder to audit tokens in development