RandomKeygen

Common JWT Implementation Mistakes

Learn from the most dangerous JWT implementation mistakes that developers make. Avoid critical security vulnerabilities and protect your applications with proper JWT practices.

🚨

Critical Security Alert

JWT implementation errors are among the most common causes of authentication bypass attacks. Even a small mistake can expose your entire user base to attackers.

73%
of JWT vulnerabilities are preventable
$4.45M
average cost of a data breach
287 days
average time to identify breach

🚨 Critical Security Mistakes

🚨 Using Weak or Predictable Secrets

critical

Many developers use simple, short, or predictable secrets for signing JWTs. This makes tokens trivially easy to forge.

❌ Wrong Implementation

// ❌ NEVER do this
const secret = 'secret';
const secret = 'myapp';
const secret = '123456';
const secret = 'your-secret-key'; // Default examples

const token = jwt.sign(payload, secret);

✅ Correct Implementation

// ✅ Always do this
const crypto = require('crypto');
const secret = process.env.JWT_SECRET || 
  crypto.randomBytes(64).toString('hex');

// Minimum 256-bit (32 bytes) entropy
if (secret.length < 32) {
  throw new Error('JWT secret too weak');
}

const token = jwt.sign(payload, secret);

💥 Security Impact

Attackers can forge any JWT token, impersonate any user, and gain complete access to your application. This is a complete authentication bypass.

🛠️ How to Fix

  • • Generate secrets with at least 256 bits of entropy
  • • Use cryptographically secure random generators
  • • Store secrets in environment variables, never in code
  • • Use different secrets for different environments
  • • Rotate secrets regularly

🚨 Algorithm Confusion Attacks

critical

Not specifying or validating the signing algorithm allows attackers to change the algorithm and bypass security.

❌ Wrong Implementation

// ❌ Accepts any algorithm
jwt.verify(token, publicKey);

// ❌ Vulnerable to 'none' algorithm
jwt.verify(token, secret, { algorithms: ['HS256', 'none'] });

// ❌ Using public key for HMAC
jwt.verify(token, publicKey, { algorithms: ['HS256', 'RS256'] });

✅ Correct Implementation

// ✅ Always specify expected algorithm
jwt.verify(token, secret, { algorithms: ['HS256'] });

// ✅ For RSA keys, only allow RS algorithms
jwt.verify(token, publicKey, { algorithms: ['RS256'] });

// ✅ Never allow 'none' algorithm in production
const allowedAlgorithms = process.env.NODE_ENV === 'test' 
  ? ['HS256', 'none'] : ['HS256'];

💥 Security Impact

Complete authentication bypass. Attackers can create tokens with no signature or trick servers into using public keys as HMAC secrets.

🛠️ How to Fix

  • • Always specify the algorithms parameter
  • • Never include 'none' in production algorithms
  • • Use different validation for symmetric vs asymmetric keys
  • • Validate algorithm in JWT header matches expectation
  • • Implement algorithm allowlist, not blocklist

🚨 Storing Sensitive Data in JWTs

critical

JWTs are encoded (base64), not encrypted. Any sensitive data in the payload is visible to anyone who has the token.

❌ Wrong Implementation

// ❌ NEVER put sensitive data in JWTs
const payload = {
  userId: 123,
  password: 'user-password',        // Visible to anyone!
  ssn: '123-45-6789',              // Major privacy violation
  creditCard: '1234-5678-9012-3456', // Financial data exposed
  apiSecret: 'internal-api-key',    // Internal secrets leaked
  email: '[email protected]',
  role: 'admin'
};

✅ Correct Implementation

// ✅ Only include non-sensitive, verifiable data
const payload = {
  sub: 'user123',           // User identifier (non-sequential)
  username: 'johndoe',      // Public information
  role: 'admin',           // Authorization info
  iat: Math.floor(Date.now() / 1000),
  exp: Math.floor(Date.now() / 1000) + (60 * 15), // 15 min
  jti: randomUUID()        // Token ID for revocation
};

// Store sensitive data server-side, reference by user ID

💥 Security Impact

Immediate exposure of passwords, personal data, and internal secrets to anyone with token access. Massive privacy violations and regulatory compliance issues.

🛠️ How to Fix

  • • Never include passwords or password hashes
  • • Don't put SSN, PII, or financial data in tokens
  • • Avoid API keys or internal secrets
  • • Use non-sequential user IDs
  • • Keep payload minimal - only authorization data
  • • Encrypt JWTs if sensitive data is required (JWE)

🚨 Ignoring Token Expiration

critical

Not setting expiration times or not validating them properly allows tokens to live forever, dramatically increasing attack windows.

❌ Wrong Implementation

// ❌ No expiration set
const token = jwt.sign(payload, secret);

// ❌ Not validating expiration
const decoded = jwt.decode(token); // Doesn't verify!
console.log(decoded.userId);

// ❌ Extremely long expiration
const token = jwt.sign(payload, secret, { 
  expiresIn: '10y' // 10 years!
});

✅ Correct Implementation

// ✅ Always set appropriate expiration
const accessToken = jwt.sign(payload, secret, { 
  expiresIn: '15m'  // 15 minutes for access tokens
});

const refreshToken = jwt.sign(refreshPayload, secret, {
  expiresIn: '7d'   // 7 days for refresh tokens
});

// ✅ Always verify, which includes expiration check
try {
  const decoded = jwt.verify(token, secret, {
    algorithms: ['HS256']
  });
  // Token is valid and not expired
} catch (error) {
  // Handle expired or invalid token
  return res.status(401).json({ error: 'Token invalid' });
}

💥 Security Impact

Stolen tokens remain valid indefinitely. Account takeovers persist even after users change passwords or administrators detect breaches.

🛠️ How to Fix

  • • Set short expirations (15-60 minutes) for access tokens
  • • Use refresh tokens for longer sessions
  • • Always use jwt.verify(), never jwt.decode() for auth
  • • Implement token refresh flow
  • • Consider JTI-based token revocation for immediate invalidation

⚠️ High-Risk Implementation Errors

⚠️ Insecure Token Storage

high

Storing JWTs in localStorage or other client-side storage vulnerable to XSS attacks.

❌ Wrong Implementation

// ❌ Vulnerable to XSS attacks
localStorage.setItem('jwt', token);
sessionStorage.setItem('jwt', token);

// ❌ Accessible to malicious scripts
document.cookie = `jwt=${token}`;

// ❌ In URL parameters - logged everywhere
window.location = `/dashboard?token=${token}`;

✅ Correct Implementation

// ✅ Secure httpOnly cookie (preferred)
res.cookie('jwt', token, {
  httpOnly: true,     // Not accessible to JavaScript
  secure: true,       // HTTPS only
  sameSite: 'strict', // CSRF protection
  maxAge: 15 * 60 * 1000 // 15 minutes
});

// ✅ Authorization header (for SPAs)
fetch('/api/data', {
  headers: {
    'Authorization': `Bearer ${token}`
  }
});

// ✅ Store in memory only (most secure for SPAs)
let authToken = null; // In-memory storage

💥 Security Impact

XSS attacks can steal tokens and impersonate users. Tokens exposed in logs, referrer headers, and browser history.

🛠️ How to Fix

  • • Use httpOnly, secure, sameSite cookies when possible
  • • For SPAs, store tokens in memory, not localStorage
  • • Implement token refresh flow for short-lived tokens
  • • Never include tokens in URLs
  • • Use CSP headers to prevent XSS

⚠️ Missing HTTPS/TLS Protection

high

Transmitting JWTs over unencrypted HTTP connections exposes tokens to interception.

❌ Wrong Implementation

// ❌ HTTP transmission exposes tokens
fetch('http://api.example.com/login', {
  method: 'POST',
  headers: {
    'Authorization': `Bearer ${token}`
  }
});

// ❌ Mixed content vulnerabilities
const API_URL = 'http://api.example.com'; // HTTP API
const FRONTEND_URL = 'https://app.example.com'; // HTTPS frontend

✅ Correct Implementation

// ✅ Always enforce HTTPS
const API_URL = 'https://api.example.com';

// ✅ HSTS headers
app.use((req, res, next) => {
  res.setHeader(
    'Strict-Transport-Security',
    'max-age=31536000; includeSubDomains; preload'
  );
  next();
});

// ✅ Redirect HTTP to HTTPS
app.use((req, res, next) => {
  if (req.header('x-forwarded-proto') !== 'https') {
    return res.redirect(`https://${req.header('host')}${req.url}`);
  }
  next();
});

💥 Security Impact

Man-in-the-middle attacks can intercept tokens. Complete authentication bypass over insecure networks.

🛠️ How to Fix

  • • Enforce HTTPS in production everywhere
  • • Set HSTS headers with long max-age
  • • Use secure cookie flags
  • • Implement certificate pinning for mobile apps
  • • Monitor for mixed content warnings

⚠️ Insufficient Token Validation

high

Not validating all required claims or accepting tokens from unexpected sources.

❌ Wrong Implementation

// ❌ Minimal validation
const decoded = jwt.verify(token, secret);
const userId = decoded.sub; // Trusting without validation

// ❌ Not checking issuer/audience
// Accepts tokens from any issuer

// ❌ Not validating custom claims
if (decoded.role === 'admin') {
  // Allowing any role claim without verification
}

✅ Correct Implementation

// ✅ Comprehensive validation
const decoded = jwt.verify(token, secret, {
  algorithms: ['HS256'],
  issuer: 'your-app.com',
  audience: 'api.your-app.com',
  maxAge: '15m'
});

// ✅ Validate required claims
if (!decoded.sub || !decoded.role) {
  throw new Error('Missing required claims');
}

// ✅ Validate claim values
const allowedRoles = ['user', 'admin', 'moderator'];
if (!allowedRoles.includes(decoded.role)) {
  throw new Error('Invalid role claim');
}

// ✅ Additional security checks
if (decoded.role === 'admin' && !isFromTrustedIP(req.ip)) {
  throw new Error('Admin access from untrusted location');
}

💥 Security Impact

Token confusion attacks, privilege escalation, and acceptance of malicious tokens from other applications.

🛠️ How to Fix

  • • Validate issuer (iss) and audience (aud) claims
  • • Check all required claims are present
  • • Validate claim values against allowlists
  • • Implement additional context validation
  • • Log and monitor validation failures

⚠️ No Token Revocation Strategy

high

Once issued, JWTs cannot be revoked without additional infrastructure, making it impossible to immediately invalidate compromised tokens.

❌ Wrong Implementation

// ❌ No way to revoke tokens
app.post('/logout', (req, res) => {
  // JWT tokens remain valid until expiration
  res.json({ message: 'Logged out' });
});

// ❌ Compromised account with no immediate remedy
app.post('/change-password', async (req, res) => {
  await updatePassword(userId, newPassword);
  // Old JWT tokens still work!
  res.json({ message: 'Password changed' });
});

✅ Correct Implementation

// ✅ Implement token blacklist
const blacklistedTokens = new Set(); // Or use Redis

app.post('/logout', authenticateToken, (req, res) => {
  blacklistedTokens.add(req.token.jti); // Blacklist by JWT ID
  res.json({ message: 'Logged out successfully' });
});

// ✅ Check blacklist on each request
function authenticateToken(req, res, next) {
  const token = extractToken(req);
  const decoded = jwt.verify(token, secret);
  
  if (blacklistedTokens.has(decoded.jti)) {
    return res.status(401).json({ error: 'Token revoked' });
  }
  
  req.user = decoded;
  next();
}

// ✅ Implement refresh token rotation
app.post('/refresh', (req, res) => {
  const refreshToken = req.body.refreshToken;
  // Validate refresh token and issue new access token
  // Invalidate old refresh token (rotation)
});

💥 Security Impact

Unable to immediately invalidate compromised tokens. Logout doesn't actually log users out. Security incidents persist until token expiration.

🛠️ How to Fix

  • • Implement JWT ID (jti) based blacklisting
  • • Use Redis or database for scalable blacklist storage
  • • Implement refresh token rotation
  • • Consider short-lived tokens with refresh flow
  • • Provide emergency token revocation endpoints

⚡ Common Implementation Pitfalls

⚡ Clock Skew and Timing Issues

medium

Not accounting for clock differences between servers can cause valid tokens to be rejected or invalid tokens to be accepted.

❌ Wrong Implementation

// ❌ Strict timestamp validation
const decoded = jwt.verify(token, secret);
if (decoded.iat > Date.now() / 1000) {
  throw new Error('Token from future');
}

// ❌ No clock skew tolerance
if (decoded.nbf && decoded.nbf > Date.now() / 1000) {
  throw new Error('Token not yet valid');
}

✅ Correct Implementation

// ✅ Allow for clock skew
const clockSkew = 60; // 60 seconds tolerance

const decoded = jwt.verify(token, secret, {
  algorithms: ['HS256'],
  clockTolerance: clockSkew
});

// ✅ Manual validation with tolerance
const now = Math.floor(Date.now() / 1000);
if (decoded.nbf && (decoded.nbf - clockSkew) > now) {
  throw new Error('Token not yet valid');
}

// ✅ Server time synchronization
// Ensure all servers use NTP for time sync

💥 Security Impact

Legitimate users get randomly rejected due to server clock differences. Valid tokens may be incorrectly accepted.

🛠️ How to Fix

  • • Set clockTolerance in JWT libraries (30-60 seconds)
  • • Synchronize server clocks with NTP
  • • Monitor time drift between servers
  • • Use UTC for all timestamp calculations
  • • Log timing validation failures for debugging

⚡ Oversized JWT Tokens

medium

Including too much data in JWTs creates large tokens that impact performance and may hit browser/server limits.

❌ Wrong Implementation

// ❌ Including large data sets
const payload = {
  userId: 123,
  preferences: { /* 2KB of user preferences */ },
  permissions: [ /* 100 permission objects */ ],
  profile: {
    bio: "Very long biography...", // Large strings
    avatar: "data:image/jpeg;base64,..." // Base64 image!
  },
  auditLog: [ /* Last 50 user actions */ ]
};

// Results in 8KB+ tokens!

✅ Correct Implementation

// ✅ Minimal payload
const payload = {
  sub: 'user123',
  role: 'admin',
  permissions: ['read', 'write'], // Just permission names
  iat: Math.floor(Date.now() / 1000),
  exp: Math.floor(Date.now() / 1000) + (15 * 60)
};

// ✅ Store large data server-side
const userPreferences = await getUserPrefs(userId);
const userProfile = await getUserProfile(userId);

// ✅ Reference by ID, fetch when needed
const tokenPayload = {
  sub: userId,
  role: userRole,
  prefVersion: userPrefVersion // Version for cache invalidation
};

💥 Security Impact

Poor performance, HTTP header size limits exceeded, mobile app crashes, and increased network usage.

🛠️ How to Fix

  • • Keep payloads under 1KB when possible
  • • Store large data server-side, reference by ID
  • • Use version numbers for cache invalidation
  • • Paginate permissions instead of including all
  • • Consider JWE (encryption) for larger payloads

⚡ Poor Error Handling

medium

Not properly handling JWT validation errors can leak information to attackers or create poor user experience.

❌ Wrong Implementation

// ❌ Exposing internal error details
try {
  const decoded = jwt.verify(token, secret);
} catch (error) {
  // Leaks implementation details
  res.status(401).json({ 
    error: error.message, // "jwt signature is invalid"
    stack: error.stack,   // Reveals code structure
    secret: secret       // NEVER expose secrets!
  });
}

// ❌ Generic error handling
app.use((error, req, res, next) => {
  res.status(500).json({ error: 'Something went wrong' });
  // No logging, can't debug issues
});

✅ Correct Implementation

// ✅ Secure error handling
try {
  const decoded = jwt.verify(token, secret, {
    algorithms: ['HS256']
  });
  req.user = decoded;
  next();
} catch (error) {
  // ✅ Log detailed error internally
  logger.warn('JWT validation failed', {
    error: error.message,
    ip: req.ip,
    userAgent: req.get('User-Agent'),
    tokenPrefix: token ? token.substring(0, 20) : 'missing'
  });

  // ✅ Return generic error to client
  return res.status(401).json({
    error: 'Authentication failed',
    code: 'INVALID_TOKEN'
  });
}

// ✅ Differentiate error types for better UX
function handleJWTError(error, res) {
  if (error.name === 'TokenExpiredError') {
    return res.status(401).json({
      error: 'Token expired',
      code: 'TOKEN_EXPIRED'
    });
  }
  
  // Generic response for other errors
  return res.status(401).json({
    error: 'Invalid token',
    code: 'INVALID_TOKEN'
  });
}

💥 Security Impact

Information disclosure to attackers, poor debugging capabilities, and confusing user experience during authentication failures.

🛠️ How to Fix

  • • Log detailed errors server-side only
  • • Return generic error messages to clients
  • • Use error codes for client-side handling
  • • Implement proper monitoring and alerting
  • • Never expose secrets or internal paths

🧪 Testing Your JWT Implementation

🔍 Security Test Cases

  • •Expired Token Test: Verify expired tokens are rejected
  • •Invalid Signature Test: Modify token signature and verify rejection
  • •Algorithm Confusion: Try changing algorithm in header
  • •None Algorithm: Test tokens with "alg": "none"
  • •Malformed Token: Send invalid base64 or JSON
  • •Missing Claims: Remove required claims and test

🛠️ Security Tools

jwt.io

Decode and verify JWTs online

OWASP ZAP

Security testing proxy with JWT support

Burp Suite

Professional security testing platform

jwt-cracker

Test JWT secret strength

Implement JWT Security Correctly

Now that you know the common mistakes, generate secure JWT tokens with proper configuration. Use our tool to create tokens with strong secrets and correct settings.

Generate Secure JWT TokensView Security Checklist
✓ Strong secrets ✓ Proper algorithms ✓ Secure defaults ✓ Best practices built-in