JWT Security Basics: What Can Go Wrong With JSON Web Tokens

JSON Web Tokens (JWTs) have become the default way modern APIs handle authentication. They're compact, self-contained, and don't require a server-side session store — but that same design makes a few common mistakes surprisingly dangerous.

Encoded, Not Encrypted

A JWT's header and payload are base64-encoded, not encrypted — anyone who gets hold of a token can decode and read its contents instantly, no key required. Only the signature is cryptographically protected. Never put a password, a secret, or sensitive personal data directly inside a token's claims.

The alg: none Attack

Some JWT libraries historically allowed a token to declare its signing algorithm as 'none,' meaning no signature verification happens at all. If a server naively trusts the algorithm the token itself claims, an attacker can forge a token with alg: none and have it accepted as valid.

Missing or Distant Expiry

A JWT without an exp (expiry) claim — or one set years in the future — stays valid indefinitely. If that token is ever leaked, it becomes a permanent, unrevokable key into the account it belongs to, since most JWT setups don't check a revocation list by default.

Weak Signing Secrets

Tokens signed with HMAC using a short or guessable secret can be brute-forced offline. Once an attacker recovers the secret, they can forge any token they want, for any user, with a valid signature the server will accept without complaint.

Decode a Token

Nexora Shield's JWT Decoder decodes any token instantly and flags these exact issues — running entirely in your browser, so the token itself is never sent anywhere.