The hook
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.
Kuidas see töötab
A JWT is three base64url segments — header.payload.signature. The header includes an `alg` field declaring how the signature was computed. Older verifier libraries read `alg` and dispatch to the matching verification routine. Tell them `alg: "none"` and they'd happily accept an unsigned token. Tell them `alg: "HS256"` (symmetric HMAC) when you've previously been signing with `RS256` (asymmetric RSA), and many libraries would use your *public* key as the HMAC secret — which the attacker has, because it's public. The third path is brute force: HS256 with a weak secret like `secret`, `changeme`, or your project name is crackable in seconds.
The variants
alg: none
Attacker forges a token with header `{"alg":"none"}` and an empty signature. Naive verifiers skip signature checking. Fixed in most libs by 2017 but still appears in custom verifiers.
RS256 → HS256 confusion
Token claims symmetric algorithm; verifier hands the public key to HMAC.verify as if it were a shared secret. Attacker, who has the public key, signs forgeries with it.
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.
The blast radius
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 checks
What FixVibe checks
FixVibe checks shipped client assets for high-confidence secret exposure signals and known credential formats. Reports identify the affected asset and rotation path. For check-specific questions about exact detection heuristics, active payload details, or source-code rule patterns, contact support@fixvibe.app.
Ironclad defenses
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.