JWT Security Vulnerabilities
detect, understand, remediate
JWT vulnerabilities include weak signing algorithms, missing expiration claims, the "none" algorithm bypass, and algorithm confusion attacks that can lead to authentication bypass and token forgery.
No credit card required. Free plan available forever.
What are JWT vulnerabilities?
JSON Web Tokens (JWTs) are widely used for authentication and authorization in modern web applications and APIs. JWT vulnerabilities arise when tokens are signed with weak algorithms, accept the "none" algorithm, use guessable secrets, or fail to validate critical claims, allowing attackers to forge tokens, escalate privileges, or impersonate other users.
Because JWTs are self-contained and stateless, a forged token is indistinguishable from a legitimate one if the server cannot detect the tampering. Unlike session-based authentication where the server maintains state, a compromised JWT signing key means every token ever issued (and every future token) is under the attacker's control.
JWT security issues are particularly insidious because the tokens appear opaque to end users but are simply Base64-encoded JSON. Attackers can decode any JWT, inspect its claims, and identify weaknesses in the signing algorithm, expiration policy, or claim validation without any special access to the server.
How it works
Decode the JWT
Attacker intercepts a JWT and Base64-decodes the header and payload to inspect the algorithm (alg), claims (sub, role, exp), and structure.
Identify weakness
The attacker checks for known weaknesses: "none" algorithm acceptance, HS256 with a weak secret, algorithm confusion (RS256 to HS256), or missing exp claims.
Forge or modify token
Using the identified weakness, the attacker creates a new JWT, changing the role to admin, the sub to another user, or signing with a cracked secret.
Authenticate as victim
The forged JWT is sent to the server, which accepts it as valid. The attacker now has full access as the impersonated user or with escalated privileges.
Common causes
Accepting the "none" algorithm
Libraries that accept alg: "none" allow attackers to strip the signature entirely, creating unsigned tokens that the server trusts as valid.
Weak symmetric signing secrets
Using short, guessable, or default secrets for HS256 signing. Tools like hashcat can brute-force weak HMAC secrets from a captured JWT in seconds.
Algorithm confusion attacks
When a server expects RS256 (asymmetric) but accepts HS256, an attacker can sign the token using the public key as the HMAC secret, and it verifies.
Missing claim validation
Not validating exp (expiration), aud (audience), iss (issuer), or nbf (not before) claims allows expired, stolen, or cross-service tokens to be reused.
How to detect it
Automated detection
- SecPortal's authenticated scanner detects JWTs in responses and tests for "none" algorithm acceptance, algorithm confusion, and missing claim validation
- Code scanning identifies insecure JWT library configurations, hardcoded secrets, and missing verification steps in source code
- SCA scanners flag JWT libraries with known vulnerabilities related to algorithm handling or signature verification bypass
Manual testing
- Decode the JWT and change the alg header to "none", remove the signature, and send the modified token to see if the server accepts it
- Attempt to brute-force the HMAC secret using tools like jwt_tool or hashcat with common password wordlists
- Modify payload claims (role, sub, admin) and re-sign with a cracked secret or using algorithm confusion to test for privilege escalation
How to fix it
Enforce strong signing algorithms
Explicitly specify the expected algorithm (RS256 or ES256) on the server side and reject tokens using any other algorithm, including "none".
Validate all standard claims
Always verify exp (expiration), iss (issuer), aud (audience), and nbf (not before) claims. Reject tokens that fail any claim validation.
Use strong signing secrets
For HMAC algorithms, use cryptographically random secrets of at least 256 bits. For asymmetric algorithms, use RSA keys of 2048+ bits or ECDSA with P-256 or stronger curves.
Set short expiration times
Issue JWTs with short lifetimes (15 minutes or less) and use refresh tokens for session renewal. This limits the window of exploitation for stolen tokens.
Never store sensitive data in the payload
JWT payloads are Base64-encoded, not encrypted. Never include passwords, API keys, or PII in token claims; use opaque references to server-side data instead.
Compliance impact
Test JWT security automatically
SecPortal checks for weak algorithms, missing expiration, "none" algorithm bypass, and algorithm confusion. Start free.
No credit card required. Free plan available forever.