🔐security

JWT Security: The Mistakes That Get Apps Hacked and How to Avoid Them

JWTs are everywhere and frequently misconfigured. Here are the most common JWT security mistakes developers make and exactly how to fix them.

8 min readJanuary 15, 2026By FreeToolKit TeamFree to read

JSON Web Tokens are used in nearly every modern web application for authentication. They're also one of the most frequently misconfigured pieces of security infrastructure. Most of the mistakes aren't exotic — they're straightforward misunderstandings that show up repeatedly across codebases.

Mistake 1: Accepting the 'none' algorithm

Early JWT libraries accepted a token signed with algorithm 'none' as valid — meaning an attacker could forge a token for any user by simply claiming the algorithm was 'none' and providing no signature. This is a classic vulnerability. Fix: explicitly whitelist the algorithms your application accepts. Never accept 'none'.

Mistake 2: Weak or hardcoded secrets

HMAC-SHA256 tokens are only as secure as the secret key. A weak secret (short, predictable, reused across environments) can be brute-forced or guessed. A hardcoded secret that ends up in a public GitHub repository is compromised the moment it's pushed. Fix: use a cryptographically random secret of at least 256 bits, store it in an environment variable, and rotate it if it's ever exposed.

Mistake 3: Missing expiration

A token without an expiration time (`exp` claim) is valid forever. If a token is stolen — from a XSS attack, a database breach, or a user's device — the attacker has permanent access. Fix: always set a short `exp`. For access tokens, 15 minutes to 1 hour is typical. Use refresh tokens for longer sessions.

Mistake 4: Sensitive data in the payload

JWTs are encoded, not encrypted by default. The payload is Base64-decoded by anyone who has the token — including the user, any intermediate proxies, and your logging infrastructure. Never put passwords, SSNs, credit card data, or anything that would be harmful if disclosed in a JWT payload. Use the token to reference a user ID, not to carry their data.

Mistake 5: Storing tokens in localStorage

localStorage is accessible to any JavaScript running on your page. If your site has a XSS vulnerability, attackers can steal tokens from localStorage trivially. HTTPOnly cookies are immune to JavaScript access. Store JWTs in HTTPOnly, Secure, SameSite=Strict cookies where possible.

Mistake 6: Not validating the signature

Sounds obvious, but some implementations decode the token without verifying the signature. The signature is what proves the token was issued by your server and hasn't been tampered with. Always verify.

Security checklist

Before shipping JWT auth: whitelist algorithms, use a strong random secret, set exp, use HTTPOnly cookies, verify signatures on every request, and test with a deliberately invalid token to confirm rejection.

🔧 Free Tools Used in This Guide

FT

FreeToolKit Team

FreeToolKit Team

We build free browser tools and write about the tools developers actually use.

Tags:

jwtsecurityauthenticationweb development