Defense: Reject alg:none

The single most famous JWT vulnerability. RFC 7519 Section 6.1 defines the "none" algorithm — an unsigned JWT. The whole point of JWT is the signature, so alg:none should never be accepted for protected resources.

But many libraries pre-2015 had this control flow:

An attacker takes a legitimate token, swaps the header to {"alg":"none"}, truncates the signature segment, and submits it. The library returns the "verified" payload — except no signature ever validated. Game over.

Defenses (in priority order)

1. Pin the algorithm. Don't trust header.alg; the verifier knows what alg it expects, so pass it explicitly: jwt.decode(token, key, algorithms=["HS256"]).
2. Reject the none family outright — including None, NoNe, NONE. Algorithm names are case-sensitive per RFC 7515 Section 4.1.1, but case-folding parsers exist.
3. Strip support for none from your library if the language allows it.

How vendors fixed this

After CVE-2015-9235 the major libraries added:

• A required algorithms= parameter (Python PyJWT).
• A blacklist of none unless explicitly allowed.
• Deprecation warnings.

You'll implement the fixed verifier: pin HS256, refuse anything else.