Home / Knowledge hub / JWT none algorithm
Knowledge hub
JWT none algorithm
A token that claims to need no signature, accepted by a careless library.
What it means
A JSON Web Token has a header that names the algorithm used to sign it. The JWT specification, RFC 7519, allows the value "none", meaning the token carries no signature at all. These "unsecured" tokens are legitimate in a few narrow cases where integrity is checked another way.
The flaw is a server that believes the header. If the library accepts whatever algorithm the token names, an attacker takes a real token, changes the claims, sets the algorithm to none and drops the signature. The result is accepted as genuine.
Why it matters
This is a full authentication bypass. An attacker can write their own token claiming to be any account or role, including an administrator, without knowing any secret. Nothing is cracked and nothing is guessed. It requires only that the server trusts the token's own header.
Several JWT libraries did accept it in the past, and the flaw still appears in custom code, older dependencies and misconfigured gateways. A pentest report with this finding is a serious one, and it is cheap to remove. It sits close to algorithm confusion.
How it shows up
The server should choose the permitted algorithm, not the token. Set the allowed algorithms in your verification call, reject "none" in any capitalisation, and keep the library current. RFC 8725, the JWT best-practice document, says implementations must let callers specify which algorithms are acceptable and should not trust the header.
Look for verification functions called with no algorithm list, code that decodes a token and reads its claims without verifying, and gateways that skip signature checks on certain routes. Test by sending a token with the algorithm set to none and the signature removed. See JWT signature checks and JWT.
Questions people ask
JWT none algorithm, answered
Is alg none a real vulnerability today?
Yes, though most current libraries refuse it by default. It still turns up in older dependencies, hand-written verification, and settings that disable checks during testing and are left on.
It is quick to test and serious when present.
Why does the standard allow none at all?
RFC 7519 defines unsecured tokens for cases where the content is protected another way, such as inside a signed or encrypted outer wrapper. It was never meant for tokens sent to users.
Applications that take tokens from clients should never accept it.
How do we fix it?
Pass an explicit list of allowed algorithms to the verification function, use a maintained library, and reject any token whose header names something else. Do not decode and trust a token without verifying it.
Add a test that an unsigned token is refused.
Is "none" in different capitalisation also a risk?
Older bypasses used variants such as "None" or "NONE" to get past a simple block list. The safer approach is an allow-list of the algorithms you use, not a block-list of those you fear.
Test with several spellings.
Does this affect signed cookies and sessions too?
It affects anything built on JWT verification that reads the algorithm from the token, including session tokens held in cookies. The format is the same, so the weakness is too.
See stateless sessions.
Sources
Where this comes from
Related
Terms that sit next to this one
JWT
A signed token a client carries to prove who is signed in.
JWT algorithm confusion
Tricking a server into verifying a token with the wrong signing method.
JWT signature verification
Checking a token's signature properly before trusting anything inside it.
Stateless session
A session kept entirely in a signed token, with nothing stored on the server.
Broken authentication
Flaws in sign-in or token handling that let someone pose as another account.
Is the token header trusted?
We submit altered tokens, including unsigned ones, to your running app and report only those it accepted, with the request and response. Where code is available we point to the verification line. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.