What it is
JSON Web Tokens are the standard auth-state-in-a-cookie of the 2020s, and they fail in predictable ways. The flaws aren't in the spec; they're in the verifiers, which were too forgiving for too long. The result: a small set of attacks that have worked across thousands of production codebases — alg=none, key confusion, weak secret brute-force, key-id traversal. They all boil down to the same root cause: trusting metadata that the attacker controls.
How it happens
A JWT is three base64url segments — header.payload.signature. The header declares which algorithm signed the token. Verifiers that trust that declaration can be talked into accepting a token with no signature at all, or into checking an HMAC signature against your public RSA key, which anyone can read. The third failure is a weak HMAC secret: a short or guessable one can be recovered offline from any token you issue.
Common variants
alg: none
The verifier accepts a token that declares no signature algorithm. Most libraries fixed this by 2017, but custom verifiers still ship it.
RS256 → HS256 confusion
The verifier lets the token choose a symmetric algorithm and checks it against the public key, so anyone holding the public key can mint tokens it accepts.
Weak HMAC secret
A 6-char dictionary word as the signing secret falls to GPU-accelerated cracking in under a minute. Hashcat eats these for breakfast.
kid header traversal
Tokens reference a key by `kid`. If your app reads that header and uses it as a file path or SQL parameter, the attacker can point you at a key they control.
What an attacker gets
A forged JWT is full impersonation. Account takeover for any user the attacker can name, role escalation by setting `admin: true` in the payload, bypass of any authorization that trusts the JWT's claims. If your JWT is the auth token for an API, the attacker is the API.
// what fixvibe reports
What FixVibe reports
Runs on every URL scan: paste your app's URL, nothing to install. The free preview shows your top findings; Hobby and above unlock the full report. Each finding shows the affected URL or host, its severity and fix steps you can paste into your AI coding tool.
How to fix it
Pin the algorithm in your verifier — never read `alg` from the token. If you support multiple algorithms, dispatch on a server-side decision (e.g. by issuer), not on the token's self-description. Use HS256 only with a high-entropy random secret (≥32 bytes from a CSPRNG); use RS256/ES256 for anything cross-service. Rotate keys on a schedule and treat compromise as a planning exercise, not a fire drill. Validate the `aud`, `iss`, `exp`, `nbf` claims on every verification. Don't put authorization decisions inside JWT claims you re-fetch from the database; treat the token as identity, not as authority.