JWT security pitfalls: alg confusion, no revocation, and where tokens leak

A pentester logs in as a normal user, copies the JWT, flips the header from "alg":"RS256" to "alg":"HS256", changes the payload to "role":"admin", and re-signs it using the server’s public RSA key as the HMAC secret. The server reads the header, takes the HMAC branch, verifies with that same public key — and waves it through. No private key was ever needed. The “secret” was published in the JWKS endpoint the whole time.

The token tells you nothing until you verify it

A JWT has three base64url parts: header, payload, signature. The header carries alg (which algorithm), the payload carries claims (sub, role, exp), and the signature is what makes the first two unforgeable — if you verify it correctly. The dangerous mental model is treating the decoded payload as facts. It is not. Anyone can base64-decode and rewrite the payload in a browser console. The only thing standing between an attacker and "role":"admin" is signature verification, and every pitfall below is a way that verification quietly does nothing.

RFC 8725 (JSON Web Token Best Current Practices, 2020) exists because the spec’s flexibility — letting the token name its own algorithm — is the root cause of most JWT attacks. Its blunt rule: the application must decide which algorithms and keys are acceptable, and verify the token against that, not against what the header asks for.

alg:none — the empty signature that some libraries accepted

The JWT spec defines an "alg":"none" value meaning “this token is unsigned.” It exists for tokens already protected by some other layer. The catastrophe: early library versions, handed a token with "alg":"none" and an empty signature segment, returned “valid.” An attacker just sets the header to none, deletes the signature, writes any payload they want, and is authenticated as anyone.

The fix is one line of discipline: the verifier must be told the expected algorithm and reject everything else. jwt.verify(token, key, { algorithms: ["RS256"] }) — an allowlist that does not contain none makes the attack impossible. Never call a decode-only function (jwt.decode, which skips the signature) and act on its claims.

RS256 → HS256 algorithm confusion

This is the subtler, nastier cousin and the one in the hook. Asymmetric RS256 uses a key pair: a private key signs, a public key verifies, and the public key is meant to be shared — it sits in your /.well-known/jwks.json. Symmetric HS256 uses one secret for both signing and verifying.

The attack exploits a server that picks its verification path from the token’s alg header:

1. Attacker grabs the public key (it’s public).
2. Attacker forges a token with "alg":"HS256" and signs it with HMAC-SHA256 using the public key string as the HMAC secret.
3. The server reads HS256, branches into the HMAC code path, and runs HMAC-SHA256 with its public key as the secret — the exact operation the attacker just did.
4. The signatures match. The forged admin token is accepted.

The whole thing works because the server trusted the header’s alg and used one key with two algorithms. RFC 8725 names both defenses directly: pin the expected algorithm (an explicit allowlist passed to verify), and bind each key to exactly one algorithm so an RS256 public key can never be fed into an HMAC verifier.

No revocation: a stolen JWT is valid until it expires

The defining property of a stateless JWT is that the server does not store it — it just verifies the signature and trusts the exp claim. The flip side is the production headache: there is no built-in logout. If a token is stolen (XSS, a leaked log, a proxy), you cannot un-issue it. Calling a “logout” endpoint that deletes a client cookie does nothing to a token the attacker already copied. It stays valid until exp.

The senior mitigation is to keep the blast radius small with time. Issue short-lived access tokens — 5 to 15 minutes is the standard range — paired with a long-lived refresh token that exchanges for new access tokens. Now a stolen access token dies in minutes. The refresh token is the high-value secret, so it gets rotation: every time it’s used, the server issues a new refresh token and invalidates the old one. If an old refresh token is ever replayed (the attacker used the one you’d already rotated past), the server detects reuse and revokes the entire token family — turning a stolen refresh token into a self-defeating trap.

Where you store the token decides which attack hits you

A token is a bearer credential: whoever holds it is you. So storage is a security decision, not a convenience one, and it’s a genuine tradeoff with no free option.

• localStorage is reachable by any JavaScript on the page. One XSS bug — a vulnerable dependency, an unsanitized render — and the attacker reads the token and exfiltrates it. There’s no httpOnly equivalent for localStorage.
• httpOnly cookies are invisible to JavaScript, so XSS can’t read them — but cookies are sent automatically, which opens CSRF. You close that with SameSite=Strict (or Lax) plus Secure, and CSRF tokens for sensitive actions.
• In-memory (a JS variable) survives neither a refresh nor a new tab, but it never touches disk and is the smallest XSS target — common for the access token, paired with an httpOnly cookie holding the refresh token.

There is no storage that’s immune to everything; you pick which class of attack you’d rather defend, and short token TTLs shrink the damage of whichever one slips through.