Slide 12 of 28
Part 2 · How It WorksSlide 12
Slide 12 · Broken Token Validation
The API trusted a token it never verified.
JWT vulnerabilities: when the signature is optional, the token is meaningless.
How JWT Tokens Work

A JSON Web Token (JWT) has three parts: header (algorithm + type), payload (user data, claims, expiry), and signature (cryptographic proof the server issued it).

The signature is what makes the token trustworthy. If the server verifies it, you can't tamper with the payload without invalidating the token.

If the server doesn't verify it, or accepts any algorithm the client specifies, the signature is worthless.

# Attacker crafts a JWT with alg:none Header: {"alg": "none", "typ": "JWT"} Payload: {"user_id": 1, "role": "admin", "exp": 9999999999} Signature: (empty — no signature at all) # Encoded: header.payload. (trailing dot, no sig) eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyX2lkIjoxLCJyb2xlIjoiYWRtaW4ifQ.
The "alg:none" Attack

The JWT specification allows an algorithm value of "none" — meaning no signature. Poorly implemented libraries that respect the client-supplied algorithm will accept a token with alg:none and skip signature verification entirely.

An attacker sets any user ID and role they want in the payload, signs with nothing, and the API accepts it as legitimate. This has affected dozens of libraries and platforms.

Other token failures

Tokens that never expire — a stolen token works forever

Weak signing secrets — brute-forceable "secret123" keys

Not checking the exp claim — validating signature but ignoring expiry

← Back Tokens in URLs + missing re-auth →