JWT Security: 12 Mistakes Developers Still Make

JSON Web Tokens (JWTs) have become the de facto standard for stateless authentication in modern web applications. They are compact, URL-safe, and incredibly versatile.

However, this flexibility comes with a significant cost: JWTs are notoriously easy to misconfigure. A single implementation flaw can compromise your entire authentication system, allowing attackers to forge tokens, escalate privileges, and impersonate any user.

Despite years of documented vulnerabilities, developers continue to make the same critical errors when implementing JWTs. In this comprehensive guide, we will explore the 12 most common JWT security mistakes developers still make, how attackers exploit them, and the best practices you must adopt to secure your applications.

1. Accepting the "None" Algorithm

The JWT specification (RFC 7519) defines a header parameter called alg, which specifies the algorithm used to sign the token. Surprisingly, the specification includes an algorithm called none. When a token uses the none algorithm, it is considered an "unsecured JWT" and does not require a signature.

If a backend library implicitly trusts the alg header and supports the none algorithm, an attacker can simply decode the token, modify the payload (e.g., changing their role to "admin"), set the alg header to none, and strip the signature. The server will accept the forged token as valid.

How to fix it: Always explicitly define the allowed algorithms in your JWT verification library. Never rely on the token's header to dictate the verification process.

2. Skipping Signature Verification Entirely

It sounds unbelievable, but a shocking number of applications fail to verify the JWT signature. Many JWT libraries offer two distinct methods: one for decoding the token and another for verifying it. For instance, in Node.js, developers might mistakenly use jwt.decode() instead of jwt.verify().

Decoding a token merely translates the Base64Url-encoded strings back into JSON. It does not check if the token was tampered with. Attackers can exploit this by altering the payload and sending the token back to the server, which blindly trusts the decoded data.

How to fix it: Always use the verification method provided by your library, ensuring that the secret key or public key is actively used to validate the signature before trusting any claims.

3. Using Weak Secret Keys for HMAC

When using symmetric algorithms like HS256, the same secret key is used to both sign and verify the token. If this secret key is weak, short, or easily guessable, attackers can use tools like Hashcat to brute-force the secret offline.

Once the secret is cracked, the attacker has the keys to the kingdom. They can generate perfectly valid tokens for any user, bypassing all authentication mechanisms.

How to fix it: Treat your JWT secret like a highly sensitive password. Use a cryptographically secure random string of at least 256 bits (32 bytes) for HS256. Never use default secrets, company names, or simple dictionary words.

4. Falling for Algorithm Confusion Attacks

Algorithm confusion occurs when a server expects an asymmetric algorithm (like RS256) but fails to enforce it, allowing an attacker to switch the algorithm to a symmetric one (like HS256).

In an RS256 setup, the server uses a private key to sign the token and a public key to verify it. If an attacker changes the header to alg: HS256 and signs the token using the server's public key as the HMAC secret, a vulnerable server will attempt to verify the HS256 signature using its stored public key as the secret string. The verification will succeed, and the forged token will be accepted.

How to fix it: Hardcode the expected algorithm in your verification logic. If you expect RS256, explicitly reject any token that specifies HS256.

5. Storing Sensitive Data in the Payload

A common misconception is that JWTs are encrypted. By default, they are only encoded (Base64Url) and signed. Anyone who intercepts a JWT can easily decode the payload and read its contents.

Developers often make the mistake of storing sensitive information — such as passwords, internal system IDs, personally identifiable information (PII), or social security numbers — directly inside the token payload.

How to fix it: Never put sensitive data in a JWT. Only include the minimum necessary claims, such as a non-sequential user identifier (sub) and essential roles. If you must transmit sensitive data, use JSON Web Encryption (JWE) instead of JWS.

6. Insecure Storage in the Browser

Where you store your JWT on the client side drastically impacts its security. Storing JWTs in localStorage or sessionStorage is a widespread practice, but it exposes the token to Cross-Site Scripting (XSS) attacks. If an attacker manages to inject malicious JavaScript into your application, they can easily read the token from localStorage and exfiltrate it.

How to fix it: Store JWTs in HttpOnly, Secure, and SameSite cookies. An HttpOnly cookie cannot be accessed via JavaScript, completely mitigating the risk of token theft via XSS.

7. Missing or Overly Long Expiration Times

JWTs are stateless. Once issued, they remain valid until they expire. If a token does not have an exp (expiration) claim, or if the expiration is set to months or years in the future, a stolen token grants an attacker indefinite access to the system.

How to fix it: Always include an exp claim. Keep the lifespan of access tokens incredibly short (e.g., 15 minutes). Use a separate, securely stored refresh token mechanism to obtain new access tokens without forcing the user to log in repeatedly.

8. Lacking a Revocation Mechanism

Because JWTs are stateless, you cannot simply delete a session from a database to log a user out. If a user's account is compromised, or if they simply click "Log Out," the issued JWT remains mathematically valid until it expires.

Relying purely on statelessness makes immediate revocation impossible.

How to fix it: Implement a token blocklist (or denylist) for tokens that have been revoked before their expiration. Alternatively, keep token lifespans very short so that the window of opportunity for a stolen token is minimized.

9. Trusting the 'kid' (Key ID) Header Blindly

The kid (Key ID) header parameter is used to indicate which key was used to sign the token, which is useful when a server rotates multiple keys. However, if the server uses the kid value to look up the key in a database or file system without proper sanitization, it opens the door to severe vulnerabilities.

Attackers can inject SQL queries into the kid parameter (SQL Injection) or use directory traversal payloads (e.g., ../../../dev/null) to force the server to use a predictable or empty key for verification.

How to fix it: Strictly validate and sanitize the kid parameter. Use an allowlist of known, valid key IDs, and never pass the raw kid value directly into database queries or file system operations.

10. Permitting JWK Spoofing

The JSON Web Key (JWK) header parameter allows the token to embed the public key directly within the header. If a server blindly trusts the embedded key to verify the signature, an attacker can generate their own RSA key pair, embed their public key in the jwk header, and sign the token with their private key. The server will use the attacker's public key to verify the attacker's signature, resulting in a successful bypass.

How to fix it: Never trust a public key provided within the token itself unless it can be cryptographically verified against a trusted root authority. Ideally, do not support the jwk header parameter for incoming client tokens.

11. Transmitting Tokens over Plain HTTP

A JWT is a bearer token; whoever bears the token gets access. If you transmit a JWT over an unencrypted HTTP connection, anyone monitoring the network traffic (such as on a public Wi-Fi network) can intercept the token and use it to impersonate the user.

How to fix it: Always enforce HTTPS/TLS for all communications between the client and the server. Ensure that cookies containing JWTs are marked with the Secure flag so they are never transmitted over plain HTTP.

12. Ignoring Standard Claims Validation

The JWT specification defines several standard claims, such as iss (Issuer), aud (Audience), and iat (Issued At). Developers often fail to validate these claims, leading to scenarios where a token issued by one service is mistakenly accepted by another service within the same ecosystem.

How to fix it: Always validate the iss claim to ensure the token was generated by your trusted authorization server. Validate the aud claim to ensure the token is intended for the specific API receiving it. Reject tokens that are used before their nbf (Not Before) time or after their exp time.

JSON Web Tokens offer a powerful and scalable way to handle authentication, but they require rigorous attention to detail. The security of a JWT implementation relies entirely on strict validation, secure cryptographic practices, and safe storage mechanisms. By avoiding these 12 common mistakes, you can significantly harden your application's defenses and protect your users from devastating authentication bypass attacks.

If you found this guide helpful, be sure to share it with your fellow developers and follow for more deep dives into application security!