JWT Security Testing/Penetration Testing Checklist

No. Vulnerability/Test Description Testing Steps Expected Results Security Recommendations

1. Obtain a JWT token from the
Sensitive data such as application. No sensitive - Do not include sensitive information in
Sensitive passwords, keys, or internal IPs 2. Decode the JWT payload using information should be JWT claims.
Information are included in JWT payloads, tools like jwt.io or any Base64 present in the JWT - Store sensitive data securely on the
1
Disclosure in JWT which can be decoded client- decoder. payload. Presence server side.
Claims side, leading to exposure of 3. Inspect the claims for sensitive indicates a - Include only necessary, non-sensitive
sensitive information. information like passwords, hashes, or vulnerability. information in the JWT payload.
internal data.
1. Modify the JWT payload (e.g., - Always verify JWT signatures on the
The server does not verify the The server should
change "admin": false to "admin": server side.
JWT signature, allowing attackers reject tokens with
Signature Not true) without altering the signature. - Use trusted libraries that enforce
2 to modify the token payload invalid signatures.
Verified 2. Use the modified token to access signature verification.
without invalidating the token, Acceptance indicates
protected resources. - Avoid disabling signature verification
leading to unauthorized access. a vulnerability.
3. Observe if access is granted. options.
1. Modify the JWT header to set "alg":
- Disallow the use of the "none"
"none". The server should
The JWT header alg is set to algorithm.
2. Remove the signature part of the reject tokens with
Algorithm None "none", disabling signature - Explicitly specify and enforce
3 JWT. "alg": "none".
Vulnerability verification and allowing token acceptable algorithms.
3. Use the modified token to access Acceptance indicates
tampering. - Configure JWT libraries to reject tokens
the application. a vulnerability.
with "alg": "none".
4. Observe if access is granted.
Secret (Brute-force Attack) Weak 1. Obtain a valid JWT token. The secret should be
- Use strong, randomly generated
or commonly used secrets are 2. Use tools like Hashcat or John the strong and not
Weak HMAC Secret secrets with high entropy.
used with HMAC algorithms, Ripper with a wordlist to brute-force discoverable via
4 (Brute-force - Rotate secrets periodically.
making them susceptible to the HMAC secret. brute-force. Discovery
Attack) - Avoid default or easily guessable
brute-force attacks to discover 3. If the secret is found, sign a new indicates a
secrets.
the secret key. token with modified claims. vulnerability.

JWT Pentest Checklist v1.0 Created by: Chintan Gurjar

 1. Change the JWT header "alg" from
Changing the alg from RS256 to "RS256" to "HS256". The server should not - Enforce strict algorithm validation.
Algorithm HS256 causes the server to use 2. Use the public key as the HMAC accept tokens with - Do not mix symmetric and asymmetric
5 Confusion Attack the public key as the HMAC secret to sign the token. altered algorithms. algorithms.
(RS256 to HS256) secret, allowing attackers to 3. Use the modified token to access Acceptance indicates - Configure the server to accept only
forge tokens. the application. a vulnerability. expected algorithms.
4. Observe if access is granted.
- Include an exp (expiration) claim in
1. Check if the token includes an exp The server should
tokens.
Tokens lack an expiration (exp) claim. enforce token
Missing or Ignored - Set appropriate token lifetimes.
claim, or the server does not 2. Modify or remove the exp claim. expiration.
6 exp Claim (Token - Ensure the server validates the exp
enforce token expiration, 3. Use the token to access resources. Acceptance of tokens
Without Expiration) claim.
allowing indefinite token use. 4. Observe if access is granted without without exp indicates
- Implement token revocation
expiration enforcement. a vulnerability.
mechanisms if necessary.
Tokens intended for one service 1. Obtain a token for Service A with The server should - Enforce strict aud claim validation.
Cross-Service (aud claim) are accepted by "aud": "ServiceA". reject tokens with - Configure services to accept tokens
7 Audience Claim Not another, potentially leading to 2. Use the token to access Service B. incorrect aud claims. only for their intended audience.
Enforced unauthorized access across 3. Observe if access is granted without Acceptance indicates - Use separate signing keys for different
services. proper audience matching. a vulnerability. services if possible.
1. Modify the JWT payload (e.g., The server should - Ensure signature verification is
Modifying Data Testing if the server verifies the change user roles) without changing reject tokens with enforced.
8 Without Modifying signature by altering the payload the signature. tampered payloads. - Reject tokens with invalid signatures.
Signature without updating the signature. 2. Use the token to access resources. Acceptance indicates - Use libraries that enforce signature
3. Observe if access is granted. a vulnerability. checks by default.
1. Analyze client-side code for token Tokens should be - Generate tokens exclusively on the
Tokens are generated on the
Token Origin generation logic. generated server-side server side.
client side, exposing the secret
9 Exposure (Client- 2. Attempt to extract the secret key or only. Client-side - Do not expose secret keys or signing
key or signing process to
Side Generation) reverse-engineer the signing process. generation indicates a logic to clients.
attackers.
3. Use the key to forge tokens. vulnerability. - Securely store secrets and limit access.

1. Check the exp claim for token - Set appropriate token lifetimes based
Tokens have very long expiration Tokens should have
Excessive Token lifetime. on risk assessments.
10 times, increasing the risk window reasonable lifetimes.
Lifetime 2. Assess if the duration is - Use short-lived tokens with refresh
if compromised. Excessively long
appropriate. tokens if necessary.

JWT Pentest Checklist v1.0 Created by: Chintan Gurjar

 3. Attempt to use old tokens to access lifetimes indicate a - Balance usability with security needs.
resources. vulnerability.
1. Modify the JWT header to include a
- Do not trust keys supplied in tokens.
new jwk with an attacker-controlled
The server should not - Maintain a set of trusted keys on the
Embedding New Attackers include a new public public key.
accept untrusted server.
Public Key in key in the JWT header, tricking 2. Sign the token with the
11 keys. Acceptance - Validate tokens only against known
Header (CVE-2018- the server into using it for corresponding private key.
indicates a keys.
0114) signature verification. 3. Use the token to access the
vulnerability. - Ignore unrecognized key parameters in
application.
headers.
4. Observe if access is granted.
1. Modify the jku header to point to
an attacker-controlled URL hosting - Restrict jku URLs to trusted endpoints.
The server should not
malicious keys. - Use allowlists for JWKS URLs.
Manipulating the jku header to fetch keys from
JWKS Spoofing via 2. Sign the token with the - Validate TLS certificates when fetching
12 point to attacker-controlled keys, untrusted sources.
jku Header corresponding private key. JWKS.
allowing token forgery. Acceptance indicates
3. Use the token to access the - Avoid dynamic key retrieval based on
a vulnerability.
application. token headers.
4. Observe if access is granted.
1. Modify the kid value to include
path traversal sequences (e.g.,
"../../etc/passwd"). The server should - Validate and sanitize kid inputs.
Exploiting the kid (Key ID)
kid Parameter 2. Inject SQL commands if kid is used sanitize kid values. - Avoid using untrusted data in file paths
parameter to perform path
13 Injection and in database queries. Vulnerabilities or commands.
traversal, SQL injection, or
Directory Traversal 3. Inject OS commands if kid is used indicate improper - Use parameterized queries and input
command injection.
in system calls. validation. validation.
4. Observe server responses for errors
or unauthorized access.
1. Modify x5u or jku headers to point
to internal or attacker-controlled The server should not - Validate and restrict x5u and jku URLs.
Using x5u and jku headers to URLs. make unauthorized - Use allowlists for acceptable URLs.
SSRF via x5u and
14 perform Server-Side Request 2. Monitor if the server makes outbound requests. - Implement network egress controls.
jku Headers
Forgery attacks. requests to these URLs. SSRF indicates a - Avoid fetching remote resources based
3. Use DNS logging to detect SSRF vulnerability. on untrusted token headers.
attempts.

JWT Pentest Checklist v1.0 Created by: Chintan Gurjar

 1. Create a self-signed certificate and - Enforce strict certificate validation.
include it in the x5c header. The server should - Accept certificates only from trusted
Including attacker-controlled
2. Sign the token with the validate certificates sources.
x5c Header certificates in the x5c header to
15 corresponding private key. against trusted CAs. - Implement certificate pinning if
Certificate Injection bypass signature verification.
3. Use the token to access the Acceptance indicates appropriate.
application. a vulnerability. - Validate the certificate chain and
4. Observe if access is granted. revocation status.
1. Collect multiple JWTs signed with
ES256 using the same nonce.
Nonce reuse should - Use secure cryptographic libraries.
Reusing the same nonce (k 2. Use cryptanalysis techniques to
ES256 Nonce Reuse not occur. - Ensure unique, random nonces for
value) in ECDSA signatures can derive the private key.
16 Leading to Private Vulnerability exists if each signature.
lead to private key disclosure. 3. Sign new tokens with the private
Key Compromise private key is - Avoid manual implementation of
key.
recoverable. cryptographic algorithms.
4. Use forged tokens to access the
application.
1. Analyze jti values for patterns. Tokens should be
- Use secure, random jti values.
Predictable or 2. Attempt to reuse or predict jti unique and non-
The jti (JWT ID) claim is - Implement token replay protection on
Reused jti Claim values. reusable.
17 predictable or reused, allowing the server.
Leading to Replay 3. Replay tokens to see if they are Vulnerabilities
token replay or prediction. - Maintain a store of used jti values to
Attacks accepted. indicate improper
detect duplicates.
4. Observe if token reuse is possible. handling.
1. Use a token from one service to
The server should - Enforce strict scope and permission
Cross-Service Relay Tokens with broad scopes allow access another service.
enforce scope and checks.
Attack (Improper access to unauthorized services 2. Observe if access is granted without
18 permissions. - Validate claims like aud, scope, and
Scope due to improper claim validation. proper authorization.
Acceptance indicates roles.
Enforcement) 3. Check if scope or role claims are
a vulnerability. - Implement least privilege principles.
enforced.
1. Modify exp, nbf, and iat claims to The server should - Ensure the server checks all time-based
The server ignores time-based
Failure to Enforce invalid values. validate time-based claims.
claims, allowing tokens to be
19 Time-Based Claims 2. Use the token to access resources. claims. Acceptance - Reject tokens with invalid or expired
used outside their valid time
(exp, nbf, iat) 3. Observe if access is granted despite indicates a claims.
window.
invalid claims. vulnerability. - Synchronize server clocks.

JWT Pentest Checklist v1.0 Created by: Chintan Gurjar

 The server should - Use secure algorithms like RS256 or
1. Check the alg field for insecure
Using weak or deprecated accept only strong ES256.
Use of Insecure or algorithms.
algorithms in the alg header algorithms. - Avoid deprecated algorithms.
20 Deprecated 2. Attempt known attacks against
makes tokens vulnerable to Acceptance of weak - Keep cryptographic libraries updated.
Algorithms these algorithms.
attacks. algorithms indicates a - Enforce algorithm validation on the
3. Observe if tokens are accepted.
vulnerability. server.
1. Check for the presence and - Include the iat claim in tokens.
The server should
Missing or Invalid Tokens lack the iat claim or it is correctness of the iat claim. - Validate the iat during verification.
validate the iat claim.
21 iat (Issued At) set incorrectly, leading to 2. Modify iat to an invalid value. - Reject tokens with invalid iat values.
Acceptance indicates
Claim potential security issues. 3. Use the token to access resources. - Ensure accurate server time
a vulnerability.
4. Observe if access is granted. synchronization.
1. Review client-side code for token
storage locations. - Store JWTs in HTTP-only cookies.
JWTs are stored in localStorage Tokens should be
2. Test for XSS vulnerabilities that - Implement Content Security Policy
Insecure Client-Side or sessionStorage, making them securely stored.
22 could expose tokens. (CSP).
Storage of JWTs accessible via JavaScript and Exposure indicates a
3. Attempt to read tokens via injected - Prevent XSS vulnerabilities through
vulnerable to XSS attacks. vulnerability.
scripts. input validation and output encoding.
4. Observe if tokens can be exfiltrated.
- Implement token revocation strategies.
1. Log out and attempt to use the old The server should - Use short-lived tokens with refresh
Lack of Token No method to revoke tokens, so token. invalidate revoked tokens.
23 Revocation compromised tokens remain 2. Observe if access is still granted. tokens. Acceptance - Invalidate tokens upon logout or
Mechanism valid until expiration. 3. Attempt to revoke a token and test indicates a critical events.
if it's invalidated. vulnerability. - Consider token blacklisting or
introspection.
1. Monitor network traffic to see if
Tokens should be
Tokens are transmitted over tokens are sent over HTTP. - Enforce HTTPS for all communications.
JWT Used Without transmitted over
unsecured channels (HTTP), 2. Attempt to intercept tokens using - Implement HSTS headers.
24 Proper HTTPS HTTPS only. HTTP
exposing them to interception. tools like Wireshark. - Do not allow fallback to HTTP.
Protection transmission indicates
3. Observe if the application allows - Validate SSL/TLS configurations.
a vulnerability.
operation over HTTP.
Using JWTs for Session management - Align JWT usage with session
JWTs are used as session tokens 1. Analyze how JWTs are used for
25 Session should be secure and management best practices.
without considering sessions.
Management robust. Vulnerabilities - Consider using opaque tokens.

JWT Pentest Checklist v1.0 Created by: Chintan Gurjar

 Without Proper statelessness and security 2. Check for issues like lack of indicate improper - Protect tokens during storage and
Security implications. invalidation or improper refresh implementation. transmission.
mechanisms. - Implement proper session invalidation
3. Attempt session hijacking or replay and renewal.
attacks.
4. Observe if sessions can be
compromised.
- Use CSRF tokens or anti-CSRF
1. Craft a CSRF attack that triggers a
The server should measures.
request including the JWT.
Cross-Site Request JWTs stored in accessible prevent CSRF attacks. - Store JWTs in HTTP-only, SameSite
2. Observe if the server processes the
26 Forgery (CSRF) in locations are susceptible to CSRF Vulnerabilities cookies.
request.
JWT Authentication attacks. indicate lack of - Avoid storing tokens in accessible
3. Check for CSRF protections like
protections. client-side storage.
tokens or SameSite cookies.
- Implement server-side CSRF defenses.
1. Identify XSS vulnerabilities in the
application. Tokens should be
- Prevent XSS through input validation
JWTs in client-side storage are 2. Inject scripts to read and exfiltrate protected from XSS.
Stored JWTs and output encoding.
27 vulnerable to theft via XSS JWTs. Vulnerabilities
Vulnerable to XSS - Store tokens in HTTP-only cookies.
attacks. 3. Use stolen tokens to access the indicate improper
- Implement CSP to mitigate XSS risks.
application. storage.
4. Observe if access is granted.

JWT Pentest Checklist v1.0 Created by: Chintan Gurjar