A pentest reports your API accepts JWTs with `alg: none`. What's the impact and fix?

A JWT's security comes entirely from its signature. The header's alg field tells a verifier which algorithm was used — but if the server trusts that field and none is allowed, it skips signature verification entirely. An attacker then sends a token with the header {"alg":"none"}, any payload they like (for example a different sub or an admin role), and an empty signature. The server treats it as valid.

Why this is critical, not cosmetic

This is a complete authentication bypass. The attacker doesn't need to crack a key or guess a secret — they simply assert who they are and the server believes them. They can impersonate any user, including administrators, with a token they forged in seconds. That is the highest-severity outcome an auth system can have, so the "low impact, document it" option is dangerously wrong.

The correct fix

• Allow-list the expected algorithms server-side (e.g. only RS256). Reject anything else, and explicitly reject none.
• Always verify the signature against the correct key before reading any claim.
• Never let the token's own alg header select the verification path. Decoupling trust from attacker-controlled input also blocks the related algorithm-confusion attack, where a token is switched from RS256 to HS256 so the public key is misused as an HMAC secret.

Why the distractors fail

• Longer expiry changes how long a legitimate token lives; it does nothing about tokens that were never validly signed.
• Moving the token into a cookie affects transport and XSS/CSRF exposure, not whether a forged unsigned token is accepted.

What the interviewer is probing

Whether you grasp that the signature is the entire trust anchor, can articulate the bypass clearly, and reach for a server-side algorithm allow-list with mandatory verification — the kind of judgment expected of a senior AppSec engineer.