Prevent JWT vulnerabilities with these 5 priority controls
Relying on signature verification alone leaves your systems open to algorithm confusion attacks that bypass authentication entirely.
Enforce the RS256 algorithm, bind tokens to specific audiences, and set short expiration times. Never store secrets in client-side code. Validate every claim on the server. These steps prevent the most common token forgery and injection attacks that compromise user sessions.
The hidden cost of trusting tokens
JSON Web Tokens are ubiquitous in modern web applications. They allow systems to pass information securely between parties as a compact, URL-safe object. The promise is stateless authentication. The reality is often a minefield of implementation errors. Many teams assume that because the token is signed, it is safe. This assumption fails when the validation logic is flawed. You must treat the token as untrusted input until every claim is verified against your server’s policy.
The structure of a JWT consists of 3 parts: a header, a payload, and a signature. The header describes the signing algorithm. The payload contains the claims, such as user ID or role. The signature ensures the message was not tampered with. If any part of this chain is weak, the entire security model collapses. You are responsible for validating the signature, the issuer, the audience, and the expiration. Missing any one of these checks creates a gap an attacker can exploit.
Algorithm confusion remains the top threat
The most dangerous vulnerability in JWT implementations is algorithm confusion. This occurs when the server accepts the algorithm specified in the token header without verifying it against a whitelist. An attacker can change the algorithm from RS256 to none. This tells the server to skip signature verification entirely. The server then accepts the forged token as valid. This is not a theoretical risk. It is a common misconfiguration in many popular libraries.
You must enforce a strict list of allowed algorithms on the server side. Do not trust the header. If your application expects RS256, the server must reject any token that specifies HS256, none, or any other algorithm. This prevents attackers from switching to unsecured modes. It also stops them from using the public key to sign tokens with a symmetric algorithm. This specific attack vector bypasses the signature check by tricking the server into using the public key as the secret key.
| Measure | Effort | What it stops |
|---|---|---|
| Algorithm whitelist | Low | Algorithm confusion and none attacks |
| Short expiry times | Low | Token replay and long-lived session theft |
| Audience validation | Medium | Token misuse across different services |
| Issuer verification | Medium | Tokens from untrusted or fake sources |
| Secret rotation | High | Compromised signing keys |
Enforce strict expiration and audience checks
A token that never expires is a liability. If an attacker steals a long-lived token, they have permanent access. You must set short expiration times, typically minutes rather than hours. This limits the window of opportunity for an attacker. Refresh tokens can extend the session, but they must be handled with care. They should be stored securely and rotated on each use.
Audience validation ensures the token is intended for your service. A token issued for Service A should not be accepted by Service B. Without this check, an attacker can use a valid token from one service to access another. This is common in microservices architectures where multiple services share authentication. You must verify the aud claim matches your service identifier. This prevents cross-service token replay attacks.
Issuer verification confirms the token came from a trusted authority. You must check the iss claim against a known list of issuers. This prevents attackers from creating tokens with a fake issuer name. It also ensures that tokens from compromised or decommissioned identity providers are rejected. These checks are lightweight but critical for maintaining trust boundaries.
Secure the signing key management
The security of a JWT relies on the secrecy of the signing key. If an attacker obtains the key, they can forge any token. You must never store the signing key in client-side code, such as JavaScript files. These files are visible to anyone who views the page source. Hardcoded secrets in source code are a frequent source of leaks. Use environment variables or a secrets manager to store keys securely.
Key rotation is a best practice but often overlooked. You should rotate signing keys periodically. When you rotate a key, you must keep the old key available for a short period to validate existing tokens. This prevents service disruption. You must also ensure that the new key is distributed to all services before the old key expires. This process requires careful coordination.
If you use asymmetric algorithms like RS256, you must protect the private key. The public key can be shared, but the private key must remain secret. A compromise of the private key allows an attacker to sign tokens that appear valid. Monitor access to the private key storage. Restrict permissions to only those who need to manage the key.
What does not work for JWT security
Many teams rely on measures that provide a false sense of security. Encrypting the token payload does not prevent forgery. Encryption hides the content, but it does not verify the source. An attacker can still modify the token and re-encrypt it if they have the key. You must use signing, not just encryption, to ensure integrity and authenticity.
Using HTTPS alone is insufficient. HTTPS protects the token in transit, but it does not protect it at rest or in use. If an attacker steals a token from a client-side storage mechanism, HTTPS provides no protection. You must validate the token on every request, regardless of the transport layer. Trusting the client to validate the token is a critical error. The server must always perform the final check.
Another common mistake is relying on the token’s signature without checking the claims. A valid signature only proves that the token was not tampered with since it was signed. It does not prove that the claims are valid for your application. You must check the expiration, audience, and issuer explicitly. Skipping these checks leaves you vulnerable to replay and misuse attacks.
See also: Chrome Zero-Day Vulnerabilities: Detection, Exploitation and Mitigation
Practical prevention measures in priority order
Start by enforcing algorithm whitelisting. This stops the most impactful attacks with minimal effort. Next, set short expiration times and validate the audience. These steps limit the damage of a stolen token. Then, verify the issuer and secure the signing key. These measures ensure the token comes from a trusted source and remains secret. Finally, implement key rotation and monitor for anomalies. This creates a defence-in-depth strategy.
Consider how these measures interact with other security practices. For example, vulnerability scanning can help identify misconfigured JWT libraries in your codebase. It is also relevant to consider how hardcoded secrets in source code can expose your signing keys. By addressing these issues together, you create a more resilient security posture. Do not treat JWT security in isolation. It is part of the broader authentication and authorisation framework.
Checklist for immediate action
Review your JWT validation code today. Ensure you are not trusting the algorithm header. Check that you are validating the expiration, audience, and issuer claims. Verify that your signing keys are stored securely and not exposed in client-side code. These 3 steps will significantly reduce your risk.
- Enforce a whitelist of allowed signing algorithms on the server.
- Set short expiration times for access tokens and validate the audience claim.
- Store signing keys in a secure secrets manager, never in source code.
Key takeaways
- Algorithm confusion attacks allow attackers to bypass signature checks by switching to unsecured modes.
- Short expiration times limit the window of opportunity for stolen or leaked tokens.
- Server-side validation is mandatory; client-side checks are easily bypassed by malicious actors.
JWT security fails when implementation details are ignored. Enforce strict algorithm and claim validation on every request.
Frequently asked questions
Can I use JWT for sensitive data like passwords?
No. JWTs are not encrypted by default and can be decoded by anyone. Never store sensitive information in the payload. Use them for non-sensitive claims only.
How do I handle token revocation?
JWTs are stateless and cannot be revoked easily. Use short expiration times and maintain a blocklist for compromised tokens. This balances security with performance.
Is HS256 or RS256 better for JWTs?
RS256 is generally preferred for multi-service environments. It uses asymmetric keys, allowing public key distribution. HS256 requires sharing the secret, which is harder to manage securely.
What happens if I use an outdated JWT library?
Outdated libraries may have known vulnerabilities, such as accepting the none algorithm. Always use the latest version and monitor for security updates.
How this guide was produced: written by the Firewall Pulse editorial team with AI assistance, checked against the public references listed below, and reviewed when the facts change. See our editorial policy or report an error.
