Guide
JWT vulnerabilities: alg:none and key confusion
A JSON Web Token is just three base64url segments — header, payload, signature — and the whole security model rests on that third segment being verified correctly. When a backend trusts the token to tell it how to verify the token, that model collapses. Two classic flaws come straight out of that mistake.
The header is attacker-controlled
The JWT header declares the signing algorithm in its alg field. The problem is that the header ships inside the token, so the client controls it. If the server reads alg to decide how to verify, an attacker gets a vote in that decision — and that is the root of both attacks below.
alg:none — dropping the signature entirely
The JWT spec includes a none algorithm meaning 'unsigned'. If a library or a permissive configuration honours it during verification, an attacker sets the header to {"alg":"none"}, edits the payload freely (say, "admin": true or a different sub), and leaves the signature segment empty. A server that accepts it treats a forged token as authentic.
The fix is to pin the expected algorithm server-side and reject none outright — never let the token choose. Any token you capture is worth testing for this the moment you have it.
Key confusion: RS256 to HS256
RS256 verifies with a public key; HS256 verifies with a shared secret. If a server calls a verify function that picks the algorithm from the token's header, an attacker switches alg from RS256 to HS256 and signs a forged token using the RSA public key — which is, by definition, public — as the HMAC secret. The server, thinking it is verifying HS256, uses that same public key and the forgery checks out.
This turns a value you are supposed to be able to publish into a signing key. The defence is the same discipline: fix the algorithm on the server, and keep the key material for each algorithm strictly separate.
What else the token gives you
Even without a forge, decode the payload. Tokens routinely over-share — roles, internal user ids, email addresses, tenant identifiers — and a missing or far-future exp claim means a stolen token is useful indefinitely. Weak HS256 secrets are also crackable offline against the token's signature.
ApexDrift's JWT Analyzer decodes a token, flags none and key-confusion exposure, surfaces sensitive and expiry claims, and (on Pro) tests HS256 tokens against weak secrets — so you see what a token is really telling you.