Browse the Knowledge Hub32 resources
Test cases
Password reset test cases: an authentication bypass you built on purpose
Twenty six cases covering token expiry, single use enforcement, account enumeration, rate limiting, session invalidation after reset, host header injection, single sign on accounts and two factor interaction. Every case here protects a route into the account.
All 26 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
26 worked examples
Request a reset for a registered address
TypeFunctionalPriorityHigh- Test data
- Email of an active account
- Expected result
- Neutral confirmation shown, reset email delivered with a single use link, previous unused tokens for that account invalidated.
Request a reset for an address that is not registered
TypeSecurityPriorityHigh- Test data
- Email with no account
- Expected result
- The same neutral confirmation, the same status code and a comparable response time. No email sent. The response must not reveal whether the account exists.
Compare response timing between existing and unknown addresses
TypeSecurityPriorityHigh- Test data
- Twenty requests of each, timed
- Expected result
- No usable timing difference. Sending mail synchronously for real accounts only is a common and measurable leak.
Complete a reset with a valid token
TypeFunctionalPriorityHigh- Test data
- Fresh link, compliant new password
- Expected result
- Password changed, token consumed, confirmation email sent to the account owner, and the user can sign in with the new password immediately.
Reuse a token that has already been used
TypeSecurityPriorityHigh- Test data
- Same link submitted a second time
- Expected result
- Refused as already used. The password is not changed again.
Use a token after it has expired
TypeBoundaryPriorityHigh- Test data
- Just inside the expiry window, then just outside it
- Expected result
- Accepted inside, refused outside with an offer to request a new link. Expiry should be short, typically under an hour.
Use a tampered or fabricated token
TypeSecurityPriorityHigh- Test data
- One character altered, a token from another account, a random string
- Expected result
- Refused with the same message in every case. Tokens must be long, random and compared in constant time.
Request several resets in a row
TypeSecurityPriorityHigh- Test data
- Five requests for the same address in a minute
- Expected result
- Only the most recent token remains valid, and requests are throttled with a stated wait. Older tokens are invalidated rather than left live.
Rate limit reset requests across accounts
TypeSecurityPriorityHigh- Test data
- Requests for fifty different addresses from one source
- Expected result
- Throttled or challenged. Without this your service is a mail sending tool for someone else.
Brute force the reset endpoint with guessed tokens
TypeSecurityPriorityHigh- Test data
- Two hundred submissions with random tokens
- Expected result
- Blocked or challenged after a small number of failures, and the attempts are logged.
Verify all other sessions are invalidated after a reset
TypeSecurityPriorityHigh- Test data
- Sign in on a second browser, then reset the password from the first
- Expected result
- The second session can no longer act. This is the case that decides whether a reset actually evicts an attacker, and it is the one most often missing.
Verify API tokens and remember me cookies after a reset
TypeSecurityPriorityHigh- Test data
- Long lived cookie and a personal access token issued before the reset
- Expected result
- Handled per a documented policy, and the policy is stated to the user. A remembered device that survives a compromise reset defeats the purpose.
Reject a new password that fails policy
TypeNegativePriorityHigh- Test data
- Too short, breached password, the account email as the password
- Expected result
- Refused with the rule stated, and the token remains valid so the user can try again.
Reject reuse of the current or a recent password
TypeSecurityPriorityMedium- Test data
- The existing password, then a password from the stated history window
- Expected result
- Refused if history rules exist, with the rule explained rather than a generic error.
Confirm password mismatch on the reset form
TypeNegativePriorityMedium- Test data
- New password and confirmation differing
- Expected result
- Blocked with a field level message. Token not consumed.
Reset for an account that is locked, suspended or unverified
TypeStatePriorityHigh- Test data
- Each account state in turn
- Expected result
- Behaviour is deliberate and documented: a reset should not silently unlock a suspended account, and a locked account should be released only if that is the intended design.
Reset an account that uses single sign on
TypeStatePriorityHigh- Test data
- Account created through an identity provider with no local password
- Expected result
- Directed to the provider rather than being given a local password that creates a second, weaker way into the account.
Reset when two factor authentication is enabled
TypeSecurityPriorityHigh- Test data
- Account with an authenticator app enrolled
- Expected result
- The second factor is still required after the reset. A reset must not be a route around two factor authentication.
Change the email address after requesting a reset
TypeStatePriorityHigh- Test data
- Request a reset, change the account email in another session, then use the link
- Expected result
- The token is invalidated by the address change, so a link sent to a previous address cannot be used.
Check the reset link for host header or parameter injection
TypeSecurityPriorityHigh- Test data
- Forged Host header and any redirect parameter on the request
- Expected result
- The link in the email always points at your canonical domain. Host header poisoning that sends a valid token to an attacker domain is a real and repeatedly exploited defect.
Check the token is not leaked through the referrer or analytics
TypeSecurityPriorityHigh- Test data
- Open the link, then trigger a third party request from the page
- Expected result
- The token is not present in outbound referrer headers, analytics payloads or session recordings. Where possible it is exchanged for a short lived server side state on first load.
Verify email content and deliverability
TypeFunctionalPriorityHigh- Test data
- Delivery to major providers, plus plain text and HTML rendering
- Expected result
- Arrives without going to spam, renders in both formats, states the expiry, names the requesting product, and includes a note about what to do if the request was not made by the recipient.
Behaviour when the email provider fails
TypeNegativePriorityHigh- Test data
- Mail service erroring or timing out
- Expected result
- The user still sees the neutral confirmation, the failure is logged and retried, and no error message reveals whether the address existed.
Open the reset link on a different device or browser
TypeCompatibilityPriorityHigh- Test data
- Request on desktop, open the link on mobile
- Expected result
- Works. The flow must not depend on session state from the requesting browser, which is a common failure when the token is tied to a session cookie.
Verify the reset notification reaches the owner
TypeFunctionalPriorityHigh- Test data
- Complete a reset and check the account email
- Expected result
- A confirmation of the change is sent, including time and approximate location if available, so an unauthorised reset is visible to the real owner.
Complete the flow by keyboard and screen reader
TypeAccessibilityPriorityHigh- Test data
- Keyboard only, then NVDA or VoiceOver
- Expected result
- Fields labelled, errors announced and associated with their field, password visibility toggle reachable and announced, and paste permitted so password managers work.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Everything about token validity, reuse, enumeration and session invalidation is High. This flow is a deliberate authentication bypass, so a weakness here is an account takeover.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Reset in one browser, act in another
If the second session still works after a reset, the flow does not do the one job it exists for.
Check other sessions die
Sign in twice, reset from one, then act from the other. A reset that leaves sessions alive cannot evict an attacker.
Compare the two responses
Registered and unregistered addresses must produce the same message, status and timing.
Forge the Host header
If the emailed link is built from the request host, an attacker can have a valid token sent to their own domain.
Open the link elsewhere
Request on desktop, open on mobile. Tokens tied to the requesting session break for most real users.
The reset cases that decide account security
Session invalidation is the most commonly missing case, and it defeats the purpose of the whole feature when it is absent. The usual reason a user resets a password is that they believe someone else has access. If existing sessions, remember me cookies and API tokens survive the reset, the intruder keeps their access and the user believes they are safe. Test with two live sessions and assert the second one is evicted.
Host header injection is the classic technical flaw here. Where the reset link is constructed from the incoming request host rather than a configured canonical domain, an attacker can trigger a reset for a victim and have the email arrive containing a link pointing at their own server, which captures a valid token. Send a forged Host header and read the resulting email.
Enumeration on this flow is easier to leak than on login, because the honest message is tempting. Any difference in wording, status code or response time between a registered and an unregistered address hands over an account list. Sending mail synchronously only for real accounts creates a timing difference you can measure with twenty requests.
Two cases worth adding that are rarely written: what a reset does to an account created through single sign on, where issuing a local password quietly creates a second and weaker way in, and whether a reset bypasses two factor authentication. Both are design decisions that need asserting rather than assuming.
Suggest an improvementAuthentication under review?
QAble tests login, reset, session handling and two factor flows together, including the API level cases that never appear in the interface.
Security testing servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for checkout and payment
Test cases30 cases including 3D Secure, declines, timeouts, duplicate charges, idempotency, refunds and partial captures.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for OTP verification
Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.Test cases for push notifications
Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- OWASP ASVS verification requirements for authentication, session and access control.
- OWASP Web Security Testing Guide test procedures for enumeration, injection and authorisation.
- OWASP Top 10 the risk categories these security cases map to.
Want account recovery tested like an attack path?
QAble covers authentication and session security with ISTQB-certified engineers. Start with a free QA audit of your product.