Test Cases for Forgot Password: Reset Flow Checklist

A password reset link is a temporary login credential delivered through a channel the application does not fully control. If it can be guessed, replayed, leaked to analytics, or used after an account change, the “forgot password” feature becomes an account-takeover path. If the flow reveals which email addresses exist, it also becomes an enumeration tool.

Testing must cover the entire credential lifecycle: request, neutral response, secure delivery, token redemption, password change, session handling, notification, and audit. Treating the email screen and reset form as separate pages misses the security contract between them.

Model the Reset Threats and Account States

Prepare active, unverified, disabled, locked, federated-only, and nonexistent accounts. Include accounts with mixed-case email addresses, aliases, internationalized addresses if supported, and multiple sessions. Decide which states may reset a local password and what neutral response every other state receives.

Record the token lifetime, one-time-use policy, password rules, session revocation behavior, rate limits, and notification requirements. Clarify whether requesting a new token invalidates older links. The answer becomes an expected result, not an assumption made during test execution.

Keep the Request Response Private

Submit a registered email, unknown email, disabled account, malformed email, empty value, different casing, and whitespace around a valid address. The page should validate obvious format errors locally, but valid-looking account states should receive a neutral message such as “If an account exists, we sent instructions.”

Compare status codes, bodies, headers, and visible timing. The goal is not mathematically identical response time, but the server should avoid a large, reliable difference caused by sending email synchronously only for known accounts. API responses and analytics events must not disclose userExists, provider type, lock status, or internal user IDs.

Repeat the request rapidly from one browser, multiple accounts, and changing client addresses. Verify limits exist per account or destination as well as per network source, since network-only limits are easy to distribute and can block shared users unfairly.

Inspect Delivery Without Leaking the Token

Verify the message reaches the intended address, identifies the product, explains the request, states the expiry, and provides a safe action for an unintended request. Links should use HTTPS and the expected owned host. The token must not be duplicated in visible text, tracking URLs, third-party image requests, or analytics parameters.

Open the link in the same browser, another browser, private mode, and a mobile email client. Follow redirects and inspect whether the token remains in browser history or referrer data after the reset page loads. Prefer exchanging or removing sensitive query data before loading unrelated resources.

Request several messages and identify each token. Test delivery delay, duplicate delivery, bounced mail, and a user clicking an older message. Support and UI wording must not promise delivery that the email provider has not confirmed.

Enforce Token Expiry, Scope, and One-Time Use

Redeem a valid token just before and just after expiry using a controlled clock. Change one character, truncate it, append data, use the wrong account context, and attempt a token from another environment. Every invalid variant should fail safely without revealing which part was correct.

Open one valid link in two browsers and submit both forms concurrently. Exactly one password change should commit. Reuse the winning token after success, use browser back, and resubmit the form. The consumed token must stay invalid even if a later step, notification, or redirect fails.

If a new request invalidates earlier tokens, prove that order. If multiple tokens remain valid, verify consuming one invalidates the rest when policy requires it. Tokens should be scoped only to password reset and must not authorize profile reads or other account actions.

Validate the New Password as a Credential

Test minimum and maximum length, just outside each limit, allowed Unicode, spaces, pasted values, and policy rules such as breached-password checks. Confirm both fields compare the actual values and that show-password controls do not expose the credential unexpectedly. Error messages should explain the rule without echoing the password.

Try the existing password if reuse is restricted, a recently used password if history is enforced, and a value that becomes invalid while an external policy check is unavailable. Define whether the service fails closed, offers a retry, or applies a documented fallback. The form should preserve no password after refresh, navigation, timeout, or server error.

After success, verify login with the new password and rejection of the old one. Check the credential's stored state through an approved test seam, never by reading or comparing raw passwords. Password-change logs must not contain the new value or the reset token.

Decide What Happens to Existing Sessions

Reset the password while the account is signed in on web, mobile, and a remembered device. According to policy, revoke all sessions, all except the resetting session, or none. Validate access tokens, refresh tokens, trusted-device cookies, API keys, and active WebSocket connections separately because they may use different stores.

Test a sensitive action from an old session immediately before and after reset. A revoked browser should not remain apparently signed in until its next page load. The next request should fail clearly and redirect to authentication without losing unsaved public data unnecessarily.

Send a security notification after successful change and include recovery guidance without including the password or token. A failed email notification must not roll back a completed password change or make the token reusable.

Change the account email or phone after requesting a reset and before redemption. The product should define whether the old destination's token remains valid, is revoked, or requires additional proof. Test recovery for an account whose delivery address is no longer accessible without creating a support shortcut that bypasses identity verification. Administrative recovery actions need stronger authorization, an audit reason, and notification through every still-trusted channel.

Resist Abuse and Cross-Site Manipulation

Verify CSRF defenses on reset request and redemption where the application's architecture requires them. Test whether an attacker can prefill or replace the destination account while a victim supplies a new password. The token must be bound to the intended account on the server, not to an editable hidden field.

Check framing protections, safe redirect handling, host-header behavior in generated links, and open redirects after success. Submit script-like text and oversized values to confirm validation and logs treat them as data. Error pages must not expose stack traces, token hashes, provider details, or account metadata.

Rate limits should return useful but neutral feedback and recover after the intended window. A flood against one account should trigger monitoring without sending an unlimited number of messages. Test that CAPTCHA or risk challenges, if introduced, remain accessible and do not reveal account existence.

Recover From Service and Browser Failures

Simulate email-provider failure, token-store timeout, password-service rejection, database failure during consumption, and notification failure after commit. The system must not report success before the credential changes, and it must not leave a valid token after a committed change.

Refresh each page, use browser back, open multiple tabs, and submit twice on a slow connection. Preserve understandable state without preserving password fields. If a valid token was checked when the form loaded but expires before submission, the server must reject it and offer a safe route to request another.

Audit records should distinguish request, throttle, successful redemption, invalid redemption, and session revocation while minimizing personal data. Correlation IDs can connect evidence without storing credentials.

Build a Security-Focused Regression Set

Automate the full success route through a captured test inbox or approved delivery stub. Add unknown-account privacy, expiry boundaries with a controlled clock, token replay, concurrent redemption, old-password rejection, and session revocation. Keep raw tokens masked in test reports and CI logs.

Run browser-level checks for link navigation, password-manager behavior, focus, error association, and responsive layout. Use manual review for email-client rendering and external security testing for token leakage and host manipulation.

Close the audit with an adversarial recovery chain. Let one user regain access while an observer probes another identity, race two redemptions of the same token, then try the old password and existing sessions. The flow is safe only if privacy holds, exactly one redemption commits, and every previous credential follows the documented revocation policy.