Common JWT misconfigurations

October 20, 2026 · 14 min read

JWT auth fails quietly when configuration drifts: a staging secret copied to production, a library that accepts alg: none, or a gateway that decodes but never verifies. This guide maps the misconfigurations security reviews catch most often and the concrete checks that close each gap.

Weak signing keys and shared secrets

HMAC JWTs are only as strong as the secret. Strings like secret, UUIDs used as passwords, or keys under 256 bits of entropy are brute-forceable offline once an attacker has one token. Generate secrets from a CSPRNG, store them in a secrets manager, and separate signing keys per environment.

• Never commit HS256 secrets to Git or sample env files checked into the repo.
• Rotate keys with a kid header and JWKS or config versioning so verifiers accept both keys during cutover.
• Prefer RS256/ES256 when many services verify the same issuer - one leak of a shared HMAC secret compromises every consumer.

Accepting "alg": "none" and algorithm confusion

Legacy libraries allowed unsigned tokens when the header said none. Modern code must allowlist algorithms: if you expect RS256, reject HS256 attempts that trick verifiers into using the RSA public key as an HMAC secret. Pin expected alg per issuer and key id.

// Dangerous header - must be rejected in production
{ "alg": "none", "typ": "JWT" }

// Verifier rule: alg must match configured list ["RS256"]

Missing exp, nbf, and key rotation

Tokens without exp stay valid until someone rotates secrets - effectively forever if revocation is absent. Always set short-lived access tokens, optional nbf to block early use, and iat for skew debugging. Pair access tokens with refresh token rotation documented in your auth design.

Tokens in URLs, referrer headers, and logs

Putting JWTs in query strings leaks them via browser history, analytics, CDN logs, and the Referer header when users follow external links. Use the Authorization: Bearer header or HttpOnly cookies. Redact tokens in application and proxy logs; treat decoded payloads as sensitive in support tickets.

Validation checklist and HTTPS

• Verify signature, exp, iss, and aud on every request - decode-only middleware is not auth.
• Terminate TLS at the edge; never send Bearer tokens over plain HTTP.
• Use maintained libraries (jose, jsonwebtoken with strict options) - do not hand-roll Base64URL and HMAC.

Inspect suspicious tokens locally with the JWT decoder and validate PEM material with the PEM validator before blaming application code.

Related: Common JWT security mistakes · JWT security checklist · Debugging JWT signature errors · JWT attack types

Browse all tools