JWT: What They Are and the 5 Most Common Security Mistakes

JSON Web Tokens (JWT) are one of the most widely used options for transmitting authentication data between client and server. Their compact format and the ability to validate identity without hitting the database on every request make them attractive, but they also expose applications to vulnerabilities that can compromise security. In this article we explain what a JWT is, describe the five most frequent security flaws, and provide concrete recommendations to avoid them.

What Is a JWT and How Does It Work?

A JWT consists of three Base64URL‑encoded parts separated by dots (.):

  1. Header – indicates the token type (JWT) and the signing algorithm (HS256, RS256, etc.).
  2. Payload – contains the claims (user identifier, roles, expiration, etc.).
  3. Signature – the result of applying the indicated algorithm to the concatenation of the header and the payload, using a secret key (HMAC) or a private key (RSA/ECDSA).

When the token is received, the server verifies the signature and, if it is valid, trusts the claims without querying the database, although additional checks (e.g., revocation lists) can be combined in some cases. This architecture enables efficient scaling of APIs and microservices, provided that signing and validation are performed correctly.

The 5 Most Common Security Mistakes

Below are the flaws that appear most frequently in audits and pentests and that often cause breaches in systems that use JWT.

1. none Algorithm Enabled

The JWT standard allows the signing algorithm to be specified in the header. Some frameworks accept the value none, which indicates that the token is unsigned. An attacker can craft an arbitrary token with "alg":"none" and modify the claims without the server detecting it. This vector is one of the most critical.

2. kid (Key ID) Injection

The kid field lets the receiver select the public key used to verify the signature. If the application does not strictly control the accepted values, an attacker can inject a kid that points to a key they control, causing the signature to be validated with the wrong key. This vulnerability, known as kid injection, appears in several JWT security guides.

3. Use of a Weak Secret Key

When HMAC algorithms are used (e.g., HS256), security depends on the strength of the shared secret. Using short, predictable passwords or storing them in plain text makes brute‑force or dictionary attacks feasible for generating a valid signature. Bugs related to weak secret are common in quick implementations or development environments.

4. Algorithm Confusion

Some servers accept both symmetric (HMAC) and asymmetric (RSA/ECDSA) algorithms. If an attacker changes the algorithm in the header without the backend verifying it, they can switch from an HMAC signature to an RSA one without knowing the private key, causing a token signed with a public key to be accepted as valid.

5. Missing Mandatory Validations (expiration, audience, etc.)

RFC 8725 states that certain claims must be validated obligatorily: exp, nbf, iat, and aud. Ignoring these checks allows an expired or replayed token to be accepted, opening the door to replay attacks or identity spoofing.

Best Practices to Avoid the Mistakes

  1. Disable none – Configure your JWT library to reject any token that declares "alg":"none" and, if possible, remove that option from the source code.
  2. Strict kid control – Validate that the kid comes from a whitelist of identifiers and load the corresponding key securely.
  3. Robust secret key – Use secrets of at least 256 bits generated randomly and store them in a secret manager (e.g., Vault or AWS Secrets Manager).
  4. Fix the algorithm – Explicitly define the algorithm your application will accept and reject any token that specifies a different one.
  5. Validate critical claims – Implement verification of exp, nbf, iat, and aud as recommended by RFC 8725. Consider revoking tokens via a blacklist when necessary.

Some best‑practice guides recommend storing JWTs in cookies with the HttpOnly and Secure flags, or in client‑side storage protected against XSS, to reduce the risk of theft via malicious scripts.

When It’s Better to Avoid JWT

In environments where session load is low and immediate revocation of access is required, a traditional server‑side cookie‑based session can be safer and easier to manage. Likewise, if the architecture does not need stateless communication between microservices, using JWT may introduce unnecessary complexity.

Conclusion

JSON Web Tokens provide an efficient way to convey authentication information, but their security hinges on careful configuration. The five mistakes described—none, kid injection, weak keys, algorithm confusion, and missing validations—are critical points that any developer or DevSecOps team should review. Applying the best practices from RFC 8725 and following recommendations from specialized sources helps mitigate these risks.

Sources and references