JWTs (JSON Web Tokens) are widely used because they’re compact, stateless, and easy to pass between services. But that convenience can hide dangerous assumptions. Many JWT implementations are insecure, not because the spec is broken, but because default behaviors, developer shortcuts, and subtle mistakes leave critical checks undone. Here’s a clear look at where things go wrong and practical steps to make validation robust.
The Critical Flaw: Algorithm Confusion
The most common and dangerous JWT vulnerability arises from trusting the token’s header alg value during verification. A JSON Web Token has three parts—Header, Payload, and Signature. The header declares the algorithm used to sign the token (for example, HS256 or RS256). If a server blindly accepts the alg value from the header and uses it to choose verification logic, an attacker can craft tokens that bypass signature checks or cause the server to use the wrong key.
1. Allowing the “None” Algorithm
JSON Web Tokens (JWTs) can be powerful, but a dangerous default or weak configuration can let attackers bypass authentication entirely. Here’s a clear explanation of the “alg: none” attack, why it works, and how to defend against it.
- What the attack is? JWTs consist of three parts: header, payload, and signature. – The header includes an “alg” field that says which algorithm was used to sign the token (for example HS256 or RS256). – Some JWT libraries will treat alg: “none” as meaning “no signature required.” If the server accepts that, verification skips signature checks.
- How the exploit works
- An attacker obtains a valid token (e.g., from a stolen token, a leaked token, or a test token).
- They modify the header so that “alg”: “none”.
- They remove the signature part (or replace it with an empty string).
- They optionally modify the payload (for example, change the user id or role).
- They send the modified token to the server. If the server’s JWT validation accepts alg: none, it will skip checking the signature and accept the token as valid.
2. Algorithm Switching Attack (HS256 vs. RS256)
An intricate assault is feasible when the validation does not stringently enforce the prescribed signing algorithm.
The Distinction:
- RS256 (RSA Signature with SHA-256) is an asymmetric algorithm, utilizing a private key for signing and a public key for verification, with the latter being safe to disseminate.
- HS256 (HMAC using SHA-256) is a symmetric algorithm, employing a solitary, mutual secret key for both signing and verification.
The Assault: In the event that your server is configured to utilize RS256 (asymmetric) for signing, it anticipates verifying tokens using the public key. A malicious agent can alter the token’s header from alg: RS256 to alg: HS256.
The Insecurity: A server vulnerable to this attack will now endeavor to verify the signature using the HS256 (symmetric) algorithm, frequently and erroneously utilizing the publicly accessible RS256 public key as the HS256 shared secret key. The malicious agent, having knowledge of the public key, can now sign the token with a self-generated HS256 signature, and the server will validate it as authentic. The public key, initially used for verification, is now being utilized as the secret key for verification.
Key Security Best Practices
To harden your JWT validation, always implement the following:
- Never trust the token’s alg header. Configure your verifier with a fixed, allowed set of algorithms (preferably a single choice such as RS256). If a token’s alg isn’t on that list, reject it.
- Explicitly disallow alg: “none”. Confirm your library or implementation rejects unsigned tokens rather than relying on defaults.
- Validate every expected claim. Always check issuer (iss), audience (aud), expiration (exp), not-before (nbf), issued-at (iat) and any application-specific claims. Treat exp as critical—deny expired tokens and consider short lifetimes to limit misuse.
- Use strong keys and protect them. For HS256, use a long, high-entropy secret and store it like any other confidential credential. For RS256, keep the private key private and use the public key only for verification.
- Prefer asymmetric signing (RS256) for services that need to delegate verification or rotate keys safely; use symmetric (HS256) only when you can securely share and manage the secret.
- Enforce token revocation and rotation policies. Combine short-lived tokens with refresh tokens and a revocation list or token versioning to handle compromised credentials.
