JWT Security

JSON Web Tokens (JWTs) are a widely used way to represent authentication and session data in modern APIs — but their flexibility is also where a lot of the vulnerabilities come from. Unlike a random opaque session ID, a JWT is a structured, often-inspectable piece of data, and small implementation mistakes can turn it into a serious authentication bypass.

Common JWT Vulnerabilities

• “alg: none” attacks — some JWT libraries historically allowed the token’s algorithm field to be set to none, meaning no signature verification happened at all. An attacker could forge any token they wanted.
• Algorithm confusion (RS256 to HS256) — if a server expects an RSA-signed token but doesn’t strictly enforce the algorithm, an attacker who knows the server’s public key can sometimes re-sign a token using it as an HMAC secret, forging a valid-looking signature.
• Weak signing secrets — an HMAC-signed JWT secured with a short or guessable secret can be brute-forced offline, letting an attacker forge tokens for any user.
• No expiration or improper expiration checks — tokens that never expire, or servers that fail to actually validate the exp claim, allowing stolen tokens to be used indefinitely.
• Sensitive data stored in the payload — JWT payloads are only base64-encoded, not encrypted, so anyone who intercepts a token can read its contents directly.

How Defenders Fix It

• Explicitly whitelist the expected algorithm on the server side — never trust the algorithm specified inside the token itself
• Use strong, sufficiently long signing secrets (or proper RSA/ECDSA key pairs for asymmetric signing)
• Always validate expiration and issuer/audience claims on every request, not just at login
• Never put sensitive data in the payload — treat it as visible information, not a secure container
• Keep signing libraries updated — most “alg: none” style bugs have been long since patched in modern libraries, but older or hand-rolled implementations remain at risk