JWT Vulnerability Testing
JWT vulnerabilities allow forging tokens to impersonate other users or escalate privileges without valid credentials. Common weaknesses include accepting the none algorithm, algorithm confusion between RS256 and HS256, weak secrets that can be cracked, and injection in the kid header parameter. Collect a valid token first — from login, a cookie, or an Authorization header — then probe it. Confirmed weaknesses move to JWT exploitation.
Decode and Inspect the Token
Before testing, decode the token to understand its structure and claims:
{
"alg": "HS256",
"typ": "JWT"
}
{
"user": "admin",
"role": "user"
}
None Algorithm Test
Some libraries accept tokens with alg: none and no signature. Create a modified token and test acceptance:
Algorithm Confusion — RS256 to HS256
When the server uses RS256, the public key is sometimes accessible. If the library can be tricked into verifying an HS256 token using the public key as the HMAC secret, you can forge tokens with the public key:
Weak Secret Brute Force
HS256 tokens signed with a weak secret can be cracked offline. Save the full token and attack the signature:
eyJhbGci...:secret123
A cracked secret allows forging arbitrary tokens. Modify the role or user claim and resign with the recovered secret.
kid Header Injection
The kid header points to the key used for verification. Injecting a path traversal or SQL payload into kid can cause the server to use an attacker-controlled key or execute SQL:
References
-
JWT testing tool supporting algorithm confusion, none algorithm, and secret cracking
-
PortSwigger — JWT Attacksportswigger.net/web-security/jwt (opens in new tab)
JWT vulnerability types and exploitation methodology
Was this helpful?
Your feedback helps improve this page.