APIs & Authentication

July 17, 2026 · 2 min read

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.

Common JWT mistakes

Trusting the `alg` field inside the token itself to decide how to verify it. A malicious client can change `alg` to `none` or downgrade `RS256` to `HS256` and, if the server naively trusts the header, forge a completely valid-looking token. The verification algorithm should always be hardcoded server-side, never read from the token being verified.

Storing a JWT in `localStorage` for convenience. Unlike an HttpOnly cookie, anything in `localStorage` is readable by any JavaScript running on the page — meaning a single XSS vulnerability anywhere on the site can exfiltrate every logged-in user's token directly.

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.

Frequently Asked Questions

Is it safe to put a user's email address inside a JWT payload?

It's common practice for non-sensitive identifiers, but remember the payload is only base64-encoded, not encrypted — anyone holding the token can read it, so never include passwords or sensitive personal data.

How long should a JWT's expiry be set to?

Short-lived access tokens (minutes to a couple of hours) paired with a separate, revocable refresh token is the standard pattern — a long-lived JWT with no revocation mechanism becomes a permanent risk if leaked.

JWT Decoder

Decodes any token instantly and flags common issues, entirely in your browser.

Try the JWT Decoder

Related Articles