JSON Web Tokens (JWTs) carry identity and permissions between a client and an API. They are signed, not encrypted, and their security depends entirely on how the server validates them. Small validation mistakes let an attacker forge a token and become any user.

How it happens

Common mistakes include accepting the none algorithm (no signature at all), accepting weak algorithms, confusing public-key and shared-secret algorithms, and trusting header fields like jku or kid that tell the server where to find the key. Each one lets an attacker craft a token the server accepts.

Why it matters

• Impersonation of any user, including administrators.
• Bypass of authorization rules encoded in token claims.
• Long-lived access if tokens never expire.

How to prevent it

• Pin the expected algorithm on the server; never read it from the token.
• Reject none and weak algorithms.
• Do not fetch keys from URLs or paths supplied in the token header.
• Keep token lifetimes short and validate exp, aud and iss.

How Vooki Pro helps

• Tests for the none algorithm, weak algorithms, algorithm confusion, and jku and kid header abuse.
• Checks session handling, including token expiry, session fixation and tokens in URLs.
• Uses auth profiles to scan APIs as a logged-in user, with automatic re-login.
• Maps findings to OWASP Top 10 and NIST 800-53 in compliance reports.

Frequently asked questions

What is the JWT alg none vulnerability?

Some libraries accept tokens that declare the algorithm "none", meaning no signature. An attacker can then forge any token the server will accept.

How should I validate a JWT?

Pin the expected algorithm on the server, verify the signature with a trusted key, and check exp, aud and iss on every request.

Related: Cross-site request forgery (CSRF) · Insecure deserialization