Complete Guide to JWT Security Testing in 2026

What is a JSON Web Token?

JSON Web Tokens (JWT) are an open standard (RFC 7519) for securely transmitting information between parties as a compact, URL-safe JSON object. JWTs are widely used for authentication and authorization in modern web applications, APIs, microservices, and single sign-on (SSO) systems.

A JWT encodes claims (user identity, roles, permissions) into a digitally signed token. The server creates the token after successful authentication, and the client includes it in subsequent requests — typically in the Authorization: Bearer header or as a cookie.

While JWTs are powerful, implementation mistakes are extremely common and can lead to complete authentication bypass, privilege escalation, and account takeover.

JWT Structure Explained

A JWT consists of three Base64url-encoded parts separated by dots:

• Header (red) — Specifies the signing algorithm (alg) and token type (typ). May include kid, jku, jwk, x5u, x5c parameters.
• Payload (purple) — Contains the claims: sub (subject), iss (issuer), aud (audience), exp (expiration), iat (issued at), and custom claims like role.
• Signature (cyan) — Created by signing the header and payload with a secret key (HMAC) or private key (RSA/ECDSA). Verifies token integrity.

Common JWT Vulnerabilities

JWT security issues fall into several categories. Each represents a different attack surface that pentesters should test:

1. Signature Verification Bypass

The most critical class of JWT vulnerabilities. If the server doesn't properly verify signatures, an attacker can forge arbitrary tokens.

• Algorithm "none" attack — Setting alg: "none" tells the server to skip signature verification entirely. JWTLens tests 16 case permutations (None, NONE, nOnE, etc.).
• Invalid signature acceptance — Some libraries accept tokens with modified signatures without validation.
• Empty signature — Removing the signature portion while keeping the trailing dot.
• Null signature bytes — Sending null bytes as the signature.

2. Algorithm Confusion (RS256 to HS256)

This is the highest-impact JWT attack. When a server uses RSA (asymmetric) to verify tokens, an attacker can switch the algorithm to HMAC (symmetric) and sign the token with the server's public key as the HMAC secret. Since the server uses the same key for HMAC verification, the forged signature is accepted.

JWTLens automates this by fetching real public keys from JWKS endpoints and testing both DER and PEM encodings. Read the full algorithm confusion guide →

3. KID (Key ID) Injection

The kid header parameter identifies which key to use for verification. If the server uses this value in file paths, database queries, or system commands without sanitization, it opens injection vectors.

• Path traversal — kid: "../../../dev/null" to sign with an empty/known file
• SQL injection — kid: "' UNION SELECT 'secret' --" to extract a known signing key
• Command injection — kid: "| sleep 5" for blind command execution
• LDAP injection — kid: "*" for wildcard key matching

Read the full KID injection guide →

4. Header Parameter Injection

JWT headers can contain URLs and keys that the server fetches or trusts:

• JWK injection — Embedding a self-signed key in the token header
• JKU injection — Pointing to an attacker-controlled JWKS URL
• X5U/X5C injection — Injecting attacker certificates

5. Weak Secrets

Many applications use weak or default HMAC signing secrets. Common examples: secret, password, jwt_secret, changeme, the jwt.io default key. JWTLens tests 200+ known weak secrets offline before sending any requests.

6. Token Lifetime Issues

• Missing exp claim (tokens that never expire)
• Expired tokens still accepted by the server
• Tokens valid after logout or password change
• Excessive lifetime (> 24 hours)

7. Sensitive Data Exposure

JWT payloads are only Base64-encoded, not encrypted. Storing passwords, credit card numbers, SSNs, or API keys in JWT claims exposes them to anyone who intercepts the token.

Passive Security Checks (No Extra Traffic)

Passive checks analyze JWT tokens as they flow through Burp Proxy without generating additional HTTP requests. JWTLens performs 23 passive checks:

• Token leakage — JWT in URL query parameter or fragment (logged by servers, proxies, browser history)
• Cookie security — Missing HttpOnly, Secure, or SameSite attributes on JWT cookies
• Claim analysis — Missing exp, iss, aud, nbf, jti claims
• Sensitive data — Emails, passwords, SSNs, credit cards, API keys in the payload
• Dangerous headers — Presence of kid, jku, jwk, x5u, x5c parameters (indicates attack surface)
• Algorithm analysis — Weak or deprecated signing algorithms
• Response leakage — JWTs exposed in HTTP response bodies

Active Attack Vectors (33 Tests)

Active checks send modified JWT tokens to the server and analyze responses to confirm vulnerabilities. These require explicit triggering via right-click context menu in Burp.

JWTLens covers every major JWT attack category:

• 5 signature bypass attacks — Algorithm none, invalid signature, stripping, null bytes, unsigned modification
• 3 algorithm attacks — RS256-to-HS256 confusion, cross-algorithm signing, forged public key (Sign2n)
• 4 KID injection attacks — Path traversal, SQL injection, command injection, LDAP injection
• 5 header injection attacks — JWK, JKU, JKU SSRF, X5U, X5C injection
• 3 weak key attacks — Empty secret, brute force (200+ secrets), weak RSA key size
• 5 lifetime/claim attacks — Expired token, nbf bypass, claim tampering, subject enumeration, clock skew
• 2 CVE-specific attacks — CVE-2022-21449 Psychic Signatures, ECDSA malleability
• 6 recon/logic attacks — JWKS discovery, typ manipulation, cross-service replay, post-logout validity, post-password-change validity, JWKS spoofing

Secret Extraction Techniques

One of JWTLens's unique features is passive secret extraction. As you browse a target application, JWTLens monitors all HTTP responses for:

• Hardcoded JWT secrets in JavaScript files, JSON configs, and HTML (e.g., JWT_SECRET = "my-secret")
• RSA/EC private keys in PEM format
• Public keys (automatically used for algorithm confusion attacks)
• Inline JWKS structures in API responses
• JWKS URL references
• Base64-encoded secrets from atob() or Buffer.from() calls

Discovered secrets are automatically prepended to the brute force wordlist (tested first, highest priority), and public keys are fed into algorithm confusion attacks — creating a fully automated attack chain.

JWT Security Testing Methodology

Follow this systematic approach when testing JWT security:

1. Reconnaissance — Identify where JWTs are used (headers, cookies, URL params). Check for JWKS endpoints at /.well-known/jwks.json.
2. Passive Analysis — Decode the JWT (JWTLens does this automatically). Check the algorithm, claims, lifetime, and cookie flags.
3. Secret Extraction — Browse the application thoroughly. Let JWTLens passively extract any hardcoded secrets or keys from responses.
4. Signature Bypass — Test algorithm none, invalid signatures, and signature stripping.
5. Algorithm Confusion — If RS256/RS384/RS512, attempt the HS256 confusion attack with the server's public key.
6. Weak Secret Brute Force — If HMAC algorithm, run the brute force with built-in + extracted + custom wordlists.
7. Header Injection — If kid/jku/jwk/x5u/x5c parameters exist, test injection vectors.
8. Claim Tampering — Modify role, admin, sub claims. Test privilege escalation.
9. Lifetime Testing — Test expired tokens, post-logout replay, post-password-change replay.
10. Forge & Exploit — Use JWT Forge to create proof-of-concept tokens for confirmed vulnerabilities.

Automating JWT Testing with JWTLens

JWTLens for Burp Suite automates all 56 checks described above. Here's how to get started:

1. Download jwtlens-1.0.0.jar from GitHub Releases
2. In Burp Suite: Extensions → Installed → Add → select the JAR
3. Browse the target application — passive checks run automatically
4. Right-click any request with a JWT → select Scan JWT for active attacks
5. Check the JWTLens tab for all findings with severity, confidence, and remediation
6. Use JWT Forge to edit, sign, and create PoC tokens
7. Export findings as CSV for your pentest report