SauronSec
JWT: the token that can forge itself
A JWT carries its own signature — but only if the server actually checks it. Some implementations let an attacker bypass it entirely.
The principle
A JWT (JSON Web Token) is an authentication token made of three readable parts: a header, data (the user, their permissions), and a signature proving the server itself issued it.
The entire security model rests on that signature: without it, anyone could write “I am an administrator” into their own data and simply be believed.
A concrete example
Some JWT libraries, misconfigured server-side, accept a token whose header announces a “none” algorithm — literally “no signature to check”. An attacker can then craft their own token with any permissions they like, without needing to know any secret at all.
Another common case: the secret used to sign tokens is a common or predictable word (the company name, a dictionary word). An attacker guesses or cracks it offline in seconds with an ordinary wordlist, then signs their own tokens as if they were the server.
Why it’s serious
A successfully forged JWT grants access to any account, including administrator, without ever touching the password system. It’s a total, silent takeover: no failed login attempt in the logs, no alert triggered anywhere.
OWASP classifies this kind of weakness under A02:2021 – Cryptographic Failures and A07:2021 – Identification and Authentication Failures, depending on the exact angle of the issue.
How to protect yourself
Always explicitly enforce the expected signing algorithm server-side — never let the presented token “choose” its own verification algorithm. Use a long, genuinely random HMAC secret (32 bytes or more), never a dictionary word or predictable value.
For public/private key algorithms, never reuse the public key as the HMAC verification secret: that’s a classic and devastating algorithm-confusion bug. Systematically check the token’s expiry on every single request, no exceptions.
How SauronSec detects it
Passive analysis first: weak algorithm announced, HMAC secret crackable by offline dictionary, missing expiry, dangerous headers pointing to an untrusted external key.
In optional active mode, SauronSec attempts to forge a signature-less token and an algorithm-confusion token (public key reused as the secret), then checks against a genuinely protected resource whether the server accepts the forged token — never on a mere theoretical assumption.
Are these flaws on your site?
SauronSec detects them, proves them, and delivers the fix — with no false positives.