.webp)
JSON Web Tokens authenticate modern web applications across industries, from financial services to healthcare. However, JWT vulnerabilities create serious risks. A single flaw can expose thousands of user accounts to attackers who forge tokens and bypass authentication entirely.
Major security incidents have demonstrated these risks. Understanding how JWTs work and where they fail helps security teams protect their APIs effectively.
How JSON Web Tokens Work
JSON Web Tokens provide stateless authentication by encoding information directly into the token. Unlike session-based systems that store data server-side, JWTs contain everything needed for authentication and authorization.
A JWT consists of three base64-encoded sections separated by dots:
After users authenticate, servers generate signed JWTs. Clients include these tokens in subsequent API requests. Servers validate the signature before processing requests, ensuring the token is authentic and unmodified.
This stateless approach scales well but requires careful implementation. Every security decision relies on proper signature verification and claims validation.
Critical JWT Vulnerabilities
Algorithm Confusion Attacks
The JWT header declares which algorithm signed the token. Attackers exploit this by changing the algorithm value to bypass security controls.
The "none" Algorithm Attack
Some JWT libraries support an algorithm value of "none" for unsigned tokens. Attackers modify legitimate tokens to use this algorithm, removing the signature entirely. If servers accept the "none" algorithm, they process tokens without verification, allowing complete authentication bypass.
HS256/RS256 Confusion
Asymmetric algorithms like RS256 require a private key for signing and a public key for verification. Symmetric algorithms like HS256 use the same secret for both operations.
Attackers change RS256 tokens to HS256, then sign them using the server's public key (which is, by definition, publicly available). Servers that verify HS256 tokens using their RSA public key accept these forged tokens as valid.
This represents a critical broken authentication vulnerability that completely undermines security controls.
Weak Signing Secrets
HS256 tokens depend on secret keys remaining confidential. Weak secrets enable brute force attacks that extract the key from token samples.
Attackers use specialized tools to test millions of potential secrets against captured tokens. Once they recover the signing key, they can forge valid tokens for any user.
Missing Signature Verification
Developers sometimes disable signature verification during testing and forget to re-enable it for production. JWT libraries typically require explicit verification calls rather than verifying automatically.
Applications that decode tokens without verification accept any well-formed JWT, regardless of authenticity. Attackers simply modify token payloads to escalate privileges or access other users' data.
Sensitive Data in Tokens
JWT payloads use base64 encoding, not encryption. Anyone who intercepts a token can decode and read its contents immediately.
Applications that include sensitive information in JWTs expose that data to network interception, browser extensions, JavaScript malware, system administrators, and logging systems. Sensitive data includes passwords, API keys, financial information, health records, or any personally identifiable information.
Excessive Token Lifetimes
Long-lived tokens create extended windows for exploitation. A stolen token with a 24-hour lifetime gives attackers a full day to abuse it. Refresh tokens without rotation allow indefinite access after a single compromise.
Missing Claims Validation
JWTs include standard claims that establish token validity:
Applications that skip validation expose themselves to token reuse attacks. These vulnerabilities frequently appear in the OWASP API Security Top 10 due to their widespread impact.
JWT Security Hardening Techniques
Enforce Strong Algorithms
Use asymmetric algorithms (RS256 or ES256) for production systems. Configure JWT libraries to whitelist allowed algorithms explicitly:
javascript
jwt.verify(token, publicKey, {
algorithms: ['RS256']
});
Reject any token using the "none" algorithm or algorithms not in your whitelist.
Generate Cryptographically Strong Secrets
For HS256 implementations, generate secrets using cryptographically secure random number generators. Minimum 256 bits (32 bytes), stored in dedicated secret management systems like AWS Secrets Manager or HashiCorp Vault, rotated every 90 days.
Validate All Claims
Verify every standard claim before trusting token contents:
javascript
jwt.verify(token, publicKey, {
algorithms: ['RS256'],
issuer: 'https://your-domain.com',
audience: 'your-api-identifier',
clockTolerance: 30
});
After signature verification passes, validate custom claims relevant to authorization.
Implement Short Token Lifetimes
Rotate refresh tokens on each use. When issuing a new access token, also issue a new refresh token and invalidate the old one.
Store Tokens Securely
Use HttpOnly cookies with proper configuration:
javascript
res.cookie('token', jwt, {
httpOnly: true,
secure: true,
sameSite: 'strict',
maxAge: 900000
});
For proper API authentication and authorization, secure token storage forms a critical foundation.
Maintain Token Revocation Lists
Implement token revocation for scenarios requiring immediate invalidation: password changes, explicit logout, suspicious activity, account compromise, or administrative suspension.
Store revoked token identifiers in Redis. Check every token against this list during verification.
Monitor Token Usage Patterns
Implement rate limiting on token endpoints (5-10 requests per minute per IP address).
Testing JWT Implementation Security
Manual testing cannot comprehensively validate JWT security. Security teams need automated testing that simulates real attack scenarios across all endpoints.
Effective JWT security testing identifies algorithm confusion vulnerabilities, weak signature secrets, missing signature verification, improper claims validation, excessive token lifetimes, token replay vulnerabilities, and privilege escalation through claim manipulation.
APIsec provides automated JWT security testing that integrates with CI/CD pipelines. The platform tests JWT implementations against real attack scenarios, identifying vulnerabilities before they reach production.
Learn more about automated API security testing.
Key Takeaways
- Algorithm confusion attacks bypass security by manipulating the algorithm field. Always whitelist allowed algorithms explicitly.
- Weak signing secrets enable brute force attacks. Use cryptographically strong secrets of at least 256 bits.
- Signature verification must happen before trusting any token contents.
- Short token lifetimes (5-15 minutes) with refresh token rotation limit exposure from stolen tokens.
- Store tokens in HttpOnly, Secure, SameSite cookies. Never use localStorage or sessionStorage.
FAQs
What causes JWT algorithm confusion attacks?
Algorithm confusion occurs when applications trust the algorithm specified in the JWT header without verification. Prevent this by explicitly whitelisting allowed algorithms in the verification code.
How long should JWT access tokens remain valid?
Access tokens should expire within 5-15 minutes. Combine with longer refresh tokens (7-30 days) that rotate on each use.
Where should web applications store JWTs?
Store JWTs in HttpOnly cookies with Secure and SameSite flags enabled. Avoid localStorage and sessionStorage entirely.
How do you prevent JWT signature bypass?
Explicitly verify signatures before processing any token contents. Configure JWT libraries to require signature verification and reject invalid signatures.
.webp)
.jpg)