attacking-jwt

Attacking JWT

A JWT is not a credential you are meant to read — it is a signature-verification decision the server makes on bytes you control. Every field, including the alg header that tells the server how to check the signature, is attacker-supplied. The classic failures all come from the server trusting the token's own header to decide how to verify it, or from a secret weak enough to recover offline.

Only against systems you are authorized to test.

When to Use

• A request carries a token in three base64url parts joined by dots, typically starting with eyJ (the encoded {" of the header)
• An Authorization: Bearer <token> header is present
• A session, access_token, id_token, or remember-me value lives in a cookie, localStorage, sessionStorage, or a query parameter
• The application authenticates or authorizes based on a signed token rather than a server-side session
• You control any claim (sub, role, admin, aud, iss) and want to see whether the signature is actually enforced

When NOT to Use

• The wider web-application methodology — use testing-web-applications
• API authentication and authorization generally — use testing-apis
• The cryptographic primitives themselves (HMAC, RSA, ECDSA design) — use reviewing-cryptography
• The OAuth/OIDC flow that issues the token, redirect_uri and PKCE abuse — use attacking-oauth-oidc
• Cloud IAM tokens (AWS STS, GCP, Azure AD access tokens) as an access primitive — use exploiting-cloud-platforms

Decode and Inspect First

A JWT is header.payload.signature, each part base64url (no padding, - and _ instead of + and /). The first two parts are plaintext; only the signature is protected.

# jwt_tool: the fastest way to read a token and see every claim
python3 jwt_tool.py <token>

# By hand, no tools, no network
echo '<header>'  | tr '_-' '/+' | base64 -d 2>/dev/null; echo
echo '<payload>' | tr '_-' '/+' | base64 -d 2>/dev/null; echo