JWT Security Attacks

JSON Web Tokens (JWTs) are widely used for authentication and authorization, but they are secure only when implemented correctly. Many real-world security breaches occur due to misconfiguration, incorrect assumptions, or incomplete validation.

This page explains the most common JWT security attacks, how attackers exploit them, and how to properly defend against them in production systems.

1. alg=none Attack

JWTs include a header that specifies the signing algorithm. In early or poorly implemented libraries, servers may accept alg=none, meaning no signature verification is performed.

An attacker can modify the token payload, set the algorithm to none, and the server may trust the token as valid.

Real-World Impact

• Privilege escalation
• User impersonation
• Complete authentication bypass

Mitigation

• Explicitly whitelist allowed algorithms
• Reject tokens with alg=none
• Never rely on token header values blindly

2. Token Replay Attack

JWTs are bearer tokens. Anyone who possesses a valid token can use it until it expires. If a token is stolen, it can be replayed multiple times.

Common Token Theft Vectors

• XSS attacks
• Man-in-the-middle attacks (no HTTPS)
• Insecure client storage

Real-World Impact

• Account takeover
• Unauthorized API access

Mitigation

• Short-lived access tokens
• Refresh tokens with rotation
• Bind tokens to device or session context

3. Weak Signing Keys

JWTs signed with weak secrets (for example, short strings or common words) can be brute-forced by attackers. This is especially dangerous when using symmetric algorithms like HS256.

Attack Scenario

An attacker captures a JWT and attempts to guess the signing key offline. If the key is weak, the attacker can generate valid tokens.

Mitigation

• Use long, random secrets (at least 256 bits)
• Prefer asymmetric algorithms (RS256, ES256)
• Rotate signing keys periodically

4. Algorithm Confusion Attack

In some implementations, servers incorrectly allow both symmetric and asymmetric algorithms. An attacker can trick the server into verifying a token using the wrong algorithm.

Example

A server expects RS256 but accepts HS256. The attacker uses the public key as an HMAC secret to forge tokens.

Mitigation

• Enforce a single expected algorithm
• Do not auto-detect algorithms from token headers

5. Missing Claim Validation

Many systems verify the JWT signature but fail to validate critical claims such as:

• exp (expiration)
• iss (issuer)
• aud (audience)

This allows attackers to reuse expired tokens or tokens issued for a different service.

Mitigation

• Always validate standard claims
• Reject expired or incorrectly issued tokens

6. Storing JWTs Insecurely

Storing JWTs in localStorage or sessionStorage exposes them to XSS attacks. If JavaScript can access the token, so can injected malicious code.

Mitigation

• Store JWTs in HttpOnly, Secure cookies
• Use SameSite cookies where applicable

7. Overloaded JWT Payloads

Developers sometimes store sensitive or excessive data inside JWT payloads, assuming they are encrypted. JWT payloads are only Base64 encoded, not encrypted.

Real-World Impact

• Information disclosure
• Compliance violations

Mitigation

• Store minimal claims only
• Never include secrets or PII in JWTs

Best Practices Summary

• Always verify signature and algorithm explicitly
• Use HTTPS for all token transmission
• Prefer RS256 or ES256 over HS256
• Use short-lived access tokens
• Validate all standard claims
• Store tokens securely (HttpOnly cookies)

Final Thoughts

JWTs are powerful but unforgiving. Most JWT vulnerabilities are not flaws in the standard, but mistakes in implementation.

A secure JWT implementation requires correct cryptography, strict validation, and secure client-side handling.