Five JWT mistakes that break production

FreePanda Team

JSON Web Tokens are simple enough to implement in an afternoon and subtle enough to get wrong for years. These are the failures that actually show up in incident reviews.

1. Trusting the alg header

The token tells you how it was signed. If your verification code reads that field and acts on it, an attacker can set it to none, drop the signature, and walk in. Pin the expected algorithm server-side and reject anything else.

2. No expiry

A token without exp is a permanent credential. If it leaks, your only remedy is rotating the signing secret and invalidating everyone. Short lifetimes plus refresh tokens cost a little complexity and save the incident.

3. Skipping aud and iss

If two services share a signing secret, a token minted for service A is valid at service B unless you check aud. Validate audience and issuer, not just the signature.

4. Putting secrets in the payload

The payload is Base64, not encryption. Anyone holding the token can read every claim. Paste one into a decoder and you will see the whole thing in plain text.

5. Ignoring clock skew

Servers drift. A token issued a second in the future fails nbf validation on a machine whose clock lags. Allow a small tolerance โ€” thirty to sixty seconds is typical.