JWT Security Explained: Common JSON Web Token Flaws

JSON Web Tokens (JWTs) are everywhere in modern web apps and APIs: after you log in, the server gives your browser or app a token that proves who you are on every later request. When they are implemented carelessly, an attacker can change the token and become someone else. Here is how they work and what goes wrong.

How a JWT Works

A JWT has three parts separated by dots: a header (which algorithm signed it), a payload (claims such as the user ID, role and expiry time) and a signature. The header and payload are only Base64URL-encoded, not encrypted, so anyone can read them. The signature is what stops tampering: the server must check it on every request.

Flaw 1: the Signature Is Not Verified

Some applications decode the token and trust the payload without checking the signature. Changing "role": "user" to "role": "admin" then works. This is the most serious and, surprisingly, still a real-world finding.

Flaw 2: the "None" Algorithm

The JWT standard includes an unsigned option. If a server accepts a token whose header says the algorithm is "none", an attacker can remove the signature and edit freely. Servers must allow only the algorithms they expect.

Flaw 3: Weak Signing Secrets

Tokens signed with a shared secret (HMAC, such as HS256) are only as strong as that secret. A short or default secret can be cracked offline from a single token, after which the attacker can sign any token. Secrets must be long and random.

Flaw 4: Algorithm and Key Confusion

If a server that expects tokens signed with a private key (RS256) can be tricked into verifying with HMAC instead, using its public key as the secret, an attacker who knows the public key can forge tokens. Header fields that tell the server where to find the key, such as "kid" or "jku", can also be abused if the server trusts them.

Flaw 5: Lifetime and Storage

• Tokens that never expire, or last for weeks
• No way to revoke a token after logout or a password change
• Sensitive data placed in the readable payload
• Tokens stored where cross-site scripting can read them; see XSS explained

Testing JWTs

Testers decode tokens, try modified payloads, test the algorithm handling and check expiry and revocation, in Burp Suite and in authorized labs such as PortSwigger's Web Security Academy. Token handling is API2 in the OWASP API Security Top 10, and our Application Security course covers JWT and OAuth testing in depth.