Common JWT mistakes

The bugs behind most JWT security incidents, and how to avoid them.

JWTs are simple, which makes it easy to use them wrongly. These are the problems seen most often.

1. Trusting the token without verifying the signature

Decoding is not verifying. A server must check the signature with the correct key on every request, and must not accept a token just because its payload looks right.

2. Accepting the algorithm from the token

Some old libraries honored "alg": "none" (no signature) or let attackers switch from RS256 to HS256 and sign with the public key. Always configure the expected algorithm on the server and reject anything else.

3. Secrets in the payload

The payload is readable by anyone. Keep identifiers and permissions in it, not personal or sensitive data.

4. Tokens that never expire

Use short lifetimes for access tokens, often minutes, and a separate refresh mechanism. A stolen long-lived token is valid until it expires.

5. Not checking iss and aud

Validate who issued the token and who it is meant for, or a token meant for one service may be accepted by another.

6. Where to store it in the browser

• localStorage is readable by any script on the page, so a cross-site scripting (XSS) bug can steal the token.
• An HttpOnly cookie cannot be read by scripts, but needs protection against cross-site request forgery (use SameSite and CSRF defenses).

7. Expecting to revoke it

Because validation is stateless, you cannot easily cancel one token before it expires. Keep lifetimes short, or keep a denylist of revoked ids.

CarefulIf you only need a simple session for one website, a normal server-side session cookie is often simpler and safer than a JWT.