JSON Web Tokens are everywhere in modern web and mobile applications, used for everything from session management to API authentication. They're also one of the most consistently misimplemented pieces of security infrastructure on the internet, which is exactly why "JWT attacks" remains one of the most requested topics from bug bounty hunters at every level.
What a JWT Actually Is
A JWT is three Base64-encoded segments separated by dots: a header describing the token type and signing algorithm, a payload containing claims (user ID, role, expiry), and a signature that proves the header and payload haven't been tampered with. The entire security model rests on one assumption: that only the server can produce a valid signature.
The "alg: none" Problem
Early JWT libraries supported an "none" algorithm for testing purposes, meaning a token could declare it isn't signed at all. Some server-side implementations, when parsing a token, trusted whatever algorithm the token itself claimed rather than enforcing the algorithm the server expected. That meant an attacker could take a legitimate token, change the header to say "alg": "none", strip the signature entirely, modify the payload to claim to be a different user or a higher privilege role, and have some vulnerable servers accept it without ever checking a signature at all. Most modern libraries have patched this by default, but it still surfaces in older codebases and custom implementations that rolled their own JWT handling.
Algorithm Confusion: RS256 to HS256
A more subtle and still very much alive attack targets applications using asymmetric signing (RS256), where the server has a private key for signing and a public key for verifying. If the server's verification code doesn't strictly enforce which algorithm family a token must use, an attacker can craft a token using HS256 (a symmetric algorithm) and sign it using the server's public key as the HMAC secret. Since the public key is, by definition, public, an attacker can obtain it and use it to forge a validly-signed token — because the server ends up checking the signature using the same public key value, just under the wrong algorithm's rules.
Weak Secrets
For applications using symmetric signing (HS256) from the start, the entire security model depends on the signing secret staying private and being sufficiently random. Short, guessable, or default secrets can be brute-forced offline once an attacker has a single valid token to test guesses against — no interaction with the live server required until the very last step of using the forged token.
What This Means in Practice
When testing an application using JWTs, the questions worth asking are: does the server strictly pin the expected algorithm rather than trusting the token's own header, is the signing secret something that could be brute-forced or guessed, and are expiry and revocation actually enforced server-side or does the application just trust whatever the token payload claims. None of these require exotic tooling — they require understanding what the token format actually promises versus what a specific implementation actually checks.
Practicing This Safely
Genesis Vault's JWT Algorithm Confusion lab walks through exactly this scenario in a sandboxed, intentionally vulnerable environment — a safe place to see the full attack chain from a normal user token to a forged admin one, without touching a real system.