JWT Vulnerabilities: Algorithm Confusion, Weak Secrets, and Safe Validation

A JWT is not automatically insecure, and HS256 is not itself a vulnerability. JWT failures happen when an application accepts an unexpected algorithm, uses a weak signing key, skips signature or claim validation, trusts attacker-controlled key references, exposes bearer tokens, or lacks a workable expiration and revocation design.

Safe validation starts with policy established by the application: which token type, issuer, audience, algorithm, and key are expected. The token's own header and claims are untrusted input until cryptographic verification and claim validation both succeed.

RFC 8725, JSON Web Token Best Current Practices, is the primary reference for the validation rules below. Use a maintained library for your language and configure it explicitly; do not build a custom JWT verifier from this article.

What is an HS256 JWT vulnerability?

HS256 uses HMAC-SHA-256 with one shared secret for signing and verification. Correctly implemented HS256 remains a valid algorithm. The common vulnerabilities are:

1. A weak shared secret. A human-memorable password, default value, company name, or short key can be guessed offline from an observed token. RFC 7518 requires an HS256 key of at least 256 bits.
2. Algorithm or key confusion. A verifier intended for an asymmetric algorithm such as RS256 may incorrectly accept HS256 and treat an RSA public key as an HMAC secret.
3. Secret exposure. A strong key still fails if it is committed, logged, copied into support material, or made available to an untrusted workload.
4. Missing claim validation. A valid signature does not prove that the token is current, intended for this service, or issued by the expected authority.

Generate an HS256 key with a cryptographically secure random generator. Store and deliver it according to the environment-variable and secrets-management guide. If the signing secret may have leaked, rotate it and follow the environment-variable leak response workflow.

Algorithm confusion and alg: none

A JWT header contains an alg value, but the verifier must not let that untrusted value choose any algorithm the application happens to support.

Two documented failure modes are:

• accepting alg: none for a token that is required to be signed;
• accepting HS256 when the application expects RS256, then using public-key material as an HMAC secret.

RFC 8725 requires libraries and applications to verify that the received algorithm is one of the algorithms allowed for that specific use. Use separate validation rules for different token types and issuers. Do not mix symmetric and asymmetric algorithms in one permissive validation path.

Decoding is not validation

A compact JWT usually contains three Base64URL-encoded parts: header, payload, and signature. Anyone holding the token can decode the header and payload. Decoding can reveal formatting errors or registered time claims, but it does not establish:

• that the signature is valid;
• that the token came from the expected issuer;
• that the token is intended for this API;
• that the subject is authorized for the requested action;
• that the signing key is trusted.

Enforce cryptographic verification and the expected algorithm

Configure the verifier with the expected algorithm and trusted key source. Reject unsigned tokens and algorithms outside that allow-list. Validate every cryptographic operation and fail closed on malformed keys, unsupported parameters, or verification errors.

If the application retrieves public keys from a JWKS endpoint:

• configure trusted issuer and JWKS locations rather than accepting an arbitrary URL from jku or x5u;
• treat kid as an identifier, not a filesystem path, database query, or remote URL;
• restrict network access and redirects used for key retrieval;
• handle key rotation without temporarily accepting an untrusted key.

The JWT header is attacker-controlled until verification succeeds. It may help select among already trusted keys, but it must not expand the trust configuration.

Validate issuer, audience, time, and token type

Signature verification proves only that the token was signed by a holder of the verification key. The resource server must also validate the claims and context required by its policy:

• iss: exactly the expected issuer;
• aud: the service or resource for which the token was issued;
• exp: reject the token after expiration;
• nbf: reject the token before it becomes valid;
• token type or purpose: do not accept an ID token where an access token is required;
• subject and authorization data: validate them for the requested operation.

Allow only the small clock-skew tolerance your deployment needs. Do not trust a role, tenant, or resource identifier merely because it appears in a signed token; the authorization layer must still enforce the request against current policy.

RFC 8725 recommends explicit typing and mutually exclusive validation rules for different kinds of JWTs. This reduces cross-JWT confusion, where a valid token issued for one purpose is accepted in another security context.

Keep bearer tokens and signing keys out of exposure paths

A signed JWT is normally not encrypted. Do not place passwords, private keys, or unnecessary personal data in its payload. Anyone who obtains the token may be able to read those claims.

Treat bearer access tokens as credentials:

• send them only over TLS;
• keep them out of URLs, logs, analytics events, error reports, and support material;
• avoid exposing signing keys to frontend code or untrusted CI jobs;
• scope access tokens to the minimum audience and privileges;
• choose lifetimes based on the threat model and recovery design.

For higher-risk OAuth deployments, RFC 9700 recommends audience restriction and sender-constrained access tokens where feasible. It also requires public clients that receive refresh tokens to use sender-constrained refresh tokens or refresh-token rotation.

Plan expiration, logout, and compromise response

JWT signatures do not create an automatic logout or revocation mechanism. A deployment can use short-lived access tokens with stateful refresh-token controls, server-side session state, a denylist for selected identifiers, signing-key rotation, or a combination appropriate to its risk and scale.

The correct choice depends on how quickly access must end after logout, account disablement, privilege change, or key compromise. Do not advertise “stateless authentication” while leaving the system unable to terminate stolen access.

For standards-based revocation and refresh-token design, read OAuth Token Revocation, Introspection, and Rotation.

JWT validation checklist

• [ ] The expected issuer, audience, token type, algorithm, and trusted key source are configured outside the token.
• [ ] Unsigned tokens and algorithms outside the allow-list are rejected.
• [ ] Symmetric and asymmetric algorithms do not share a permissive validation path.
• [ ] HS256 keys contain at least 256 bits of cryptographically secure random material.
• [ ] Signature verification completes before any header or claim affects authorization.
• [ ] iss, aud, exp, nbf, and application-required claims are validated.
• [ ] ID tokens, access tokens, refresh tokens, and internal JWTs use mutually exclusive rules.
• [ ] kid, jku, x5u, and other key-selection inputs cannot escape trusted configuration.
• [ ] JWT payloads contain no secrets and only necessary personal data.
• [ ] Tokens and signing keys stay out of URLs, logs, analytics, and support artifacts.
• [ ] Access-token lifetime, refresh-token replay detection, logout, and compromise response are documented and tested.
• [ ] Authorization checks current resource, tenant, and privilege rules after token validation.

The safest mental model is simple: a decoded JWT is untrusted data; a correctly verified JWT is authenticated data; authorization still requires separate policy checks.

Primary guidance

• RFC 8725: JSON Web Token Best Current Practices
• RFC 7518: JSON Web Algorithms
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• OWASP JSON Web Token Cheat Sheet