JWT vulnerabilities often come from flawed implementation, not a broken format. At Secure Coding Practices, we’ve seen systems fail by trusting a decoded payload without verifying its signature.
The main risks are mistakes in signature verification, algorithm handling, secret management, and claim validation. These errors turn a secure token into a path to account takeover.
This guide covers the common pitfalls and how to build a secure JWT setup. Keep reading to lock down your tokens.
JWT Security Essentials
Before we dive deep, remember these core truths. Most JWT breaches stem from a handful of preventable errors.
- Always verify the signature. Decoding is not verification.
- Pin your algorithm. Never let the token header dictate how it should be validated.
- Use strong, unique secrets. A weak signing key makes your entire authentication scheme guessable.
- Validate every critical claim. A cryptographically valid token can still be malicious if exp, iss, or aud are wrong.
- Plan for revocation. Stateless tokens live until they expire; you need a strategy for invalidation.
Why Do JWT Authentication Vulnerabilities Happen?
JWTs fail because developers often misunderstand what they provide. A JWT guarantees integrity, it proves the token hasn’t been altered, but it doesn’t mean the token is right for the current request.
The security model puts the burden on the verifier. In our audits, we’ve seen validation logic treated as an afterthought, a copied snippet that decoded the token and blindly trusted its contents.
This creates a dangerous gap. The token format is flexible by design, but that flexibility is a double-edged sword. Attackers exploit the space between what a token could be and what your app should accept.
Research from Lightweight Cryptography for Security and Privacy shows
“The use of JSON Web Token (JWT)s has become ubiquitous… However, the standard that describes the JWT is fragmented, and interpretations may pave the way for abuses. In this work we show a supply chain attack that exploits a weakness in the JWT standard.” – Lightweight Cryptography for Security and Privacy
Common implementation mistakes
- Skipping Signature Verification: Using a library’s decode() function instead of verify().
- Trusting Client-Controlled Headers: Letting the alg parameter in the JWT header dictate the validation algorithm.
- Weak Secret Management: Using hardcoded, short, or commonly reused secrets for HMAC signing.
- Missing Expiration Checks: Failing to check the exp claim, letting old tokens work forever.
How Can Signature Verification Fail?
This is the most critical failure. If you don’t verify the signature, you’re not using JWTs for security; you’re using base64url-encoded data.
We responded to an incident where an internal API accepted any token that was correctly formatted. The team had turned off verification in a testing environment and accidentally shipped that setting.
An attacker just changed the payload to switch their user ID to an administrator’s, re-encoded it, and the system accepted it. The signature is the whole point. Without it, the sub (subject) and role claims are just suggestions written by the client.
High-Risk Mistakes
Production code repositories frequently exhibit dangerous validation omissions during environment deployments.
The most severe architectural oversight involves calling unverified extraction functions within production endpoints, a mistake that completely bypasses the token’s cryptographic signatures and treats user-supplied payload strings as trusted data.
What Is Algorithm Confusion and Why Is It Dangerous?
Algorithm confusion attacks exploit how some libraries handle the JWT header. Here’s how it works: your server uses an asymmetric algorithm like RS256. It has a private key to sign tokens and a public key to verify them.
An attacker creates a token, sets the header to alg: HS256 (symmetric), and signs it with your server’s public key. If your verification code is set to follow the alg header, it will use the public key as an HMAC secret to check the signature.
Since the attacker signed with that exact key, the signature checks out. The server wrongly accepts a token the attacker faked. We stop this by pinning the expected algorithm in our verification logic, ignoring the token’s header completely.
In a recent analysis by CVE-2025-68925
“Jervis is a library… Prior to 2.2, the code doesn’t validate that the JWT header specifies ‘alg’:’RS256′. This vulnerability is fixed in 2.2.” – CVE-2025-68925
Attack Scenarios
Algorithm Mix-up (Asymmetric-to-Symmetric): Attackers shift the token header from an asymmetric format like RS256 to a symmetric one like HS256, then sign the payload using the target server’s publicly accessible RSA key.
If the backend validator lacks a strict algorithm policy, it treats the public key as a raw HMAC secret, rendering the faked signature valid.
Directory Traversal Key Injection (kid tampering): Attackers inject malicious file paths or local directory strings into the Key ID (kid) header field.
This exploits vulnerable backend file-lookup functions, forcing the application server to read local null files or public static assets as the signature verification key.
How Do Weak JWT Secrets Lead to Account Takeover?
Credits: Ariel Weinberger
When you use a symmetric algorithm like HS256, the security of every token depends on one secret. If that secret is weak, easy to guess, or leaked, it’s over.
Attackers use tools to brute-force secrets. We’ve seen secrets like “secret123,” the company name, or even an empty string in live code. Once the secret is cracked, an attacker can make valid tokens for any user with any privileges.
This becomes even more dangerous when attackers combine forged tokens with credential stuffing attacks against exposed authentication endpoints.
This is why secure coding practices require treating signing secrets with the same care as database passwords. They must be high-entropy, stored securely (like in a secrets manager), and changed regularly.
Prevention Checklist
- High-Entropy Secrets: Create long, random strings using a cryptographically secure random generator.
- Secure Storage: Never hardcode secrets in your source code. Use environment variables or a dedicated secrets management service.
- Key Rotation: Have a plan to rotate signing keys without logging out all your users.
- Secret Monitoring: Scan your code repositories and logs for accidental secret leaks.
Which JWT Claims Must Always Be Validated?
A valid signature only proves the token wasn’t changed after it was signed. It doesn’t mean the token is currently good for your application. That’s where claim validation comes in.
Failing to check the standard claims is a common vulnerability. Many of these broken authentication flaws occur when teams validate signatures but overlook issuer, audience, or expiration checks. We enforce a strict validation routine for every token on every request. It’s not optional.
Claims You Must Validate
- exp (Expiration Time): Is the token still valid? Reject any expired token.
- iss (Issuer): Was this token issued by a trusted source (like https://auth.yourdomain.com)? Reject tokens from unknown issuers.
- aud (Audience): Is this token meant for this service? A token for the “billing-api” shouldn’t work on the “admin-api.”
- nbf (Not Before): (If used) Has the token become valid yet?
- Custom Claims: Check application-specific claims like role or scope to enforce proper permissions.
In our code reviews, missing these checks is a major red flag. They are the final, essential step after signature verification.
What Does a JWT Exploit Look Like? Mapping Common Vulnerabilities
Knowing the theoretical flaw is one thing; seeing how it turns into a real attack is another. The table below links common vulnerabilities to how they’re exploited and what they impact. This is what we look for during a security review.
| Vulnerability | Exploitation Method | Primary Impact | Typical Root Cause |
| Missing Signature Verification | Attacker changes the payload (e.g., “role”:”user” to “role”:”admin”) and submits the token. | Full authentication bypass, privilege escalation. | Using decode() instead of verify(); disabled validation in production. |
| Algorithm Confusion (e.g., RS256 to HS256) | Attacker forges a token signed with the public key, sets alg: HS256 in header. | Token forgery, impersonation of any user. | Verifier trusts the alg header value from the untrusted token. |
| Weak HMAC Secret | Attacker brute-forces the signing secret using tools like hashcat, then signs any token. | Complete signing key compromise, ability to mint valid tokens. | Use of short, common, or hardcoded secrets for HS256. |
| alg: none Accepted | Attacker submits a token with alg: none and a modified payload. | Authentication bypass. | Misconfigured JWT library allowing unsigned tokens. |
| Unvalidated Claims (exp, aud, iss) | Attacker uses an expired token, a token for a different service, or from a malicious issuer. | Unauthorized access, cross-service attacks. | Lack of claim validation logic after signature check. |
| Sensitive Data in Payload | Attacker decodes the base64url payload (no secret needed) to steal PII or session data. | Information disclosure, privacy violation. | Storing sensitive data in an unencrypted JWT payload. |
In our audits, we find these patterns repeatedly. The table helps turn abstract risks into concrete actions you need to fix.
Why Is JWT Revocation a Common Security Weakness?
The stateless nature of JWTs is their advertised benefit, but it creates a major operational problem: revocation.
If a user logs out, changes their password, or their account is hacked, how do you invalidate their already-issued tokens? They stay cryptographically valid until their exp claim passes. This is a fundamental gap.
We address this by not relying only on the JWT’s expiry. We use a hybrid approach, with short-lived access tokens (minutes) paired with refresh tokens that can be revoked server-side.
For high-security situations, we keep a short-lived denylist or check a last-invalidated timestamp against the token’s iat (issued at) claim.
Revocation options
- Short-Lived Access Tokens: Limit the damage. A stolen token is only useful for 5-15 minutes.
- Refresh Token Rotation: Invalidate old refresh tokens when a new one is issued, providing a form of implicit revocation.
- Token Denylist: Keep a fast, short-lived cache of revoked token IDs (the jti claim) for immediate invalidation.
- Session Tracking: Maintain a lightweight server-side session record with a last-valid timestamp.
In our systems, we often combine short-lived tokens with refresh token rotation. It’s a practical balance between security and not overloading our databases.
Where Should JWTs Be Stored Safely?
This vulnerability isn’t in the JWT itself but in how clients handle it. The most common mistake is storing tokens in localStorage or sessionStorage. This makes them accessible to JavaScript, so any successful XSS attack can steal them.
We always recommend storing tokens in HttpOnly cookies for web apps. These session hijacking prevention techniques reduce the likelihood of attackers stealing active authentication tokens through client-side attacks.
This reduces XSS theft, though it means you need CSRF protection (handled with same-site cookies and anti-CSRF tokens).
For mobile or native apps, use the platform’s secure storage. The rule is simple: stop the token from being easily stolen.
Security of Common Client-Side Storage Locations
- localStorage: Low security. Stays across sessions, fully accessible via JavaScript. Highly vulnerable to XSS.
- sessionStorage: Medium security. Cleared when the tab closes, but still accessible via JavaScript. Vulnerable to XSS.
- HttpOnly Cookie: High security. Not accessible via JavaScript, protected from XSS theft. Must be used with SameSite and CSRF defenses.
In our guidance, we push hard for HttpOnly cookies. The trade-off in managing CSRF is almost always worth the protection against token theft.
What Security Controls Prevent JWT Authentication Vulnerabilities?
Building a secure JWT system needs a defense-in-depth approach. It’s about mixing strong cryptography with solid application logic. Our secure coding checklist for any new service using JWTs is non-negotiable. We treat the verification library as a dangerous tool that must be set up right.
Our layered control framework includes:
Phase 1: Strict Ingestion and Header Rejection: Immediately intercept the incoming authorization header, reject any token containing an alg: none declaration, and enforce an immutable, server-side algorithm policy (such as pinning to asymmetric RS256/ES256) to completely ignore the user-controlled header value.
Phase 2: Cryptographic Verification and Key Extraction: Extract the signing key from a secure local environment vault or a hardened JSON Web Key Set (JWKS) endpoint, then run the cryptographic signature validation routine using the designated library verify() method rather than simply decoding the string.
Phase 3: Immutable Claim Validation: Inspect the structural integrity of the verified payload by running strict boundary checks on standard temporal claims, rejecting any tokens where the current system epoch time falls outside the window defined by the nbf (not before) and exp (expiration) values.
What Is The Best Practice for JWT Security 2026?
Looking ahead, the main ideas stay the same, but the tools and what people expect will change. The trend is moving toward tokens that are handled by the server, or stricter rules for JWTs. For most groups, the job is to make what you already have better.
Your Actionable Checklist
- Use Asymmetric Signing (RS256/ES256): Pick these over symmetric ones (like HS256) so you don’t have to share a secret key.
- Implement Algorithm Pinning: In your code, write the expected algorithm directly. Never take it from the token header.
- Adopt a Good Validation Library: Use a library that’s been tested a lot and set it up with tight rules.
- Enforce Short Expirations: Make access tokens last 15 minutes or less.
- Design a Revocation Strategy: Choose a way to cancel tokens (short life + refresh token rotation) and put it in place.
- Integrate Security Scanning: Add checks for JWT mistakes to your security testing tools.
- Plan Incident Response: Have a plan for if a key gets stolen, including logging everyone out and changing the key.
FAQ
How can I check whether a JWT token has expired?
You can check the exp (expiration time) value stored in the JWT Claims. When the expiration time passes, the server should reject the JWT token even if the JWT Signature remains valid.
Proper signature validation and expiration checks are important parts of JWT security because they prevent attackers from using old JSON web tokens to access protected resources.
Why do weak signing keys compromise token integrity?
Using a low-entropy or predictable symmetric secret allows attackers to run offline dictionary attacks using high-throughput GPU tools like Hashcat.
Because symmetric signing relies on the same shared secret to both generate and verify signatures, cracking the key grants an attacker the immediate ability to forge arbitrary session payloads, escalate privileges, and impersonate any identity across the system.
What problems can occur when using the Key ID field?
The Key ID (kid) field tells the server which JWT key pair should be used during signature verification. If developers do not validate this field correctly, attackers may attempt JWT kid injection attacks.
In some cases, malicious values can trick the application into using the wrong file or key, resulting in signature bypass vulnerabilities.
How do public and private keys improve JWT security?
A private key creates the JWT Signature, while a public key verifies it. This approach prevents users from modifying the JWT Payload without detection.
Many systems that use OAuth 2.0 and OpenID Connect rely on public and private key cryptography because it provides stronger protection than shared JWT secrets and simplifies key distribution.
Why should APIs validate every JWT token request?
Every request sent to API authentication endpoints should undergo signature verification before access is granted.
Failure to validate JWT tokens correctly can lead to JWT vulnerabilities such as algorithm confusion, JWT algorithm confusion attacks, and JWK spoofing.
Following RFC 7519 and recommendations from the OWASP API Security Top 10 helps reduce these authentication risks.
Building JWT Authentication You Can Trust
JWT security depends on how you build it, not the technology itself. Strong login systems are built on checking the signature correctly, checking the claims strictly, keeping keys safe, and having clear rules for token life. When you use these practices every time, JWTs become a reliable part of a modern login system, not a source of risk you could have avoided.
Ready to strengthen your application security skills? Join the Secure Coding Practices Bootcamp and gain hands-on experience with secure authentication, access control, and real-world secure coding techniques.
References
- https://link.springer.com/chapter/10.1007/978-3-032-15541-2_18
- https://security-tracker.debian.org/tracker/CVE-2025-68925