Security Pitfalls

JWT Security Pitfalls

JWTs are secure when implemented correctly, but several common mistakes create critical vulnerabilities.

Pitfall 1: The alg: none Attack

The Problem

The JWT spec defines "alg": "none" for unsigned tokens (used in development). If a server naively reads the algorithm from the token header and uses it for verification, an attacker can:

1. Take a valid token
2. Modify the payload (change role: "user" to role: "admin")
3. Set the header to "alg": "none"
4. Remove the signature
5. The server “verifies” with algorithm none — which always succeeds

Original token (signed):
  Header:    {"alg": "RS256", "kid": "key-1"}
  Payload:   {"sub": "user_42", "role": "user"}
  Signature: [valid RSA signature]

Attacker-modified token:
  Header:    {"alg": "none"}
  Payload:   {"sub": "user_42", "role": "admin"}  ← elevated privileges
  Signature: [empty]

Vulnerable server reads alg from header → "none" → no verification → accepts!

The Fix

Never read the algorithm from the token. Always specify the allowed algorithms in your verification code:

# VULNERABLE — reads algorithm from token header
claims = jwt.decode(token, key, algorithms=jwt.get_unverified_header(token)["alg"])

# SECURE — explicit algorithm allowlist
claims = jwt.decode(token, key, algorithms=["RS256"])

Pitfall 2: Key Confusion (HS256 / RS256 Mix-Up)

The Problem

An RS256 system uses a public/private key pair. The public key is published (JWKS). An attacker:

1. Downloads the public key from the JWKS endpoint
2. Creates a token signed with HS256 using the public key as the HMAC secret
3. Sends the token to the server

If the server reads "alg": "HS256" from the header and verifies using HS256 with the same “key” (which happens to be the public key string), the signature matches — because HMAC(payload, public_key) is valid when checked with HMAC(payload, public_key).

flowchart LR
    subgraph "Normal RS256 Flow"
        Auth1[Auth Server] -->|"sign with PRIVATE key"| Token1[JWT alg=RS256]
        Token1 -->|"verify with PUBLIC key"| API1[API Server ✓]
    end

    subgraph "Key Confusion Attack"
        Attacker([Attacker]) -->|"sign with PUBLIC key
as HS256 HMAC secret"| Token2["JWT alg=HS256
(forged)"]
        Token2 -->|"server reads alg=HS256
verifies with 'key' param
(which is the public key)"| API2["API Server ✓
(incorrectly accepts!)"]
    end

    style API2 fill:#f66

The Fix

Never let the token dictate the algorithm. Hardcode the expected algorithm and key type:

# VULNERABLE — flexible algorithm from token
claims = jwt.decode(token, key)  # library picks algorithm from header

# SECURE — explicit algorithm, correct key type
claims = jwt.decode(token, rsa_public_key, algorithms=["RS256"])
# If attacker sends alg=HS256, library rejects it because
# the key is an RSA public key, not an HMAC secret

Pitfall 3: Missing Audience Validation

The Problem

Two services (App A and App B) trust the same auth server. A user authenticates with App A and receives a JWT. The attacker takes that JWT and sends it to App B’s API. Without audience validation, App B accepts it — because the signature is valid and the issuer is trusted.

User authenticates with App A → JWT {aud: "app-a.com", sub: "user_42"}
Attacker sends this JWT to App B's API
App B checks: signature valid? ✓  issuer trusted? ✓  not expired? ✓
App B does NOT check: aud == "app-b.com"? ✗
→ App B accepts the token — user_42 gains access to App B without authorization

The Fix

Always validate aud:

claims = jwt.decode(
    token, key,
    algorithms=["RS256"],
    audience="https://api.app-b.com",  # MUST match the aud claim
)
# Token with aud="https://api.app-a.com" will be rejected

Pitfall 4: Tokens That Live Too Long

The Problem

A JWT with exp set to 30 days is essentially a session cookie with no server-side revocation. If stolen, the attacker has 30 days of access. Unlike a session ID, you can’t delete it from a database to revoke it.

The Fix

Short expiry (5–15 minutes) + refresh token (covered in the OAuth 2.0 & OIDC post). The short window limits the damage of a stolen access token.

Pitfall 5: Storing Sensitive Data in the Payload

The Problem

JWTs are signed, not encrypted. The payload is Base64URL-encoded — anyone can decode it. Do not put passwords, SSNs, credit card numbers, or other secrets in the payload.

import base64, json

token = "eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyXzQyIiwic3NuIjoiMTIzLTQ1LTY3ODkifQ.signature"

# Anyone can read the payload — no key needed:
payload = token.split(".")[1]
# Add padding for Base64
payload += "=" * (4 - len(payload) % 4)
data = json.loads(base64.urlsafe_b64decode(payload))
print(data)  # {"sub": "user_42", "ssn": "123-45-6789"} ← exposed!

Rule: Only put data in the JWT that you’d be comfortable putting in an HTTP header. Use JWE (JSON Web Encryption) if you truly need encrypted tokens — but consider whether the data belongs in the token at all.

JWT in the Request Pipeline

flowchart TB
    C([Client]) -->|"Authorization: Bearer eyJ..."| GW[API Gateway / LB]

    GW --> V{Validate JWT}
    V -->|"1. Decode header"| Alg{alg in allowlist?}
    Alg -->|No| R401_1([401 Unauthorized])
    Alg -->|Yes| Key{Fetch public key
by kid from JWKS cache}
    Key -->|Not found| R401_2([401 Unauthorized])
    Key -->|Found| Sig{Verify signature}
    Sig -->|Invalid| R401_3([401 Unauthorized])
    Sig -->|Valid| Exp{exp > now?}
    Exp -->|Expired| R401_4([401 Expired])
    Exp -->|Valid| Aud{aud matches?}
    Aud -->|Mismatch| R401_5([401 Unauthorized])
    Aud -->|Match| Iss{iss trusted?}
    Iss -->|No| R401_6([401 Unauthorized])
    Iss -->|Yes| BL{Check blocklist?
optional}
    BL -->|Revoked| R401_7([401 Revoked])
    BL -->|OK / skip| Pass[✓ Forward to service
with user_id from sub]

    style Pass fill:#bfb

Test Your Understanding