Misreading #1: Believing the Token Knows Best
One of the most classic and devastating JWT blunders is trusting the token’s header to tell you how to validate it. Specifically, we’re talking about the `alg` (algorithm) parameter. A JWT can declare in its own header that its signing algorithm is 'none'.
An attacker can grab a real token, change the payload to make themselves an admin, set the `alg` field to 'none', and then simply delete the signature. If the server is lazily coded to accept whatever algorithm the token suggests, it will see `alg:none` and conclude, "Oh, I guess I don't need to check a signature for this one!". Just like that, the attacker walks through the front door. The fix is simple but crucial: your server should never ask the token how it should be validated. It should be hardcoded to expect a specific, strong algorithm (like RS256) and reject any token that doesn’t comply.
Misreading #2: Confusing Public Keys with Secret Keys
This pitfall is more subtle but just as dangerous. It involves the confusion between symmetric (HS256) and asymmetric (RS256) signing algorithms. With HS256, the same secret key is used to both sign and verify the token. With RS256, you use a private key to sign and a public key to verify. The public key, as the name implies, can be shared. The vulnerability arises when a server is configured to accept tokens signed with either algorithm. An attacker can take a token that is supposed to be signed with RS256, modify its header to say it was signed with HS256, and then sign the token using the publicly available RS256 public key as the secret. When the server receives this forged token, it sees `alg:HS256` and obediently verifies it using the HS256 method, for which the "secret" is the public key it already knows. It validates perfectly, and the attacker gains unauthorized access. Again, the solution is to be strict: explicitly configure your server to accept only one specific algorithm.
Misreading #3: Thinking Encoded Means Encrypted
This is perhaps the most common misunderstanding among developers new to JWTs. A standard JWT is not encrypted; its payload is merely encoded with Base64Url. Encoding is not a security feature. It's a way to ensure the data can be safely transmitted. Anyone who gets their hands on a JWT can pop it into a decoder and read the payload in plain text. Despite this, teams frequently make the mistake of storing sensitive information—email addresses, internal user IDs, or detailed permissions—directly in the payload. If that token is ever leaked, through logs, a browser vulnerability, or insecure transmission, all that data is exposed. Think of a JWT like a postcard: the signature proves it came from the right person and wasn't altered in transit, but anyone who handles the mail can read the message. The rule is simple: if you wouldn't feel comfortable writing the data on a postcard, don't put it in a standard JWT payload.
Misreading #4: Using a Weak or Obvious Secret
When using a symmetric algorithm like HS256, the entire security of the system rests on a single secret key. A weak secret is like leaving your house key under the doormat. Attackers can use brute-force attacks with lists of common passwords (like 'secret', 'password123', or the company name) to guess the key. If they succeed, they can forge any token with any payload they want. Another common mistake is hardcoding the secret directly into the application's source code. If the code is ever leaked or accessed by a malicious actor, the keys to the kingdom are handed over. JWT secrets should be long, random, and complex, generated by a secure process. They must be stored securely in environment variables or a dedicated secrets management service, and they should be rotated periodically to limit the potential damage if one is ever compromised.
