Test token handling by replaying tokens the API should refuse: an expired one, one with an altered signature, one used after logout, and one used after a password or role change. Each replay should return 401 or 403. Any 200 response means the API is not validating or revoking tokens properly.
Why this matters
OWASP API2:2023 says an API is vulnerable if it fails to validate token authenticity or expiration, or accepts unsigned or weakly signed JWTs. It also lists letting users change sensitive settings without confirming a password. Stolen tokens are only as useful as the API lets them be.
Definitions
An access token is a credential presented on each call. Expiry limits how long it works. Revocation ends it early, for example on logout. A stateless token is validated locally, so revocation needs extra design, such as short lifetimes or a deny list.
The test plan
| Test | How | Expected |
|---|---|---|
| Expired token | Wait out a short lifetime or craft one in a test environment | 401 |
| Altered payload | Change a claim, keep the old signature | 401 |
| Unsigned token | Remove the signature or set no algorithm | 401 |
| Wrong audience or issuer | Use a valid token from another service | 401 or 403 |
| After logout | Save a token, log out, replay it | 401 if revocation is promised |
| After password change | Replay an older token | 401 under your policy |
| After role removal | Replay a token that carried the old role | Access removed, within your stated delay |
| Refresh token reuse | Use a refresh token twice | Second use refused if rotation is on |
| Token in URL | Send it as a query parameter | Refused, since OWASP flags tokens in URLs |
Deeper JWT checks are in JWT validation checklist for API resource servers.
Decide your revocation promise first
Many systems cannot revoke an access token instantly, and that is a design choice. State the maximum delay, for example the token lifetime, and test that this delay holds. A promise you have not written down cannot be tested.
Sensitive actions
Add a test where a bearer token alone tries to change an email address or password. OWASP's scenario shows why: an attacker with a stolen token changes the email, then uses password reset to take over the account. The API should require re-authentication.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how authenticated testing depends on a valid session.
Quick check
Should logout invalidate a JWT?
Only if your design supports it. Short lifetimes with refresh rotation are common. Whatever you choose, document it and test it.
Can I run these tests against production?
Prefer staging with test accounts. Replaying tokens is low risk, but password change tests alter account state.
Safeguard policies and gates can block merges that fail your checks, and the free scan at gold.safeguard.sh/scan covers dependency risk in auth libraries.
Sources
Last reviewed: 19 October 2026.
