Review password reset as an account state change
Map reset requests, token use, password replacement, and session handling. Test expiry, reuse, enumeration, and recovery without real customer accounts.
Password recovery can change who controls an account without an ordinary login. Review the complete transition, from requesting a message to handling existing sessions after a password changes. Use dedicated test inboxes and synthetic users. Do not request recovery messages for unrelated people.
OWASP's forgot-password guidance covers consistent responses and single-use, expiring recovery tokens. The state record below helps turn those properties into testable application behavior.
Identify the irreversible step
Separate requesting recovery from proving possession of a valid token. A request alone should not change the password or disable the account. Record which operation consumes the token and commits the new password.
| State or event | Expected account effect | Test record |
|---|---|---|
| Recovery requested | No password change | Existing login still follows policy |
| Invalid or expired token | No replacement | Controlled failure with no secret disclosure |
| Valid token submitted | One permitted replacement | Token consumption and password write agree |
| Same token reused | No second replacement | Replay fails after first success |
| Concurrent submissions | At most one accepted transition | Final account state is unambiguous |
Use a safe token reference in evidence. Never store the actual recovery link in a public issue or screenshot.
Check the message and browser path
Compare responses for a synthetic existing account and a synthetic unknown account. Review status, text, and timing behavior without running a broad enumeration test. Apply abuse limits to message requests so the flow cannot send unbounded email.
Build links from trusted application configuration rather than an arbitrary request host. Check the destination after proxies and redirects. Prevent the token from appearing in analytics, referrer data, or verbose request logs. Keep the recovery page free of unnecessary third-party requests.
Define what happens to sessions
Record whether successful recovery ends existing sessions and how that decision is enforced. Test an already-open session after the password change, including API calls and live connections where relevant. Do not infer server-side invalidation merely because the recovery page redirects to login.
Notify the account through the documented channel and provide a controlled response path for an unexpected change. Save the tested build, token lifetime policy, reuse result, and session outcome. A complete review proves the intended transition for this flow; it does not establish the security of separate MFA recovery or customer-support overrides.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.