JWTs and similar tokens carry their own claims; if their signature, algorithm, key source, validity period or audience is not checked, anyone can mint or replay them.
- Validate the signature or MAC before using any claim, against an allowlist of algorithms.
- Accept keys only from trusted, preconfigured sources.
- Check the validity period, the token type and the intended audience.
Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-9.1.1.
V9.1 Token source and integrity · 3 requirements
V9.1.1 Level 1
Verify that self-contained tokens are validated using their digital signature or MAC to protect against tampering before accepting the token's contents.
On this site: JWT validation: algorithms, keys, claims and key rollover (guide) · JWT validation in APIs (bearer tokens) (fix card)
V9.1.2 Level 1
Verify that only algorithms on an allowlist can be used to create and verify self-contained tokens, for a given context. The allowlist must include the permitted algorithms, ideally only either symmetric or asymmetric algorithms, and must not include the 'None' algorithm. If both symmetric and asymmetric must be supported, additional controls will be needed to prevent key confusion.
On this site: JWT validation: algorithms, keys, claims and key rollover (guide) · JWT validation in APIs (bearer tokens) (fix card)
V9.1.3 Level 1
Verify that key material that is used to validate self-contained tokens is from trusted pre-configured sources for the token issuer, preventing attackers from specifying untrusted sources and keys. For JWTs and other JWS structures, headers such as 'jku', 'x5u', and 'jwk' must be validated against an allowlist of trusted sources.
On this site: JWT validation: algorithms, keys, claims and key rollover (guide) · Case study: Storm-0558 and the forged Microsoft tokens (2023) (guide) · JWT validation in APIs (bearer tokens) (fix card)
V9.2 Token content · 4 requirements
V9.2.1 Level 1
Verify that, if a validity time span is present in the token data, the token and its content are accepted only if the verification time is within this validity time span. For example, for JWTs, the claims 'nbf' and 'exp' must be verified.
On this site: JWT validation: algorithms, keys, claims and key rollover (guide) · JWT validation in APIs (bearer tokens) (fix card)
V9.2.2 Level 2
Verify that the service receiving a token validates the token to be the correct type and is meant for the intended purpose before accepting the token's contents. For example, only access tokens can be accepted for authorization decisions and only ID Tokens can be used for proving user authentication.
On this site: JWT validation: algorithms, keys, claims and key rollover (guide)
V9.2.3 Level 2
Verify that the service only accepts tokens which are intended for use with that service (audience). For JWTs, this can be achieved by validating the 'aud' claim against an allowlist defined in the service.
On this site: JWT validation: algorithms, keys, claims and key rollover (guide) · JWT validation in APIs (bearer tokens) (fix card)
V9.2.4 Level 2
Verify that, if a token issuer uses the same private key for issuing tokens to different audiences, the issued tokens contain an audience restriction that uniquely identifies the intended audiences. This will prevent a token from being reused with an unintended audience. If the audience identifier is dynamically provisioned, the token issuer must validate these audiences in order to make sure that they do not result in audience impersonation.
Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.
Guides on this site
JWT validation: algorithms, keys, claims and key rollover
Validate a JWT against a fixed algorithm, trusted keys and the expected issuer, audience and type, reject the known header attacks, and rotate signing keys without accepting arbitrary keys or breaking valid tokens.
OAuth 2.0 and OpenID Connect login: authorization code with PKCE
Implement OAuth 2.0 and OpenID Connect login with the authorization code flow and PKCE, keep each transaction bound to its browser, and block redirect, mix-up, code-injection and token-theft attacks.
Practice
- JWT validation lab: Validate the purpose and audience of a token · Browser lab
- JWT verification lab: Verify a JWT before trusting it · Browser lab
- OAuth redirect and PKCE lab: Match redirect URIs and verify PKCE · Browser lab
- Secure a real HTTP API · Local project
- Verify tokens through rotation and revocation · Local project
References
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.