JWT Attack Playground

Break six synthetic tokens, watch an unsafe verifier accept them, then compare the exact validation rule that blocks each failure. All keys, signatures and dictionary attempts stay in this browser.

LAB

Use this playground for learning and for tokens you are authorized to test. The RSA key pair, mock filesystem and weak secrets below are generated for this page. The lab never contacts a target, reads a real server path or stores pasted tokens.

Unsigned token accepted as alg:none

The attacker changes the claims and removes the signature. A verifier that trusts the header's algorithm treats the token as intentionally unsigned.

Forged claims

{{noneResult.token}}

Verifier decision

Trust header alg No signature is checked. The forged role: admin claim reaches authorization. accepted

Pinned algorithm The server requires its configured algorithm before it reads any claim. rejected

Fix: configure an explicit algorithm allowlist, reject none, and verify the signature before using the payload.

HS256 and RS256 key confusion

The lab creates a fresh RSA key pair, then signs an HS256 token with the public key text as the HMAC secret. A confused verifier accepts it because it chooses the algorithm from the token.

Ephemeral key lab

The private key is never displayed or persisted. Generate a new pair for every run.

Verifier decision

Trust token alg The verifier reuses the RSA public key bytes as an HMAC secret when the forged header says HS256. accepted

Expect RS256 The forged token never reaches RSA verification because its algorithm does not match policy. rejected

Legitimate RS256{{confusionResult.legitimateAccepted?'signature valid':'failed'}}

Forged HS256{{confusionResult.vulnerableAccepted?'accepted by confused verifier':'failed'}}

Pinned verifier{{confusionResult.safeAccepted?'accepted':'rejected before key use'}}

Fix: bind each issuer and key to one allowed algorithm. Never derive verification behavior from an untrusted alg header.

No key pair yetRun the local demo to compare both verifier paths.

kid path traversal

The untrusted kid header is concatenated into a server key path. This browser lab resolves that path against a tiny mock filesystem, never the device running it.

Header value

{{kidResult.token}}

Weak HS256 secret recovery

A signed token is only as strong as its HMAC secret. The worker tests the local wordlist without freezing the interface or sending the token anywhere.

HS256 token

Candidate secrets · one per line

Maximum 50,000 non-empty candidates per run.

Worker run

{{weakAttempts}} / {{weakTotal}} attempts

Recovered secret{{weakFound}}

Fix: generate at least 256 random bits for HS256, rotate exposed secrets, and prefer asymmetric signing when verifiers should not receive signing authority.

Expired token replay

The signature remains mathematically valid after exp. A verifier that checks only the signature silently turns a short-lived bearer token into a permanent credential.

Expired signed token

{{replayResult.token}}

issued at{{formatUnix(replayResult.payload.iat)}}

expired at{{formatUnix(replayResult.payload.exp)}}

signaturecryptographically valid

Signature onlyThe HMAC matches, so the stale bearer credential is replayed successfully.accepted

Full claims policy{{replayResult.temporal.reasons.join(', ')}}. Issuer and audience must also match the endpoint policy.rejected

Fix: validate exp, nbf, issuer and audience on every request. Use short TTLs and a revocation or token-version strategy where immediate invalidation matters.

jku SSRF — trusting the token's own key URL

The token's jku header names the URL its public key comes from. A verifier that fetches whatever URL the token supplies lets an attacker publish their own key and point straight at it. This lab never fetches any URL — the "server" the vulnerable and safe paths consult is a two-entry in-memory map, so the concept is reproduced without a single request leaving this tab.

Forged token (self-signed, self-published)

A fresh RSA pair signs the token; a second, unrelated RSA pair plays the real issuer. Neither key is displayed or leaves this page.

{{jkuResult.forgedToken}}

No forged token yetRun the local demo to compare both verifier paths.

What this lab proves

JWT decoding is not trust. Header and payload are untrusted input until verification succeeds.
Signature verification is not enough. Algorithm, key, issuer, audience and temporal claims are one policy.
Convenient dynamic key lookup expands the attack surface. Keep kid inside an explicit key map.
Bearer tokens can be replayed. Short expiry limits damage but does not replace secure transport and storage.
A token that names its own key location is not trustworthy. Pin jku/x5u lookups to a server-configured URL, never the token's own claim.

Privacy and scope

This page uses Web Crypto for HMAC and RSA operations. The weak-secret run executes in a Web Worker. No fetch, analytics call, local storage or server endpoint receives your token, candidates or generated keys.

The path traversal scenario uses a two-entry JavaScript object as a mock filesystem. It cannot read a local file or a server path. The jku SSRF scenario is the same idea applied to key URLs: a two-entry in-memory Map stands in for a JWKS server, and neither the vulnerable nor the safe verifier path ever makes a network request — the "attacker" URL is never actually requested, anywhere.

Test only systems and tokens you own or are explicitly authorized to assess.