Common JWT Attacks and Vulnerabilities Explained

  • September 23, 2025

Discover key JWT vulnerabilities like token tampering, none algorithm abuse, and signature bypass. Learn how to protect your apps from JWT attacks.

Understanding JSON Web Token (JWT) Attacks and Vulnerabilities

JSON Web Tokens (JWTs) have become a fundamental technology for securely transmitting information between parties in a JSON format. Favored for their ability to be digitally signed and verified, JWTs are widely used in authorization and authentication across modern web applications. However, the security of JWTs hinges on precise implementation and configuration. Incorrect usage can open doors to significant vulnerabilities and exploitation risks.

The Anatomy of a JSON Web Token

At its core, a JWT consists of three components — the header, payload, and signature — each Base64URL encoded and separated by dots, exhibiting the following structure:

HEADER.PAYLOAD.SIGNATURE

JWT Header

The header defines metadata about the token, including:

  • alg: The cryptographic algorithm used to sign the token (e.g., HS256, RS256)
  • typ: The token type, typically “JWT”

Example of a decoded header:

{
  "alg": "HS256",
  "typ": "JWT"
}

JWT Payload

The payload carries claims, which are statements about an entity (usually the user) and additional data. For example:

{
  "name": "John Doe",
  "user_name": "john.doe",
  "is_admin": false
}

Claims can be standard (registered claims like iss, exp) or custom defined for specific application logic.

JWT Signature

The signature ensures the token’s integrity and authenticity. It is created by signing the Base64URL-encoded header and payload using a secret or private key, depending on the algorithm:

  1. Encode header and payload
  2. Concatenate the two with a dot
  3. Sign the concatenated string using the specified algorithm (e.g., HMAC with SHA-256 or RSA)

For instance, with the HS256 algorithm:

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

Common Vulnerabilities in JWT Implementation

Despite JWT’s widespread adoption, several vulnerabilities stem from misconfiguration or flawed implementation. These weaknesses can jeopardize the security of applications relying on JWTs for authentication and authorization.

1. Skipping Signature Verification

Many JWT libraries distinguish between decoding and verifying a token. The decode() function extracts token contents without authenticating the signature, while verify() ensures the signature is correct. Developers who inadvertently rely solely on decode() risk accepting tampered tokens.

Impact: Attackers can modify tokens arbitrarily—elevating privileges or impersonating users without detection. For example, changing the is_admin claim from false to true in an unsigned token could grant unauthorized admin access.

2. Allowing the “None” Algorithm

The JWT specification includes a “None” algorithm option, indicating an unsigned token. If applications permit tokens signed with alg: none, attackers can bypass signature verification by stripping the signature entirely.

Case in Point: Historical attacks have successfully exploited alg: none acceptance to compromise services (see Auth0’s analysis).

Mitigation: Explicitly disallow the none algorithm and enforce validation against an expected algorithm whitelist.

3. Algorithm Confusion Attacks

JWT supports both symmetric (HMAC) and asymmetric (RSA, ECDSA) algorithms. Confusion arises when applications fail to strictly verify the algorithm type, allowing attackers to switch the algorithm field (e.g. from RSA to HMAC) and trick the verifier into using inappropriate key material.

Example: An attacker replaces alg: RS256 with alg: HS256 and uses the public key as the HMAC secret, enabling them to forge valid signatures without the private key.

This vulnerability has surfaced in several JWT libraries and remains a critical risk if the algorithm is not explicitly validated.

4. Using Weak or Guessable Secrets for Symmetric Signing

In symmetric cryptography (like HS256), token security depends entirely on the secrecy of the shared key. Weak secrets such as simple passwords or predictable strings are vulnerable to brute-force attacks.

Research Insight: Studies indicate that many JWTs use weak secrets like “123456” or “password” (see Snyk JWT Vulnerability Report 2023), enabling attackers to rapidly compromise authentication.

Best Practice: Employ strong, randomly generated secrets of sufficient length—ideally over 256 bits—and rotate them periodically.

5. Exploiting the Key ID (kid) Parameter

The kid parameter in the JWT header is used to identify which key to use for signature verification. However, when unvalidated, it can be exploited in several ways:

  • Injection Attacks: Malicious input in kid can lead to SQL injection, remote code execution (RCE), or local file inclusion (LFI) vulnerabilities if used unsafely for key retrieval.
  • Directory Traversal: Attackers manipulate the kid to reference arbitrary files (e.g., /dev/null) to bypass signature checks.
  • SQL Injection: Unsanitized SQL queries with user-controlled kid enable attackers to force key substitution for signature forging.

Security Tip: Sanitize and strictly validate the kid parameter before use. Employ prepared statements for database queries and restrict file system access rigorously.

6. Abuse of the jku Header Parameter

The jku (JSON Web Key Set URL) parameter allows dynamic fetching of public keys from a remote URL. Without proper validation, attackers can direct applications to attacker-controlled JWKS endpoints containing forged keys.

  • Attack Vector: Modify jku to a malicious URL, generate your own key pair, and sign tokens that the application mistakenly accepts.
  • Bypassing Defenses: Attackers use URL parsing tricks, open redirects, DNS tricks, and SSRF to evade domain restrictions or URL filters.

Mitigation Strategies:

  • Whitelist trusted domains for jku values and enforce strict URL format checks.
  • Use static or internally managed keys where possible, avoiding dynamic key fetching.
  • Implement robust SSRF protections to prevent unauthorized requests.

Additional Considerations and Best Practices

  • Use Established JWT Libraries: Implement JWTs using well-maintained libraries with active security updates.
  • Enforce Token Expiration: Set reasonable expiration times (exp claim) and validate them strictly to limit token replay.
  • Implement Audience and Issuer Checks: Confirm the token is intended for your application by validating aud and iss claims.
  • Rotate Secrets and Keys: Regularly update cryptographic keys and secrets to minimize damage from leaks.
  • Employ Multi-Layered Security: JWT verification should be part of a comprehensive security strategy incorporating server-side authorization checks, rate limiting, and anomaly detection.

Real-World Case Studies

Case Study 1: Auth0’s Algorithm Confusion Vulnerability
In 2015, Auth0 disclosed a critical JWT vulnerability where an attacker could exploit algorithm confusion to bypass authentication, emphasizing the importance of algorithm validation (source).

Case Study 2: Microsoft Azure Container Service JWT Misconfiguration
In 2018, a misconfigured JWT validation in Azure Container Service led to privilege escalation by allowing tokens with the none algorithm. The vulnerability was patched after disclosure (source).

Conclusion

JSON Web Tokens are essential for modern authentication and authorization but present significant security risks when improperly implemented. Attackers exploit weaknesses such as missing signature verification, algorithm confusion, weak secrets, and unsafe handling of JWT header parameters like kid and jku. To safeguard applications, developers must strictly adhere to best practices, rigorously validate all JWT elements, and utilize trusted libraries.

Ongoing vulnerability assessments and security testing tailored for JWT implementations are crucial for maintaining robust application security. Addressing JWT vulnerabilities mitigates risks of unauthorized access, privilege escalation, and wide-reaching security breaches.