JWT Attacks
JSON Web Tokens are widely used for authentication and widely misimplemented. The common attacks are the none algorithm, algorithm confusion between RS256 and HS256, weak signing secrets, and header injection through kid or jwk. Every one comes down to the server trusting the token instead of properly verifying its signature.
How a JWT works
A JWT has three parts: header, payload, signature, separated by dots. The header says which algorithm signs it, the payload holds claims like user ID and role, and the signature proves it was not tampered with. The server should verify that signature on every request. Most JWT attacks exploit weak or missing verification.
The seven attacks
| Attack | The flaw |
|---|---|
| none algorithm | Server accepts an unsigned token |
| Algorithm confusion | RS256 switched to HS256 using the public key as secret |
| Weak secret | HMAC secret is guessable or crackable |
| kid injection | kid header manipulated to point at attacker data |
| jwk injection | Attacker supplies their own signing key in the header |
| Missing expiry check | Old tokens never expire |
| No signature check | Server reads claims without verifying at all |
The none algorithm
Set the header algorithm to none, remove the signature, and if the server accepts it, you can forge any token. Change the role claim to admin and you are admin. Trivial to test, still found in the wild.
Algorithm confusion
An app uses RS256, verifying with a public key. An attacker changes the header to HS256 and signs the token using that public key as the HMAC secret. If the server naively verifies with the same public key, it accepts the forgery. The fix is to pin the expected algorithm, never trust the header's choice.
Weak secrets
HMAC signed tokens are only as strong as the secret. A weak or default secret can be cracked offline from a single captured token, after which the attacker forges any token they like. Same principle as password cracking in Kerberoasting.
How to test JWTs
- Decode the token and read the header and claims
- Try the none algorithm
- Try algorithm confusion if it uses RS256
- Attempt to crack the secret if it uses HS256
- Check whether expiry is enforced
- Tamper with kid and jwk headers
The jwt-editor extension makes this practical, part of the toolkit in the Burp install guide.
The fixes
- Pin the algorithm server side, ignore the header's claim
- Use a long random secret for HMAC
- Always verify the signature, on every endpoint
- Enforce expiry
- Validate kid and reject attacker supplied keys
Practise this
Attack JWTs on deliberately vulnerable APIs. Free labs on Hacklido.
Enroll in API Security
Live instructor led training with hands on labs and a verifiable certificate. Or start free on Hacklido.
Enroll in API Security