A JWT is not safe just because it is signed. It is only as safe as the checks the receiving API performs on every request. Here, five common beliefs about JWTs in APIs are checked against RFC 8725 and OWASP guidance, with a fix for each.
Myth 1: the token header tells the server how to verify it
Fact. The header is supplied by whoever sends the token. The OWASP REST cheat sheet says to pick the verification algorithm from your own configuration, not the token header. RFC 8725 section 3.1 says libraries should let callers specify allowed algorithms and that each key should be used with exactly one algorithm.
Myth 2: the none algorithm is a harmless option
Fact. An unsigned token proves nothing about who made it. RFC 8725 section 3.2 says none is acceptable only when another layer protects the JWT, and libraries should not produce or consume unsigned tokens unless explicitly asked. OWASP's authentication entry lists accepting unsigned JWTs as a sign an API is vulnerable. For an API, reject them.
Myth 3: a valid signature means the token is valid for us
Fact. Signature is one check. The RFC also says to validate issuer and subject (3.8) and audience (3.9). The OWASP cheat sheet says to validate iss, aud and exp by default. A token meant for another service can carry a perfectly good signature.
Myth 4: a short secret is fine for HS256
Fact. Section 3.5 says not to use human-memorable passwords directly as HMAC keys. If the key can be guessed, an attacker can mint tokens offline and your API will accept them.
Myth 5: stateless means you cannot revoke
Fact. It is harder, not impossible. The OWASP cheat sheet suggests a jti denylist to handle early session termination. Short lifetimes keep the list small. Statelessness is a trade-off you choose, not a law.
Bonus: where header values lead
RFC 8725 section 3.10 says not to trust received claims. Sanitize kid values to prevent injection, and guard against SSRF from jku and x5u URLs, for example with an allow-list. A library that fetches keys from a URL inside the token is following an attacker's instruction.
What this means for your code
- Configure allowed algorithms explicitly.
- Reject unsigned tokens.
- Check issuer, audience and expiry every time.
- Use strong keys, rotated on a schedule you control.
- Use a maintained library and keep it patched.
The full list is in the JWT validation checklist.
Quick check
Is JWT encryption the same as signing?
No. Signing proves who issued a token and that it was not altered. Encryption hides the contents. A signed token is readable by anyone who holds it, so do not put secrets in it.
Are JWTs always the right choice?
Not always. Opaque tokens checked against the issuer are simpler to revoke. Pick based on your revocation and scale needs.
If a JWT library you depend on has a published advisory, Safeguard's dependency scanning can flag it, and the free scan at gold.safeguard.sh/scan is a quick way to look.
Sources
- RFC 8725 JSON Web Token Best Current Practices
- OWASP REST Security Cheat Sheet
- OWASP API2:2023 Broken Authentication
Last reviewed: 19 October 2026.
