ASVS 5.0 V6.8.2 requires that the presence and integrity of digital signatures on authentication assertions, such as JWTs and SAML assertions, are always validated. Unsigned assertions and assertions with invalid signatures must be rejected. It is a Level 2 requirement.
Why it matters
An assertion is a statement about who the user is. Without a verified signature, anyone can write one. Classic failures include JWTs with alg: none accepted, libraries that verify only when a signature is present, SAML responses where the signature covers a different element than the one the app reads, and code that decodes a token to read claims and never verifies it.
How to implement it
Pin the algorithm and key, verify before reading anything, and treat a missing signature as failure.
import jwt # PyJWT
def validate(token: str):
return jwt.decode(
token,
key=IDP_PUBLIC_KEY, # from configuration, not the token header
algorithms=["RS256"], # allow list, never "none"
audience="my-api",
issuer="https://idp.example.com/",
options={"require": ["exp", "iss", "aud", "sub"]},
)
// Node, jose library
import { jwtVerify, createRemoteJWKSet } from "jose";
const jwks = createRemoteJWKSet(new URL("https://idp.example.com/.well-known/jwks.json"));
const { payload } = await jwtVerify(token, jwks, {
issuer: "https://idp.example.com/",
audience: "my-api",
algorithms: ["RS256"],
});
For SAML, use a maintained library, require the response or assertion to be signed by the IdP certificate you configured, and read data only from the element that was verified. Reject documents with multiple assertions or unexpected structure to avoid signature wrapping.
Never use decode without verification for trust decisions. Keep your JWT and SAML libraries patched, because signature handling bugs are common in them.
How to test it
- Take a valid token, strip the signature, and send it. Expect rejection.
- Change the header to
alg: none, and also try switching RS256 to HS256 using the public key as the secret. Both must fail. - Alter one claim and keep the old signature. Must fail.
- For SAML, remove the signature, and then try wrapping attacks with a tool built for that purpose.
Common mistakes
- Reading the algorithm from the token header.
- Verifying only if a signature exists.
- Using a decode helper that skips verification.
- Outdated libraries with known bypasses.
Try it yourself
Check which JWT and SAML libraries your project uses and whether they carry known issues.
Click through it at your own pace, or open it full screen.
You can also run the free in-browser dependency scan at gold.safeguard.sh/scan.
Quick check
The token has no signature but valid claims. What should happen?
Reject it. A missing signature is a failure, not a pass.
Why must the verification key come from configuration?
If the token can name its own key or algorithm, an attacker can choose settings that make their forgery validate.