5 JWT Security Mistakes That Can Compromise Your App
(And How to Fix Them)

This is the most common and most dangerous mistake. Many developers set their JWT secret key like this:

These keys are so simple that an attacker can guess them using a brute-force attack in just a few minutes. Once they have the secret key, they can generate any valid JWT token — fake admin tokens, fake user tokens, anything.

JWT_SECRET="secret"
JWT_SECRET="password123"
JWT_SECRET="test"

JWT_SECRET=k9#mP2@nQ8!xZ5&wR7
*vT1^yU6%sL4jD0bC3eF
# Min 256-bit, cryptographically
# random — see below

Always use a long, random, and cryptographically secure key — at least 256-bit (32 characters).

🔐 Visit jwtsecretkeygenerator.com and generate a completely secure random key with just one click. This tool was built specifically for this purpose.

This subtle but extremely dangerous vulnerability was discovered in 2015 and still exists in many applications today.

The JWT header contains an alg field that specifies the signing algorithm. If the server blindly trusts this field, an attacker can do the following:

Another variant — Algorithm Confusion Attack: If the server uses RS256 (asymmetric) and the attacker switches to HS256 (symmetric), the server treats the public key as a private key during verification. Since the public key is publicly available, the attacker can use it to sign valid tokens.

// No algorithm specified —
// accepts 'none' attack
const decoded = jwt.verify(
    token,
    process.env.JWT_SECRET
);

// Explicitly lock the algorithm
const decoded = jwt.verify(
    token,
    process.env.JWT_SECRET,
    { algorithms: ['HS256'] }
);

🛡️ With this one line, both the "none" algorithm attack and the algorithm confusion attack are automatically blocked.

The JWT payload is Base64-encoded — not encrypted. Anyone can decode it without a secret key. All it takes is a single command:

const token = jwt.sign({
    userId: user._id,
    password: user.password,    // ❌
    creditCard: user.creditCard, // ❌
    ssn: user.ssn,              // ❌
    apiKey: user.privateApiKey  // ❌
}, process.env.JWT_SECRET);

const token = jwt.sign({
    id: user._id,      // ✅ DB ID
    role: user.role,   // ✅ role
    email: user.email  // ✅ email
}, process.env.JWT_SECRET, {
    expiresIn: '15m'
});

💡 Rule of thumb: In the JWT payload, include only the data you need to access quickly with every request and whose public visibility won't cause any harm.

Many developers forget — or intentionally skip — setting an expiration time so that users don't have to log in repeatedly. This is a serious security flaw. If the token is stolen via XSS, network sniffing, or a leaked log file, the attacker can use it indefinitely.

const token = jwt.sign(
    { userId: user._id },
    process.env.JWT_SECRET
    // No expiresIn — lives forever!
);

// Short-lived access token
const accessToken = jwt.sign(
    { userId: user._id, role: user.role },
    process.env.JWT_ACCESS_SECRET,
    { expiresIn: '15m' }
);

// Longer-lived refresh token
const refreshToken = jwt.sign(
    { userId: user._id },
    process.env.JWT_REFRESH_SECRET,
    { expiresIn: '7d' }
);

⏱️ Best practice: Use short-lived access tokens (15 minutes) paired with long-lived refresh tokens (7 days). Even if an access token is stolen, it becomes useless within 15 minutes.

Generating a token securely matters — but where you store it is equally important. localStorage is one of the most common and most dangerous choices.

// Accessible by any JS — XSS steals it
localStorage.setItem('token', accessToken);

// Captured in history, logs, referrers
// https://app.com/dash?token=eyJhbGci...

res.cookie('accessToken', token, {
    httpOnly: true,   // JS cannot access
    secure: true,     // HTTPS only
    sameSite: 'Strict', // CSRF protection
    maxAge: 15 * 60 * 1000 // 15 min
});

🍪 HTTP-only cookies are not accessible by JavaScript. Even if an XSS vulnerability exists, the attacker cannot read or steal the token.