JWT forging workbench

A live attacker workbench paired with a real (intentionally misconfigurable) JWT verifier. Generate a legitimate RS256 token, run an attack to produce a forged one, then watch the verifier accept or reject each as you toggle defenses.

How this works. A 2048-bit RSA keypair is generated in your browser via WebCrypto on page load. The verifier below is the same code you'd ship in production, with two configuration knobs that mirror the real footguns: trustHeaderAlg (turning it on enables RS-vs-HS confusion), and acceptAlgNone (turning it on enables CVE-2015-9235). Tokens are minted and verified with no server round-trip.

What this proves. Four CVE-class verifier bugs that have shipped in real libraries and SaaS SDKs:

alg=none bypass (CVE-2015-9235) — verifier accepts unsigned tokens. Defense: pin allowedAlgorithms, never honour none.
RS256 → HS256 alg confusion (CVE-2016-10555) — attacker HMACs the signing input with the verifier's public key as the secret. Defense: ignore the token header's alg; select the algorithm from your key material.
kid header path traversal — attacker pointskid at a known-bytes file and HMACs with those bytes. Defense: sanitize kid, resolve it through an allowlist of named keys, never as a filesystem path.
Tamper claims, keep the signature — “decode-then-trust” code paths that read the payload before verifying. Defense: verify first, read claims from the verified output, never from the raw token.

Cross-reference: paste any token you generate here into the JWT inspector for a static decode + Bearer health-check.

Generating RSA keypair…