Security
JWT pitfalls: multiple-choice review
Crux Multiple-choice synthesis across the JWT-pitfalls unit — alg:none, RS256-to-HS256 confusion, claim validation, revocation, and token storage tradeoffs.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole unit. Each one mirrors a real verification decision — not a definition to recite, but a trust boundary to defend under an attacker who controls the token.
Goal
Confirm you can connect the JWT failure modes — algorithm trust, key binding, claim checks, revocation, and storage — into one rule: never let the token describe how it should be verified.
Quiz
Completed
A library version accepts a token whose header is alg:none with an empty signature segment and returns valid. Why is this catastrophic, and what is the one-line fix?
Heads-up JWTs are signed, not encrypted by default, and encryption is a separate concern. The integrity gap is the empty signature being accepted — encryption would not stop a verifier that trusts alg:none.
Heads-up exp is just another attacker-controlled claim once the signature is not verified. With alg:none accepted, the attacker sets exp to whatever they like along with role:admin.
Heads-up There is no signature to guess — alg:none means no signature at all. Key length is irrelevant; the verifier must reject the none algorithm outright.
Quiz
Completed
In the RS256-to-HS256 confusion attack, what is the secret the attacker signs the forged token with, and why does the server accept it?
Heads-up No private-key recovery happens; RSA is not broken. The attack abuses the public key as a symmetric secret — the public key is already published in the JWKS endpoint.
Heads-up Nothing is brute-forced. The HMAC secret is the public key, which is freely available, so the attacker computes a valid HS256 signature directly.
Heads-up Cookies are unrelated to JWT signing. Confusion works purely because the verifier lets the header pick HS256 and feeds a key bound for RS256 into the HMAC path.
Quiz
Completed
A service correctly pins alg:RS256 and verifies the signature, but a token minted for a different microservice in the same trust domain is accepted as its own. Which claim check is missing?
Heads-up exp governs lifetime, not intended recipient. A perfectly fresh token for another audience is still wrong for this service; only aud/iss scope it to the right consumer.
Heads-up Signature validity only proves authenticity of issuance. Without aud, any service sharing the key accepts tokens minted for any other service — a confused-deputy across the trust domain.
Heads-up kid selects which key verifies the signature; here the signature already verified. The defect is accepting a token whose audience is a different service entirely.
Quiz
Completed
A token's header carries a kid that points at https://attacker.example/jwks.json, and the server fetches the key from that URL to verify. What is the failure, and the fix?
Heads-up HTTPS authenticates the attacker's own server, not that the key is yours. The header chose the location, so transport security does not stop the attacker from serving a key they control.
Heads-up Caching an attacker-supplied key just pins the wrong key. The defect is sourcing the key from a header-named location at all; pin trusted keys server-side.
Heads-up kid selects the verification key. If the server fetches the key the header points to, the attacker fully controls verification — the opposite of cosmetic.
Quiz
Completed
A user reports their session was hijacked. With a stateless JWT, why can't you log them out server-side, and what bounds the damage?
Heads-up A stateless JWT was never in your database — that is the whole design. There is no row to delete; the token is valid until exp unless you add a revocation list.
Heads-up Deleting the client's copy does nothing to a token the attacker already exfiltrated. It stays valid until exp regardless of the client's cookie state.
Heads-up JWTs are not one-time tokens; the same JWT is replayable until its exp passes, which is exactly why short TTLs and rotation matter.
Quiz
Completed
A SPA must survive page refreshes. Which storage split does a security-minded senior ship, and why?
Heads-up localStorage is readable by any script on the page, so one XSS bug exfiltrates both tokens — including the long-lived refresh token, the worst thing to lose. There is no httpOnly equivalent for localStorage.
Heads-up Dropping httpOnly keeps the cookie JavaScript-readable, so you keep XSS exposure AND add CSRF surface from automatic cookie sending — the worst of both models.
Heads-up In-memory is fine, but a 24h access token has no fast revocation and you have removed the refresh-rotation that detects reuse. Short TTL plus rotation is the entire point.
Recap
The through-line across the unit is one rule: never trust the token to describe its own verification. alg:none and RS256-to-HS256 confusion both die when you pin an explicit algorithm allowlist and bind each key to one algorithm; attacker-controlled kid/jku die when you resolve keys only against a pinned allowlist. A valid signature is necessary but not sufficient — check aud and iss so a token is scoped to THIS service. And because a stateless token cannot be un-issued, short access TTLs, refresh-token rotation with reuse detection, and XSS-aware storage bound whatever leaks.