JWT Attack Simulator

A JSON Web Token (JWT) consists of three base64url-encoded parts separated by dots: Header.Payload.Signature. The header specifies the signing algorithm, the payload contains claims (user data, permissions, expiry), and the signature verifies the token wasn't tampered with. The server signs the header+payload with a secret key; clients send the JWT in requests, and the server verifies the signature to trust the claims.

The 'alg:none' attack exploits JWT libraries that accept unsigned tokens. An attacker modifies the header to set alg to 'none', then strips the signature. If the library accepts this, the attacker can forge any payload (e.g., change user ID to an admin ID) without knowing the secret key. Fix: explicitly allowlist accepted algorithms and never accept 'none'.

HS256 uses a shared symmetric key for both signing and verification. If the key is weak (short, predictable, or a common word), attackers can brute-force it offline using tools like hashcat. Once the secret is known, they can forge any JWT. Fix: use RS256 (asymmetric) for distributed systems, or use cryptographically random secrets of at least 256 bits for HS256.

Critical claims to validate: (1) exp — token expiry, prevents old tokens from working indefinitely. (2) iss — issuer, ensures the token came from your auth server. (3) aud — audience, ensures the token was meant for your service. (4) iat — issued at, helps detect time-based attacks. (5) sub — subject, identifies the user. Always validate all claims server-side, never trust client-side validation alone.

Cookies (httpOnly + secure + sameSite=strict) are generally safer because JavaScript can't read httpOnly cookies, preventing XSS-based token theft. localStorage is vulnerable to any XSS attack on your site. The trade-off: cookies require CSRF protection (sameSite=strict or CSRF tokens), while localStorage is simpler for SPAs. For high-security applications, use httpOnly cookies with short expiry and refresh token rotation.