Developer
Encoders, converters & dev utilities
The JWT alg:none Attack (and Key-Confusion) Explained
The alg:none attack is the classic JWT verification vulnerability. A JWT header names the signing algorithm; the special value {"alg":"none"} declares the token unsigned. If a verifier trusts that header, an attacker can strip the signature, set alg to none, and forge a token with any claims they like — instant privilege escalation. A correct verifier must NEVER accept an alg:none token as valid. Its dangerous sibling is the HS/RS key-confusion (algorithm confusion) attack: with an RS256 setup whose public key is known, an attacker flips the header to HS256 and signs the token using the RSA public key as the HMAC secret — because the public key is public, the forged HMAC "verifies". Both attacks share one root cause: trusting the token's own alg header. The defence is to pin the expected algorithm (and key type) on the server and reject anything else. This page explains both; the verifier here refuses alg:none and guards against key confusion. Free, no login.
alg:none declares the token unsigned — a correct verifier must NEVER treat it as valid
- Attack: strip the signature, set {"alg":"none"}, forge arbitrary claims → privilege escalation
- Key-confusion (HS/RS): flip RS256→HS256 and sign with the public RSA key as the HMAC secret
- Root cause of both: trusting the token's own alg header instead of a server-pinned expectation
- Defence: pin the accepted algorithm(s) and key type server-side; reject none and mismatches
- Reminder: decode ≠ trust — a readable payload is not an authenticated one
- This verifier refuses alg:none and will not verify an asymmetric key as a symmetric secret
Frequently asked questions
What is the JWT alg:none attack?
The alg:none attack exploits verifiers that trust the token's header. A JWT header can declare {"alg":"none"}, meaning the token is unsigned. An attacker takes a legitimate token, removes the signature, sets alg to none, and rewrites the payload claims (for example, changing a role to admin). If the server accepts alg:none as valid, the forged token is trusted with no signature at all. The mitigation is absolute: a verifier must reject any token whose algorithm is none, and more generally must not let the token choose its own verification algorithm.
What is the HS256/RS256 key-confusion attack?
It is an algorithm-confusion attack against systems using RS256 (asymmetric). The RSA public key used to verify tokens is, by design, public. An attacker changes the token header from RS256 to HS256 and computes an HMAC-SHA256 signature using that public key string as the shared secret. A naive verifier that reads alg from the header will then run HMAC verification with the public key it already has — and the forged signature matches. The defence is to pin the expected algorithm to the key type: an RSA key must only ever be used for RS256 verification, never as an HMAC secret.
How do I protect my application from these attacks?
Never trust the alg value in the incoming token to decide how to verify it. Configure your verifier with an explicit allow-list of expected algorithms (e.g. only RS256) and the matching key, and reject any token whose header does not match — including alg:none. Do not use a generic "verify with whatever algorithm the header says" call. Keep signing secrets and private keys off clients, rotate keys via JWKS, and remember that decoding a token only reveals its claims; only a correctly pinned signature check establishes trust.