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.
Related Articles
Was My Email Hacked? How to Check for Data Breaches (2026)
Find out if your email address was exposed in a data breach, what attackers actually do with it, and the exact steps to lock your accounts down today.
Privacy10 AI Scams to Watch For in 2026 (Real Cases + Fixes)
Deepfakes, cloned voices, AI phishing — real 2026 scam tactics explained with actual incidents, warning signs, and exactly how to protect yourself.
Phishing & MalwareI Clicked on a Phishing Link — What Should I Do? (Complete Recovery Guide 2026)
Accidentally clicked a phishing link? Learn exactly what to do if you entered your password, downloaded a file, or shared banking information. Step-by-step reco