The JWT alg:none Attack

How it works

The JWT spec defines an none algorithm for unsecuredtokens — a JWT with no signature. The attack is simple: take a valid token, set the header's alg to none, and drop the signature so the token ends with a trailing dot (header.payload.). If the server accepts it, you can change any claim — role, sub, admin — and it will be trusted.

Because some servers only blocklist the exact string none, case variants are used to slip past naive filters: None, NONE, nOnE. A correct implementation rejects all of them when an unsecured token is not expected.

Why it matters

This is a complete authentication bypass. No key, no secret, no cracking required — if the server trusts alg:none, forging an admin token is trivial.

How to test for it

• Open the Attack tab's alg:none generator. It strips the signature and produces the none / None / nOnE / NONE variants, plus ready-to-run curl, Burp, nuclei and jwt_tool artifacts.
• Tamper a claim that affects authorization (e.g. set a role to admin).
• Replay each variant against an endpoint you are authorized to test. If any is accepted, the server does not enforce signatures.

How to fix it

• Never accept alg:none in production. Configure the verifier with an explicit algorithm allow-list that does not include none.
• Reject tokens whose signature segment is empty.
• Keep libraries up to date — several historical CVEs were exactly this bug in popular JWT libraries.

Related: algorithm confusion (RS256 → HS256) is another header-driven bypass. You can also paste a token into the Audit tab to surface these signals automatically.