JSON Web Tokens (JWT)
JSON Web Tokens (JWTs) are a compact, URL-safe format for transmitting signed claims between parties, defined in RFC 7519. They consist of three Base64-encoded parts — header, payload, and signature — and are most commonly used for stateless authentication and session management in modern web and API applications. Their flexibility is also their biggest source of bugs.
JWT vulnerabilities typically come from flawed validation rather than from the spec itself. Servers that accept the "alg": "none" header skip signature verification entirely. Servers that accept multiple algorithms can be tricked into algorithm confusion attacks — for example, treating an RSA public key as an HMAC secret. The "kid" header has been a recurring source of SQL injection, path traversal, and arbitrary file read. Weak HMAC secrets fall to brute force in minutes with tools like jwt_tool. And even libraries that get the basics right have repeatedly shipped regressions that re-enable old attacks years later.
Storage and lifecycle introduce a second class of risk: tokens kept in localStorage are XSS-readable, refresh-token rotation is often skipped, and revocation is rarely implemented because JWTs are designed to be stateless. RFC 8725 ("JWT Best Current Practices") exists specifically because the original spec left too much room for unsafe defaults.
This page collects PortSwigger's JWT research and Web Security Academy labs, the major open-source testing tools (jwt_tool, jwt-pwn, jwtXploiter, c-jwt-cracker), CVE writeups, OWASP cheat sheets, and bug bounty methodologies for attacking JWT-based authentication.
From OWASP JWT Cheat Sheet
| Date Added | Link | Excerpt |
|---|---|---|
| 2026-04-10 NEW 2026 | PortSwigger KB: JWT none algorithm supported | PortSwigger KB: JWT none algorithm supported |
| 2026-04-10 NEW 2026 | Intigriti: Exploiting JWT vulnerabilities — advanced exploitation guide | Intigriti: Exploiting JWT vulnerabilities — advanced exploitation guide |
| 2026-04-10 NEW 2026 | Vaadata: JWT vulnerabilities, common attacks and security best practices | Vaadata: JWT vulnerabilities, common attacks and security best practices |
| 2026-04-10 NEW 2026 | WorkOS: JWT algorithm confusion attacks explained | WorkOS: JWT algorithm confusion attacks explained |
| 2026-04-10 NEW 2026 | PentesterLab: Another JWT Algorithm Confusion Vulnerability (CVE-2024-54150) | PentesterLab: Another JWT Algorithm Confusion Vulnerability (CVE-2024-54150) |
| 2026-04-10 NEW 2026 | Curity: JWT Security Best Practices | Curity: JWT Security Best Practices |
| 2026-04-10 NEW 2026 | RFC 8725: JSON Web Token Best Current Practices | RFC 8725: JSON Web Token Best Current Practices |
| 2026-04-10 NEW 2026 | Auth0: Critical vulnerabilities in JSON Web Token libraries | Auth0: Critical vulnerabilities in JSON Web Token libraries |
| 2026-04-10 NEW 2026 | OWASP WSTG: Testing JSON Web Tokens | OWASP WSTG: Testing JSON Web Tokens |
| 2026-04-10 NEW 2026 | OWASP JSON Web Token for Java Cheat Sheet | OWASP JSON Web Token for Java Cheat Sheet |
| 2026-04-10 NEW 2026 | KathanP19/HowToHunt: JWT | KathanP19/HowToHunt: JWT |
| 2026-04-10 NEW 2026 | tuhin1729 Bug Bounty Methodology: JWT | tuhin1729 Bug Bounty Methodology: JWT |
| 2026-04-10 NEW 2026 | HackTricks: JWT vulnerabilities | HackTricks: JWT vulnerabilities |
| 2026-04-10 NEW 2026 | PayloadsAllTheThings: JSON Web Token | PayloadsAllTheThings: JSON Web Token |
| 2026-04-10 NEW 2026 | DontPanicO/jwtXploiter: A tool to test the security of JSON Web Tokens | DontPanicO/jwtXploiter: A tool to test the security of JSON Web Tokens |
| 2026-04-10 NEW 2026 | brendan-rius/c-jwt-cracker: JWT brute-force cracker in C | brendan-rius/c-jwt-cracker: JWT brute-force cracker in C |
| 2026-04-10 NEW 2026 | mazen160/jwt-pwn: Security testing scripts for JWT | mazen160/jwt-pwn: Security testing scripts for JWT |
| 2026-04-10 NEW 2026 | jwt_tool Attack Methodology wiki | jwt_tool Attack Methodology wiki |
| 2026-04-10 NEW 2026 | ticarpi/jwt_tool: A toolkit for testing, tweaking and cracking JSON Web Tokens | ticarpi/jwt_tool: A toolkit for testing, tweaking and cracking JSON Web Tokens |
| 2026-04-10 NEW 2026 | Working with JWTs in Burp Suite | Working with JWTs in Burp Suite |
| 2026-04-10 NEW 2026 | JSON Web Token Attacker Burp extension | JSON Web Token Attacker Burp extension |
| 2026-04-10 NEW 2026 | JWT Scanner Burp extension | JWT Scanner Burp extension |
| 2026-04-10 NEW 2026 | PortSwigger jwt-editor: Burp Suite extension for editing and signing JWTs | PortSwigger jwt-editor: Burp Suite extension for editing and signing JWTs |
| 2026-04-10 NEW 2026 | Algorithm confusion attacks | Web Security Academy | Algorithm confusion attacks | Web Security Academy |
| 2026-04-10 NEW 2026 | JWT attacks | Web Security Academy | JWT attacks | Web Security Academy |
Frequently Asked Questions
- What is JWT algorithm confusion?
- Algorithm confusion (also called key confusion) exploits servers that accept multiple JWT signing algorithms. The classic example: a server expects an RS256 (asymmetric) signature but accepts HS256 (symmetric). An attacker switches the alg header to HS256 and signs the token using the server's RSA public key as the HMAC secret — turning a verification key into a signing key.
- What is the JWT "none" algorithm vulnerability?
- The JWT specification allows an alg value of "none", meaning the token is unsigned. Some libraries historically accepted this even for tokens that should have been verified, letting an attacker forge any payload. Modern libraries reject "none" by default, but the bug periodically resurfaces in custom implementations and lesser-used languages.
- Should I store JWTs in localStorage or cookies?
- Both have tradeoffs. localStorage is vulnerable to XSS — any script on the page can read the token. Cookies with HttpOnly, Secure, and SameSite=Strict prevent XSS theft but introduce CSRF risk if not handled. For most applications, HttpOnly cookies with proper CSRF defenses are the safer choice. Refresh-token rotation and short JWT lifetimes reduce the impact either way.
Weekly AppSec Digest
Get new resources delivered every Monday.