Skip to content
ImpactrStart an engagement
AuthenticationHigh

JWT Attacks

Also known as: JSON Web Token vulnerabilities · Algorithm confusion

JSON Web Tokens (JWTs) are widely used for stateless authentication. Attacks arise when a service fails to verify the token signature correctly: accepting the 'none' algorithm, confusing asymmetric and symmetric algorithms (RS256 vs HS256), trusting unvalidated claims, or using weak signing keys. Any of these lets an attacker forge a valid-looking token and impersonate other users.

OWASP
A07:2021

How it works

  1. 1The service issues JWTs but validates them incorrectly or incompletely.
  2. 2The attacker manipulates the header or payload (alg, kid) or brute-forces a weak secret.
  3. 3The server accepts the tampered token as authentic.
  4. 4The attacker assumes another identity or elevates privileges.

Example

Common flaws:
- alg: "none" accepted, signature stripped
- RS256 verified as HS256 using the public key as the HMAC secret
- Missing audience (aud) / issuer (iss) validation
- Weak HMAC secret recovered by offline brute force
Frequent JWT validation weaknesses.

Impact

Successful JWT forgery leads to authentication bypass, account takeover, and privilege escalation across every service that trusts the token.

Remediation

  • Pin the expected algorithm; never let the token's header choose it.
  • Validate signature, expiry, audience, and issuer on every request.
  • Use strong, rotated signing keys and keep public/private key usage separate.
  • Prefer vetted libraries and avoid custom JWT verification.

Detection & testing

Test tokens with alg=none, algorithm swaps, and tampered claims; attempt offline secret cracking on HMAC tokens. Confirm the server rejects all forgeries.

Impactr finds and proves whether JSON Web Token vulnerabilities — or flaws like it — are actually reachable in your own web apps and APIs, with a reproducible exploit as evidence.

Tools

Impactrjwt_toolhashcatBurp Suite

Frequently asked questions

What is a JWT algorithm confusion attack?

If a service supports both RS256 (asymmetric) and HS256 (symmetric) and derives the verification key from the token header, an attacker can sign a token with HS256 using the known RSA public key as the HMAC secret, and the server accepts it.

Related concepts