Paste a JWT token to decode its header & payload and run a comprehensive security audit.
Test HMAC-signed JWTs against a wordlist of common/weak secrets. Runs entirely in your browser.
Decode a JWT, modify the header/payload, and regenerate the token (with optional signing).
// Token will appear here after clicking Generate JWT
Build JWT tokens from scratch — supports HMAC, RSA, and ECDSA signing. Generate real RSA-2048 key pairs in-browser, add standard claims with one click, and verify tokens instantly.
alg to "none" (or a variant)alg header from RS256 → HS256alg header will use the public key to verify — and succeedalg header and used the public key as HMAC secret/.well-known/jwks.json, /oauth/discovery, x5c header, or source codeid command output, or delayed responsejwk to verify will accept the token.
120+ point JWT security audit checklist based on OWASP, RFC 7519, RFC 8725, CVE disclosures, and real-world pen-testing experience.
| 🔴 | alg:none Bypass Verify the server rejects tokens with algorithm set to "none". An attacker can forge tokens without any secret — complete auth bypass. Ref: CVE-2015-9235 · RFC 8725 §2.1 | CRITICAL |
| 🔴 | Algorithm Confusion (RS256 → HS256) If the server uses RS256, test by sending an HS256 token signed with the RSA public key. Vulnerable libraries may accept it, allowing full token forgery. Ref: CVE-2016-5431 · PortSwigger Research | CRITICAL |
| 🔴 | Signature Not Verified Some implementations only base64-decode the JWT without verifying the signature. Send a token with a tampered payload and a random signature. Ref: OWASP API Top 10 · RFC 7519 §7.2 | CRITICAL |
| 🔴 | Empty / Truncated Signature Accepted Test if the server accepts tokens with an empty string as the signature field (header.payload.). The token format is technically valid but unsigned. Ref: RFC 8725 §2.1 · jwt_tool tests | CRITICAL |
| 🔴 | Weak HMAC Secret (Brute-Forceable) HMAC secrets under 256 bits or using dictionary words can be cracked offline using tools like hashcat in seconds. Test with the Secret Bruteforcer tab. Ref: RFC 7518 §3.2 · NIST SP 800-107 | CRITICAL |
| 🔴 | Null Byte / Padding Injection in Signature Some implementations may be vulnerable to null byte injection or Base64 padding confusion. Test with signatures ending in null bytes or extra padding characters. Ref: Python-jwt CVE-2022-39227 | CRITICAL |
| 🟠 | Weak Algorithm: HS256 HS256 provides only 128-bit security level. Prefer HS512 (256-bit security), RS256, or ES256 for better resistance against brute-force. Ref: RFC 7518 §3 · NIST SP 800-131A | HIGH |
| 🟠 | alg:none Case Variants Test case variants: "None", "NONE", "nOnE", "NoNe". Some parsers may accept these as equivalent to "none" due to case-insensitive algorithm matching. Ref: Tim McLean JWT security research | HIGH |
| 🟠 | RSA-PSS Algorithm Confusion (PS256 → RS256) If a server accepts both PS256 and RS256, test swapping between them. Malformed PSS signatures may be accepted by loose RSA verifiers. Ref: RFC 7518 §3.5 | HIGH |
| 🟡 | Algorithm Downgrade Attack Verify the server does not allow downgrading from a stronger algorithm (ES256) to a weaker one (HS256) by modifying the alg header. Ref: RFC 8725 §2.1 · OWASP JWT Cheat Sheet | MEDIUM |
| 🔴 | Missing exp (Expiration) Claim Token never expires — remains valid indefinitely. If stolen, attacker has permanent access. This is the most common critical JWT misconfiguration. Ref: RFC 7519 §4.1.4 · OWASP A07:2021 | CRITICAL |
| 🔴 | Expired Token Accepted by Server Verify the server actually rejects expired tokens. Clock skew tolerance should be ≤60 seconds. Test by replaying a known-expired token. Ref: RFC 7519 §4.1.4 · RFC 8725 §3.9 | HIGH |
| 🟠 | Missing / Unvalidated iss (Issuer) Without issuer validation, tokens from other systems or environments (prod token on dev) may be accepted. Validate against a strict whitelist. Ref: RFC 7519 §4.1.1 | MEDIUM |
| 🟠 | Missing / Unvalidated aud (Audience) Without audience validation, a token for service A can be replayed against service B. This is the "confused deputy" problem in microservices. Ref: RFC 7519 §4.1.3 · RFC 8725 §2.4 | MEDIUM |
| 🟡 | Missing jti (JWT ID) Claim Without a unique JWT ID, token revocation is impossible, making logout and credential rotation ineffective. Ref: RFC 7519 §4.1.7 | LOW |
| 🟡 | Missing sub (Subject) Claim The sub claim should uniquely identify the token's principal. Its absence makes user attribution and authorization logic harder to implement securely. Ref: RFC 7519 §4.1.2 | LOW |
| 🟠 | nbf (Not-Before) Not Enforced Verify the server enforces the nbf claim. Pre-issued tokens (nbf in future) should be rejected until the activation time passes. Ref: RFC 7519 §4.1.5 | MEDIUM |
| 🟠 | iat Issued-in-Future A future-dated iat may indicate token manipulation. Servers should reject tokens with iat more than 60 seconds ahead of server time. Ref: RFC 7519 §4.1.6 | MEDIUM |
| 🟠 | Excessive Token Lifetime (>24h) Long-lived access tokens dramatically increase the impact window of token theft. Prefer ≤15 min for access tokens, ≤24h for refresh tokens. Ref: OAuth 2.0 Security Best Practices §2.1.2 | MEDIUM |
| 🟠 | Replay Attack Potential Token lacks a jti claim and has a long expiration — makes it trivial to replay intercepted tokens across sessions or services. Ref: RFC 7519 §4.1.7 · OWASP Testing Guide | MEDIUM |
| 🔵 | Weak / Predictable jti Value A sequential or timestamp-only jti (e.g., "1", "1234567890") lacks sufficient uniqueness for reliable replay prevention. Ref: RFC 7519 §4.1.7 · NIST SP 800-90A | LOW |
| 🟠 | Cross-Tenant / Cross-Environment Token Reuse Test if a production token is accepted in staging or if tokens from one tenant work for another. Proper iss + aud validation prevents this. Ref: RFC 8725 §2.4 · Multi-tenant JWT security | MEDIUM |
| 🔴 | kid SQL Injection If kid is interpolated into a DB query, inject: kid: 1' OR '1'='1'--. A successful injection lets attackers control which key is fetched, potentially returning a known/empty key.Ref: PortSwigger JWT Labs · CVE research | CRITICAL |
| 🔴 | kid Path Traversal Test: kid: ../../dev/null or kid: ../../../../etc/passwd. If kid is used as a file path, returning empty or known content bypasses signature verification.Ref: PortSwigger JWT Labs | CRITICAL |
| 🔴 | kid Command Injection (RCE) If kid is passed to a shell command for key retrieval, inject shell metacharacters. Special chars like ; | & ` $( ) may trigger remote code execution.Ref: OWASP Command Injection · CWE-78 | CRITICAL |
| 🔴 | jku Header Injection (JWKS URL Hijack) The jku header points to a JWKS endpoint. If the server fetches this URL without domain whitelisting, point it to an attacker-controlled server to return a self-generated key pair. Ref: RFC 7515 §4.1.2 · PortSwigger JWT Labs | CRITICAL |
| 🔴 | x5u Header Injection x5u specifies a URL for an X.509 certificate chain. Without strict domain validation, redirect it to an attacker-controlled certificate to forge tokens. Ref: RFC 7515 §4.1.5 · RFC 8725 §3.9 | CRITICAL |
| 🟠 | Embedded JWK in Header (Self-Signed) Some libraries accept a jwk header parameter containing an embedded key and use it for verification. Attackers can embed their own public key to forge tokens signed with the matching private key.Ref: CVE-2018-0114 · RFC 8725 §3.9 | HIGH |
| 🟠 | x5c Certificate Chain Injection The x5c header embeds a certificate chain. If the server trusts embedded certificates without validating against trusted root CAs, an attacker can supply self-signed certs. Ref: RFC 7515 §4.1.6 · RFC 8725 §3.9 | HIGH |
| 🟠 | kid / jku SSRF (Server-Side Request Forgery) Even if the attacker cannot control the key returned, jku or x5u pointing to internal IPs can be used to probe internal network services via SSRF. Ref: OWASP SSRF · CWE-918 | HIGH |
| 🟡 | cty (Content Type) Header Misuse The cty header (e.g., cty: JWT) signals nested JWTs. If not expected, servers parsing nested structures may be tricked into double-decoding, leading to claim injection.Ref: RFC 7519 §5.2 | MEDIUM |
| 🟡 | typ Header Manipulation Changing the typ from JWT to JWT+AT or omitting it may bypass token type checks in some implementations. Validate the typ header explicitly.Ref: RFC 9068 · OAuth 2.0 Access Token JWT | MEDIUM |
| 🟠 | Sensitive PII in Payload JWT payload is only base64url-encoded — not encrypted. Passwords, SSNs, credit card numbers, health data, or government IDs must never appear in JWT claims. Ref: GDPR Article 32 · OWASP Data Exposure | HIGH |
| 🟠 | Over-Privileged Role / Permission Claims Inspect role and permission claims for excessive privileges. A token claiming "admin" or "superuser" is a high-value target. Apply least-privilege principle. Ref: OWASP A01:2021 · PoLP | MEDIUM |
| 🔵 | Internal System Metadata in Claims Claims like db_host, internal_id, shard, or service names reveal internal architecture — valuable for attackers during reconnaissance.Ref: OWASP API3:2023 Property Level Authorization | LOW |
| 🔵 | Email / Username Exposed in Claims Email and username in JWT claims are readable by any party that holds or intercepts the token — including client-side JavaScript, proxy logs, and CDN access logs. Ref: OWASP API3 · GDPR Article 25 | LOW |
| 🟠 | Token Exposed in URL / Query Parameters JWTs passed as URL parameters appear in server logs, browser history, Referer headers, and analytics tools — all unintended disclosures of credential material. Ref: RFC 6750 §5.3 · OWASP JWT Cheat Sheet | MEDIUM |
| 🔵 | Debug / Version Claims in Production Claims like debug: true, env: staging, or version: 1.2.3 should never appear in production tokens — they reveal environment details to attackers.Ref: CWE-200 Information Exposure | LOW |
| 🟠 | Long-Lived Token in Insecure Client Storage Refresh tokens stored in localStorage or sessionStorage are accessible to JavaScript and vulnerable to XSS-based theft. Use HttpOnly cookies instead. Ref: OWASP A02:2021 · Web Storage Risks | HIGH |
| 🟠 | Refresh Token Rotation Not Enforced Each refresh token should be single-use. Rotate and invalidate the old token on every use. Detect and alert on reuse — it may signal theft. Ref: OAuth 2.0 Security BCP §2.2.2 | HIGH |
| 🟠 | Refresh Token Never Expires Refresh tokens without expiration grant permanent access. Set absolute expiration (e.g., 90 days) and idle timeout (e.g., 14 days inactivity). Ref: OAuth 2.0 Security BCP §2.2 · NIST 800-63B | HIGH |
| 🟡 | Refresh Token Not Bound to Client Refresh tokens should be bound to the client (client_id, device fingerprint, or DPoP key). An unbound refresh token stolen from storage can be used from any device. Ref: RFC 9449 DPoP · OAuth 2.0 Security BCP §2.2 | MEDIUM |
| 🟡 | Refresh Token Scope Escalation Verify the server does not issue access tokens with broader scopes than the original refresh token's scope. Test by modifying scope in refresh requests. Ref: RFC 6749 §6 · OAuth 2.0 Security BCP | MEDIUM |
| 🟠 | Refresh Tokens Stored Plaintext Server-Side Store only hashed refresh tokens (e.g., SHA-256) server-side. If the database is compromised, plaintext refresh tokens provide immediate unauthorized access. Ref: OWASP Auth Cheat Sheet | HIGH |
| 🟡 | Refresh Token Not Revoked on Logout Verify that logging out invalidates all associated refresh tokens server-side. Test by attempting to use a refresh token after logout. Ref: RFC 7009 Token Revocation · OAuth 2.0 BCP | MEDIUM |
| 🟠 | HTTPS Not Enforced Tokens must only be transmitted over TLS 1.2+. HSTS should be configured. Never send tokens over HTTP — they can be intercepted by passive listeners. Ref: RFC 6750 §5.3 · RFC 8446 TLS 1.3 | HIGH |
| 🟠 | Cookie Missing Security Flags If storing JWT in cookies, all three flags are required: HttpOnly (prevents XSS theft), Secure (HTTPS only), SameSite=Strict (prevents CSRF).Ref: RFC 6265bis · OWASP CSRF Prevention | HIGH |
| 🟠 | Token Stored in localStorage / sessionStorage Tokens stored in Web Storage are accessible to any JavaScript on the page. A single XSS vulnerability leads to token theft. Use HttpOnly cookies instead. Ref: OWASP XSS Prevention · Auth0 Security Guide | HIGH |
| 🟡 | Token Leaked in Referrer / Access Logs Tokens in URLs appear in server access logs, CDN logs, Referrer headers, and third-party analytics — all unintended disclosures. Never put tokens in URLs. Ref: RFC 6750 §5.3 · CWE-598 | MEDIUM |
| 🟡 | Token Cached by Service Worker Service workers can intercept and cache API responses including Authorization headers. Verify tokens are not inadvertently cached in service worker caches. Ref: OWASP PWA Security · Service Worker Security | MEDIUM |
| 🔵 | CORS Misconfiguration Leaking Token A wildcard CORS policy ( Access-Control-Allow-Origin: *) combined with credentials: true allows cross-origin sites to read Authorization headers.Ref: OWASP CORS Security · RFC 6454 | LOW |
| 🟡 | Token Leakage via postMessage When passing tokens between frames or windows using postMessage, verify the target origin is explicitly specified — never use * as the target origin.Ref: MDN postMessage security · CWE-346 | MEDIUM |
| 🟠 | Secret Entropy Below 256 Bits HMAC secrets must be at least 32 cryptographically random bytes (256 bits). Anything shorter or derived from human-memorable strings is unsafe. Ref: RFC 7518 §3.2 · NIST SP 800-132 | HIGH |
| 🟠 | No Key Rotation Policy Define and implement a key rotation schedule (e.g., every 90 days or after suspected compromise). Old keys must be retired after rotation; publish new keys via JWKS. Ref: NIST SP 800-57 · RFC 7517 JWKS | HIGH |
| 🟠 | Secret Hardcoded in Source Code JWT secrets hardcoded in code, config files, or committed to version control are trivially discoverable. Use secrets management (Vault, AWS Secrets Manager, etc.). Ref: CWE-321 · OWASP A02:2021 Cryptographic Failures | HIGH |
| 🟡 | JWKS Endpoint Not Properly Secured The JWKS endpoint should be read-only, rate-limited, and cached. Ensure it does not expose private key material and serves only public verification keys. Ref: RFC 7517 §5 · RFC 8414 Authorization Server Metadata | MEDIUM |
| 🟡 | Private Key Improper Storage RSA/EC private keys must be stored with restrictive file permissions (600), ideally in HSM or secure enclaves. Never log or expose private key material. Ref: NIST SP 800-57 · PKCS#11 · HSM best practices | MEDIUM |
| 🔵 | kid Enumeration / Discovery If kid values are sequential integers (1, 2, 3), attackers can enumerate valid key IDs. Use non-sequential UUIDs or opaque identifiers for kid values. Ref: RFC 7517 §4.5 · Security through obscurity | LOW |
| 🟡 | Multiple Active Signing Keys Without kid When multiple keys are active (during rotation), all tokens must include a kid header. Without it, servers must try all keys, increasing the attack surface for key confusion. Ref: RFC 7517 §4.5 · Key rotation best practices | MEDIUM |
| 🟠 | Implicit Flow Usage (OAuth 2.0) The OAuth 2.0 implicit flow returns tokens in the URL fragment — exposing them to browser history and referrer leakage. Migrate to Authorization Code + PKCE. Ref: OAuth 2.0 Security BCP §2.1.2 · RFC 9700 | HIGH |
| 🟠 | PKCE Not Implemented (Public Clients) Public clients (SPAs, mobile apps) must use PKCE (RFC 7636). Without it, authorization codes intercepted via redirect URI attacks can be exchanged for tokens. Ref: RFC 7636 · OAuth 2.0 Security BCP §2.1 | HIGH |
| 🔴 | Open Redirect in redirect_uri If the authorization server does not strictly validate redirect_uri against a registered whitelist, attackers can steal authorization codes or tokens via open redirect. Ref: RFC 6749 §10.6 · OAuth 2.0 Security BCP §4.1 | CRITICAL |
| 🟠 | Missing state Parameter (CSRF in OAuth) The state parameter prevents CSRF attacks during the OAuth authorization flow. Verify it is generated with sufficient entropy and validated on callback. Ref: RFC 6749 §10.12 · OAuth 2.0 Security BCP §2.1 | HIGH |
| 🟠 | Missing nonce in OIDC ID Token The nonce in OIDC ID tokens prevents replay attacks. Clients must validate that the nonce in the ID token matches the one sent in the authorization request. Ref: OIDC Core §3.1.2.1 · RFC 6749 | HIGH |
| 🟡 | at_hash / c_hash Not Validated OIDC ID tokens include at_hash (access token hash) and c_hash (code hash). Clients should validate these to ensure the access token and code correspond to the ID token. Ref: OIDC Core §3.3.2.11 | MEDIUM |
| 🟡 | Overly Broad OAuth Scopes Request only the minimum necessary scopes. Broad scopes like * or admin increase the blast radius if a token is compromised.Ref: RFC 6749 §3.3 · PoLP principle | MEDIUM |
| 🟠 | DPoP Not Implemented (Sender-Constrained Tokens) DPoP (RFC 9449) binds access tokens to a client's private key, preventing stolen token reuse. Implement DPoP for high-value API access. Ref: RFC 9449 DPoP · OAuth 2.0 Security BCP §2.2.1 | HIGH |
| 🔴 | Outdated JWT Library with Known CVEs Check your JWT library version against the NVD and GitHub Security Advisories. Many critical CVEs (e.g., CVE-2015-9235, CVE-2022-39227) affect popular libraries. Ref: NVD CVE Database · GitHub Security Advisories | CRITICAL |
| 🟠 | Library Algorithm Auto-Detection Enabled Never pass the algorithm from the token header to the library's verify function. The algorithm must be hardcoded server-side, not trusted from the untrusted token. Ref: CVE-2015-9235 · RFC 8725 §2.1 | HIGH |
| 🟠 | Using Decode Instead of Verify Code review red flag: using jwt.decode() (no verification) in authentication paths instead of jwt.verify(). Decode-only functions skip all security checks.Ref: CWE-347 Improper Verification of Cryptographic Signature | HIGH |
| 🟡 | Insecure Library Default Options Some JWT libraries disable expiration checking or signature verification by default. Explicitly configure: verify_exp=True, verify_signature=True, and required algorithms.Ref: PyJWT docs · jsonwebtoken docs | MEDIUM |
| 🟡 | Non–Constant-Time Signature Comparison Signature comparison must use constant-time comparison functions (e.g., hmac.compare_digest()). Variable-time comparison leaks timing information enabling brute-force.Ref: CWE-208 · RFC 6151 Timing Attacks | MEDIUM |
| 🔵 | Verbose JWT Error Messages Error messages like "Invalid signature for HS256" reveal the algorithm and validation details to attackers. Use generic messages: "Authentication failed." Ref: CWE-209 Information Exposure Through Error Message | LOW |
| ⚪ | JSON Parsing Quirks & Duplicate Keys Different JSON parsers handle duplicate keys differently. Injecting {"alg":"RS256","alg":"none"} may confuse parsers — test for inconsistent claim resolution.Ref: RFC 7159 §4 · Parsing differential research | INFO |
| 🟠 | Direct Internal Service Access (Gateway Bypass) If microservices are accessible directly without going through the API gateway, attackers can bypass JWT validation entirely. Use network-level controls (mTLS, VPC) plus application-level validation. Ref: OWASP API Top 10 · Zero-Trust Architecture | HIGH |
| 🟠 | Insecure Service-to-Service Authentication Internal microservice calls should use mTLS or short-lived service JWTs — not shared secrets or no authentication at all. Avoid implicit trust within the perimeter. Ref: NIST Zero Trust Architecture SP 800-207 | HIGH |
| 🟡 | Token Pass-Through Without Scope Restriction API gateways that forward the original user JWT to downstream services allow those services to see full user permissions. Use token exchange (RFC 8693) to issue scoped downstream tokens. Ref: RFC 8693 Token Exchange · OWASP API Security | MEDIUM |
| 🟡 | Stale Token Validation Cache at Gateway If the API gateway caches JWKS keys aggressively, it may continue accepting tokens signed by a rotated/compromised key. Tune JWKS cache TTL appropriately (<5 min). Ref: RFC 7517 §5 · API Gateway JWKS caching | MEDIUM |
| 🟡 | Audience Confusion Across Microservices Each microservice should validate the aud claim and only accept tokens intended for it. Without strict aud validation, a token for service A can be replayed at service B. Ref: RFC 7519 §4.1.3 · Microservices JWT patterns | MEDIUM |
| 🔵 | Missing Request Correlation in JWT Claims Include trace/correlation IDs in JWT claims or headers to enable end-to-end request tracing across microservices — important for security incident investigation. Ref: OpenTelemetry Security Observability | LOW |
| 🟠 | JWT Token Logged in Plaintext Never log full JWT tokens. Log only non-sensitive metadata: jti, sub, iss, exp, aud. Full tokens in logs represent credential exposure in log aggregation systems. Ref: OWASP Logging Cheat Sheet · CWE-532 | HIGH |
| 🟠 | No Alerting on JWT Validation Failures Spikes in JWT validation failures (invalid signature, expired token, unknown kid) indicate active attacks. Implement real-time alerting on abnormal failure rates. Ref: OWASP Logging Cheat Sheet · NIST IR 7298 | HIGH |
| 🟡 | No Incident Response Plan for Key Compromise Define and document a key compromise runbook: how to rotate keys, invalidate existing tokens, notify affected users, and audit token usage from the compromise window. Ref: NIST SP 800-61 · OWASP Security Incident Management | MEDIUM |
| 🟡 | No Token Usage Anomaly Detection Monitor for token usage anomalies: simultaneous use from multiple IPs, unusual geolocations, or abnormal request frequencies — may indicate token theft or sharing. Ref: OWASP A09:2021 · Behavioral analytics | MEDIUM |
| 🔵 | No Token Issuance Audit Trail Maintain an audit log of token issuance (who issued, when, for what scope). This is critical for forensic investigation after a security incident. Ref: PCI DSS §10 · OWASP Logging Cheat Sheet | LOW |
| ⚪ | JWT Usage Metrics & Dashboards Implement metrics for: tokens issued/hour, validation failure rate by type, algorithm distribution, average token lifetime. Use these to detect drift from secure baselines. Ref: OWASP Security Observability | INFO |
| 🟠 | Insecure Token Storage on Mobile On iOS, store tokens in Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly. On Android, use EncryptedSharedPreferences or Android Keystore. Never use plain SharedPreferences or NSUserDefaults.Ref: OWASP MASVS-STORAGE-1 · iOS/Android Security Guide | HIGH |
| 🟠 | No Certificate Pinning on Mobile Without certificate pinning, a compromised root CA or MITM proxy can intercept JWT tokens in transit. Implement certificate or public key pinning for mobile API clients. Ref: OWASP MASVS-NETWORK-2 · RFC 7469 | HIGH |
| 🟡 | Token Exposure in WebView JavaScript Bridge In hybrid mobile apps, WebView JavaScript interfaces may expose JWT tokens to web content. Limit the JavaScript bridge surface and avoid passing tokens through it. Ref: OWASP MASVS-PLATFORM · Android WebView security | MEDIUM |
| 🟡 | Token Not Bound to Biometric / Device Auth For high-security mobile apps, bind token access to biometric authentication via the device's secure enclave (iOS Secure Enclave / Android StrongBox) using proof-of-possession keys. Ref: FIDO2 · OWASP MASVS-AUTH | MEDIUM |
| 🟡 | No Jailbreak / Root Detection On jailbroken/rooted devices, token storage protections are bypassed. Implement jailbreak/root detection as a defense-in-depth measure for high-security applications. Ref: OWASP MASVS-RESILIENCE · iOS/Android detection | MEDIUM |
| 🔵 | Token Remains in Memory After Use Tokens held in application memory may be extractable through memory dumps. Minimize in-memory token lifetime — zero out buffers after use where the language allows it. Ref: CWE-316 · OWASP MASVS-STORAGE | LOW |
| 🔴 | JWT Claim Injection / Pollution Test injecting additional claims via URL encoding, double encoding, or Unicode normalization. Some parsers may be tricked into accepting extra claims (e.g., injecting &admin=true in a form-encoded token).Ref: HTTP Parameter Pollution · Unicode normalization attacks | CRITICAL |
| 🔴 | ECDSA Signature Malleability ECDSA signatures are malleable — for every valid (r,s), (r, n-s) is also valid. If not normalized, attackers can produce alternative valid signatures for the same payload. Ref: CVE-2022-21449 Psychic Signatures (Java) · SEC1 | CRITICAL |
| 🔴 | RSA Bleichenbacher / Padding Oracle Attack If using RSA PKCS#1 v1.5 padding (RS256 with old libraries), test for Bleichenbacher-style oracle attacks that can recover the private key or forge signatures. Ref: CVE-2017-15361 ROCA · Bleichenbacher 1998 | CRITICAL |
| 🟠 | Confused Deputy via Token Forwarding When a frontend service forwards user tokens to internal APIs, the internal APIs may perform actions on behalf of the user without proper authorization checks (confused deputy pattern). Ref: OWASP API Security Top 10 2023 | HIGH |
| 🟠 | Token Substitution Attack If a service validates tokens but doesn't bind them to the specific request context (e.g., user, action), a valid token from one context may be substituted into another. Ref: RFC 8725 §2.2 · Confused Deputy attacks | HIGH |
| 🟠 | Online Timing Attack on Token Validation Measure response times for tokens with different signatures — timing differences may leak partial information about the secret. Ensure constant-time comparison at the network level too. Ref: CWE-208 · Bernstein Timing Attacks | HIGH |
| 🟡 | Decompression Bomb in Compressed JWT (JWE) JWE supports deflate compression. A maliciously crafted compressed payload can expand to gigabytes, causing DoS. Validate decompressed size before processing. Ref: RFC 7516 §4.1.3 · CWE-409 | MEDIUM |
| 🟡 | Oversized JWT Denial of Service Set maximum token size limits (recommended: 8 KB). Some parsers allocate memory proportional to input size — a crafted enormous JWT can exhaust server memory. Ref: CWE-400 · RFC 7518 §3 | MEDIUM |
| 🟠 | Algorithm Whitelist Enforced Server-Side The server must maintain an explicit algorithm whitelist. Never derive the algorithm from the token header. Hard-code expected algorithms in verification logic. Ref: RFC 8725 §2.1 · OWASP JWT Cheat Sheet | HIGH |
| 🟡 | Rate Limiting on Token Endpoints Token issuance and refresh endpoints must be rate-limited per IP and per user. Detect and block credential stuffing and brute-force attacks early. Ref: OWASP A04:2021 · RFC 6585 | MEDIUM |
| 🟡 | Token Revocation / Blacklist Mechanism Implement a jti-based revocation list (Redis, DB) for immediate invalidation on logout, password change, or security events. Revocation without jti is impossible. Ref: RFC 7009 Token Revocation · OWASP Auth Cheat Sheet | MEDIUM |
| 🟡 | Use JWE for Sensitive Payloads JWT only signs — it does not encrypt. For sensitive claims, use JWE (JSON Web Encryption / RFC 7516) to ensure confidentiality in addition to integrity. Ref: RFC 7516 JWE · OWASP Cryptographic Failures | MEDIUM |
| 🔵 | Clock Skew Tolerance ≤ 60 Seconds Allow at most 60 seconds of clock skew for exp and nbf validation. Larger windows increase the attack surface. Ensure all servers sync time via NTP/PTP. Ref: RFC 7519 §4.1.4 · RFC 7518 §3 | LOW |
| 🔵 | Cryptographically Random jti Values Use UUID v4 or ≥128 bits of CSPRNG output for jti. Avoid sequential integers, timestamps alone, or deterministic values — these are predictable and reusable. Ref: RFC 7519 §4.1.7 · NIST SP 800-90A | LOW |
| 🔵 | Enforce Maximum Token Size Define and enforce maximum JWT size (e.g., 8 KB) at the API gateway and application layer to prevent DoS via oversized tokens. Ref: CWE-400 · nginx / AWS API Gateway limits | LOW |
| ⚪ | Security-Focused Code Review of JWT Usage Conduct periodic code reviews specifically auditing JWT library usage: verify function choice, option flags, error handling, and claim validation patterns across all token-consuming services. Ref: OWASP Code Review Guide | INFO |
| ⚪ | Automated Dependency Scanning for JWT Libraries Integrate SCA tools (Dependabot, Snyk, OWASP Dependency-Check) into CI/CD to automatically detect and alert on vulnerable JWT library versions. Ref: OWASP A06:2021 Vulnerable Components | INFO |
| ⚪ | Developer Security Training on JWT Ensure all developers who implement or use JWT understand the top attack vectors (alg:none, algorithm confusion, HMAC bruteforce). Regular tabletop exercises help. Ref: OWASP Security Knowledge Framework | INFO |