SECURITY TESTING
JWT Testing Basics for QA.
Hands-on checks JSON Web Tokens explained in plain QA language — what a JWT is, what you can safely inspect, what to check, and what never to do with real tokens.
When to use this page: When a feature uses JWTs for login or API access and you want to know what QA can safely inspect and verify.
A JWT (JSON Web Token) is a token often used to prove who a user is and what access they may have. You do not need to forge or crack tokens to test them well. This page covers what a JWT is made of, what QA can safely inspect, the checks that matter, and the safety rules for handling real tokens.
// What is a JWT
A JWT is a compact, signed string passed between the client and server — usually in an Authorization header as 'Bearer <token>'. It carries claims about the user (who they are, what they can do, when the token expires). The signature lets the server confirm the token has not been tampered with. It is signed, not encrypted: anyone holding the token can read the header and payload, so it should never contain secrets.
// The three parts
| Part | What it holds | What QA reads it for |
|---|---|---|
| Header | Token type and signing algorithm. | Confirm the algorithm is as expected (e.g. not 'none'). |
| Payload | Claims: user id, roles, issuer, audience, expiry. | Check identity, roles and expiry — and that nothing sensitive is in here. |
| Signature | A cryptographic check the server verifies. | Not something QA decodes — its presence and verification is what matters. |
Decode a test token safely
Use the JWT Decoder utility to inspect a non-production test token's header and payload without sending it anywhere.
Open the JWT Decoder// What QA can safely inspect
- Expiry (exp) — is there one, and is it sensible for the use case?
- Issuer (iss) and audience (aud) — do they match the expected service?
- User id (sub) — does it match the logged-in test user?
- Roles / permissions claims — do they reflect the account's real role?
- Payload contents — is there any sensitive personal data that should not be there?
// Safe test ideas
- An expired token returns 401, not data.
- A missing token returns 401.
- A token belonging to User A cannot access User B's data.
- After a role change, a freshly issued token reflects the new role.
- After logout (or password change), the old token is rejected where the product requires it.
- The payload contains no passwords, card numbers or full personal records.
// What not to do with real tokens
Don't
- Do not try to forge or re-sign tokens outside an approved test scope.
- Do not paste real production tokens into public/online decoders.
- Do not include full tokens in bug reports — mask the middle of the value.
- Mask tokens in screenshots and logs.
// Evidence to collect
- The decoded header and payload claims relevant to the issue (with sensitive values masked).
- The request, response status and a note on which token/role was used.
- The expected vs actual behaviour (e.g. expected 401 for expired token, got 200).
- Environment and timestamp.
// Related resources