JWT Security Pitfalls Explained
A JSON Web Token (JWT) is incredibly popular for stateless authentication. However, developers often confuse the Base64Url encoding of a JWT with actual encryption, leading to severe security vulnerabilities.
1. Decoding is Not Verifying
As demonstrated by our JWT Decoder, anyone can read the Header and Payload of a standard JWT. The payload is merely Base64Url encoded, not encrypted. If you store PII (Personally Identifiable Information) or sensitive data like passwords inside the payload, anyone who intercepts the token can read it in plain text.
2. The none Algorithm Attack
The JWT Header specifies the signing algorithm (e.g., "alg": "HS256"). A classic security misconfiguration occurs when backend servers implicitly trust the alg header provided by the client.
An attacker can change the header to "alg": "none", remove the signature, and send the token. If your server accepts none as a valid algorithm, the attacker can spoof any user identity.
3. Symmetric vs Asymmetric Keys
- HS256 (Symmetric): Uses a single secret key to both sign and verify the token. If this key is leaked, attackers can mint valid tokens.
- RS256 (Asymmetric): Uses a private key to sign and a public key to verify. This is strictly required for OAuth/OIDC providers so consumers can verify the token without knowing the signing key.
4. Token Expiration (exp)
Always set an exp (Expiration) claim. A stateless JWT cannot be easily revoked once issued without maintaining a stateful blacklist on the server, completely defeating the purpose of statelessness. Keep access token lifespans short (15-60 minutes) and use refresh tokens for prolonged sessions.