Token & JWT Misconfiguration

JWTJSON Web TokenBearer TokenToken Security

Token & JWT Misconfiguration at a glance

What it is: Security flaws in JSON Web Token (JWT) implementation including weak signatures, missing validation, algorithm confusion, and token exposure that allow attackers to forge or hijack authentication tokens.

Why it happens: JWT vulnerabilities occur when tokens use weak or misconfigured algorithms, lack proper claim or expiration checks, expose secrets or sensitive data, or are stored and managed insecurely without revocation.

How to fix: Validate JWTs with strong algorithms, verify all claims, store tokens securely in HttpOnly cookies, and use rotation with short expiration to reduce compromise risk.

Overview

JSON Web Tokens (JWT) are a popular standard for representing claims securely between parties, commonly used for authentication in modern web applications and APIs. However, improper implementation can lead to critical security vulnerabilities.

Common JWT vulnerabilities include accepting the 'none' algorithm allowing unsigned tokens, algorithm confusion attacks where RS256 tokens are validated as HS256 using the public key as a secret, missing or incomplete validation of claims like expiration and issuer, storing sensitive data in JWT payloads (which are only base64 encoded, not encrypted), and insecure token storage exposing tokens to XSS attacks.

sequenceDiagram participant Attacker participant App as Application participant API Attacker->>Attacker: Obtain valid JWT Attacker->>Attacker: Change alg: RS256 to alg: HS256 Attacker->>Attacker: Sign with public key as HMAC secret Attacker->>App: Request with modified JWT App->>App: Verify using public key (as HS256 secret) App-->>Attacker: 200 OK (authenticated) Note over App: Missing: Algorithm allowlist<br/>Missing: Proper signature validation

A potential flow for a Token & JWT Misconfiguration exploit

Where it occurs

JWT vulnerabilities occur in token handling where algorithms, claims, or signatures aren’t properly validated, secrets are weak or exposed, or tokens lack expiration, revocation, or secure storage.

Impact

JWT misconfigurations lead to authentication bypass through forged tokens, session hijacking from stolen tokens, privilege escalation by modifying claims, unauthorized API access, data exposure from token payloads, and inability to revoke compromised tokens.

Prevention

Prevent this by using RS256/ES256 (reject “none”), verifying signatures first, validating exp/iat/nbf/iss/aud, keeping tokens short-lived with rotating refresh tokens, storing in HttpOnly Secure cookies, omitting sensitive payloads, and enabling revocation.

Examples

Switch tabs to view language/framework variants.

JWT verification vulnerable to algorithm confusion attack

JWT library doesn't enforce algorithm, allowing RS256 to HS256 downgrade.

Vulnerable

JavaScript • Express + jsonwebtoken — Bad

const jwt = require('jsonwebtoken');
const fs = require('fs');

const publicKey = fs.readFileSync('public.pem');

app.use((req, res, next) => {
    const token = req.headers.authorization?.split(' ')[1];
    // BUG: No algorithm specified
    const decoded = jwt.verify(token, publicKey);
    req.user = decoded;
    next();
});

Line 9: No algorithm specified

Not specifying algorithm allows attackers to switch from RS256 to HS256.

Secure

JavaScript • Express + jsonwebtoken — Good

const jwt = require('jsonwebtoken');
const fs = require('fs');

const publicKey = fs.readFileSync('public.pem');

app.use((req, res, next) => {
    const token = req.headers.authorization?.split(' ')[1];
    
    try {
        // Enforce RS256 algorithm
        const decoded = jwt.verify(token, publicKey, {
            algorithms: ['RS256']
        });
        req.user = decoded;
        next();
    } catch (err) {
        return res.status(401).json({ error: 'Invalid token' });
    }
});

Line 11: Enforce expected algorithm

Always specify expected algorithm in verification options.

JWT signed with weak secret enables token forgery

Application uses predictable JWT signing secret, allowing attackers to forge valid authentication tokens.

Vulnerable

Python • Flask + PyJWT — Bad

# Vulnerable: Weak JWT secret
from flask import Flask, request, jsonify
import jwt
import datetime

app = Flask(__name__)

# VULNERABLE: Weak, predictable secret
SECRET_KEY = 'secret'  # Or 'password', '123456', etc.

@app.route('/login', methods=['POST'])
def login():
    username = request.json.get('username')
    password = request.json.get('password')
    
    user = authenticate_user(username, password)
    if not user:
        return jsonify({'error': 'Invalid credentials'}), 401
    
    # Create JWT with weak secret
    payload = {
        'user_id': user.id,
        'username': user.username,
        'role': user.role,
        'exp': datetime.datetime.utcnow() + datetime.timedelta(hours=24)
    }
    
    token = jwt.encode(payload, SECRET_KEY, algorithm='HS256')
    return jsonify({'token': token})

@app.route('/admin/users', methods=['GET'])
def admin_users():
    token = request.headers.get('Authorization', '').replace('Bearer ', '')
    
    try:
        # Verify with weak secret
        payload = jwt.decode(token, SECRET_KEY, algorithms=['HS256'])
        
        # Check role from JWT
        if payload.get('role') != 'admin':
            return jsonify({'error': 'Forbidden'}), 403
        
        users = get_all_users()
        return jsonify({'users': users})
    
    except jwt.InvalidTokenError:
        return jsonify({'error': 'Invalid token'}), 401

Line 9:
Line 24:
Line 27:
Line 38:

The vulnerable code uses 'secret' as the JWT signing secret - a common dictionary word that appears in standard password wordlists like rockyou.txt. This can be brute forced offline in seconds.

With HS256 (HMAC-SHA256), the same secret is used for both signing and verification. Once an attacker obtains any JWT, they can attempt to brute force the secret offline without making requests to the server.

After cracking the secret, an attacker can forge arbitrary JWTs with any claims - different user_ids, admin roles, extended expiration dates. The application has no way to distinguish forged tokens from legitimate ones.

The 24-hour expiration makes stolen or forged tokens valid for a full day, and role authorization relies solely on JWT claims without database verification.

Secure

Python • Flask + PyJWT — Good

# Secure: Strong secret and proper JWT configuration
from flask import Flask, request, jsonify
import jwt
import datetime
import secrets
import os

app = Flask(__name__)

# Use cryptographically secure random secret
# Generated with: python -c 'import secrets; print(secrets.token_urlsafe(64))'
SECRET_KEY = os.environ.get('JWT_SECRET_KEY')
if not SECRET_KEY:
    raise ValueError('JWT_SECRET_KEY environment variable must be set')

# Use 256-bit minimum for HS256
if len(SECRET_KEY) < 32:
    raise ValueError('JWT secret must be at least 32 bytes')

# Or use asymmetric RS256 (preferred)
PRIVATE_KEY = open('private_key.pem', 'r').read()
PUBLIC_KEY = open('public_key.pem', 'r').read()

@app.route('/login', methods=['POST'])
def login():
    username = request.json.get('username')
    password = request.json.get('password')
    
    user = authenticate_user(username, password)
    if not user:
        return jsonify({'error': 'Invalid credentials'}), 401
    
    # Create JWT with strong secret and proper claims
    payload = {
        'user_id': user.id,
        'username': user.username,
        'role': user.role,
        'iat': datetime.datetime.utcnow(),  # Issued at
        'exp': datetime.datetime.utcnow() + datetime.timedelta(minutes=15),  # Short expiration
        'iss': 'https://api.example.com',  # Issuer
        'aud': 'api.example.com',  # Audience
        'jti': secrets.token_urlsafe(16)  # JWT ID for revocation
    }
    
    # Use RS256 for better key management
    token = jwt.encode(payload, PRIVATE_KEY, algorithm='RS256')
    
    # Also issue refresh token
    refresh_token = create_refresh_token(user.id)
    
    return jsonify({
        'access_token': token,
        'refresh_token': refresh_token,
        'expires_in': 900  # 15 minutes
    })

@app.route('/admin/users', methods=['GET'])
def admin_users():
    token = request.headers.get('Authorization', '').replace('Bearer ', '')
    
    try:
        # Verify with public key and validate claims
        payload = jwt.decode(
            token,
            PUBLIC_KEY,
            algorithms=['RS256'],  # Explicitly specify algorithm
            issuer='https://api.example.com',
            audience='api.example.com',
            options={
                'verify_signature': True,
                'verify_exp': True,
                'verify_iat': True,
                'require': ['exp', 'iat', 'iss', 'aud', 'jti']
            }
        )
        
        # Check if token is revoked
        if is_token_revoked(payload['jti']):
            return jsonify({'error': 'Token revoked'}), 401
        
        # Verify role from database, not just JWT
        user = get_user_by_id(payload['user_id'])
        if not user or user.role != 'admin':
            return jsonify({'error': 'Forbidden'}), 403
        
        users = get_all_users()
        return jsonify({'users': users})
    
    except jwt.ExpiredSignatureError:
        return jsonify({'error': 'Token expired'}), 401
    except jwt.InvalidTokenError as e:
        return jsonify({'error': f'Invalid token: {str(e)}'}), 401

Line 11:
Line 18:
Line 38:
Line 62:
Line 75:
Line 79:

The secure implementation uses RS256 (RSA-SHA256) asymmetric encryption instead of HS256. The private key signs tokens but is never exposed; only the public key is used for verification. This makes brute forcing impossible.

The JWT secret (if using HS256) would be generated using secrets.token_urlsafe(64), creating a 512-bit cryptographically random secret that's infeasible to brute force.

Access tokens expire after only 15 minutes, limiting the window for abuse. A separate refresh token (stored securely) allows obtaining new access tokens without re-authentication.

All standard JWT claims are validated: issuer (iss), audience (aud), expiration (exp), issued at (iat). The jti (JWT ID) enables token revocation.

Critical: Role authorization verifies against the database, not just JWT claims. Even if someone forged a token (somehow), they couldn't escalate privileges because the database is the source of truth.

Engineer Checklist

Use RS256 or ES256 for production (not HS256 with shared secrets)
Explicitly reject the 'none' algorithm
Validate signature before processing any claims
Verify exp (expiration) claim and reject expired tokens
Validate iss (issuer) matches expected value
Validate aud (audience) matches your application
Use short token lifetimes (15 min access, longer refresh)
Store tokens in HttpOnly, Secure, SameSite cookies
Never store sensitive data in JWT payloads
Implement token rotation for refresh tokens
Use cryptographically strong signing secrets (256+ bits)
Implement token revocation mechanism
Log and monitor for token anomalies

End-to-End Example

An application using JWT authentication accepts the 'none' algorithm, allowing attackers to forge valid tokens without any signature.

Vulnerable

JAVASCRIPT

// Vulnerable: Accepts any algorithm including 'none'
const decoded = jwt.verify(token, publicKey);

Secure

JAVASCRIPT

// Secure: Explicitly specify allowed algorithms
const decoded = jwt.verify(token, publicKey, {
  algorithms: ['RS256'], // Only allow RS256
  issuer: 'https://your-app.com',
  audience: 'your-api',
  clockTolerance: 0
});

Discovery

Decode a JWT and check the 'alg' field. Try changing it to 'none' and removing the signature. Test if the application accepts it.

1. Test JWT algorithm confusion
http
Action

Change RS256 JWT to HS256 with public key as secret
Request
GET https://api.example.com/protected

Body:

"Authorization: Bearer <modified_jwt>"
Response
Status: 200

Body:

{ "note": "Modified JWT accepted, signature bypassed" }
Artifacts

algorithm_confusion signature_bypass
2. Test JWT with none algorithm
http
Action

Send JWT with alg=none
Request
GET https://api.example.com/protected

Body:

"Authorization: Bearer eyJ...none..."
Response
Status: 200

Body:

{ "note": "Unsigned JWT accepted" }
Artifacts

none_algorithm no_signature_verification
3. Test JWT expiration validation
http
Action

Send expired JWT
Request
GET https://api.example.com/protected

Body:

"Authorization: Bearer <expired_jwt>"
Response
Status: 200

Body:

{ "note": "Expired token still accepted" }
Artifacts

no_expiration_check token_reuse

Exploit steps

Attacker modifies the algorithm field to 'none' or exploits algorithm confusion to forge tokens with elevated privileges.

1. Forge JWT using algorithm confusion

RS256 to HS256 attack
http
Action

Sign JWT with public key using HS256
Request
GET https://api.example.com/admin

Body:

"Authorization: Bearer <forged_jwt>"
Response
Status: 200

Body:

{ "note": "Admin access granted with forged token" }
Artifacts

forged_jwt privilege_escalation admin_access
2. Escalate privileges by modifying JWT claims

JWT claims manipulation
http
Action

Change role claim to admin in JWT
Request
GET https://api.example.com/protected

Body:

"{...,'role':'admin',...}"
Response
Status: 200

Body:

{ "note": "Modified claims accepted, admin privileges granted" }
Artifacts

privilege_escalation modified_claims
3. Bypass authentication with none algorithm

Unsigned JWT attack
http
Action

Remove signature and set alg to none
Request
GET https://api.example.com/user/123

Body:

"Authorization: Bearer eyJ...none..."
Response
Status: 200

Body:

{ "note": "Full API access without valid signature" }
Artifacts

authentication_bypass unsigned_token_accepted

Specific Impact

Complete authentication bypass allowing attackers to impersonate any user, access protected resources, and perform privileged operations without valid credentials.

Fix

Always specify the allowed algorithms explicitly to prevent algorithm confusion and 'none' algorithm attacks. Validate issuer, audience, and other claims. Use asymmetric algorithms (RS256, ES256) for better key management in distributed systems.

Detect This Vulnerability in Your Code

Sourcery automatically identifies token & jwt misconfiguration vulnerabilities and many other security issues in your codebase.

Scan Your Code for Free