How to Find Password Reset Vulnerabilities and Account Takeover
Password recovery is an alternate authentication system. It deserves the same scrutiny as login because it creates credentials, changes account ownership, and often crosses email, API, mobile, and support workflows.
Use only email addresses and accounts you control. Never request reset messages for real users at scale.
Map the complete recovery flow
Record the request endpoint, response, email link, token format, expiration, final password-change request, and post-reset session behavior. Repeat with two test accounts so you can swap values safely.
Identify which data binds the flow together: username, email, user ID, reset token, browser cookie, and any one-time code.
Test token quality and lifecycle
A reset token should be generated with cryptographic randomness, expire quickly, work once, and be bound to exactly one account and purpose.
Check whether a token:
- remains valid after use
- remains valid after requesting a newer token
- works for another test account when the username or ID is changed
- appears in analytics, referrer URLs, logs, or third-party requests
- can be redeemed without the browser state that initiated recovery
Do not attempt to brute-force production tokens. If the format appears weak, explain the entropy concern and request permission for controlled validation.
Test identity binding
Capture the final reset request and change account identifiers independently. Applications sometimes validate a token and then trust a separate user ID from the request body. Also test duplicate parameters and differences between JSON, form, and query parsing.
A clear finding proves that a token issued for account A changes account B, using two accounts you own.
Host header and link generation
If the application builds reset URLs from the incoming Host or proxy headers, an attacker may make the email point to an attacker-controlled domain. Test with a domain you control and your own inbox. Also inspect forwarded host headers only when the program allows them.
The impact is strongest when the victim would see a convincing reset email and the token is included in the poisoned URL.
Enumeration and abuse controls
Compare status codes, body length, timing, and rate limits for existing and nonexistent test addresses. Recovery responses should be consistent. Rate limits should consider account, IP, device, and delivery channel without allowing trivial bypass through header changes.
Enumeration alone is usually lower severity, but it can amplify credential stuffing or targeted phishing.
After the password changes
Verify whether existing sessions, remembered devices, API tokens, and recovery codes are invalidated according to the product's policy. A password reset that leaves an attacker's active session alive can prevent the victim from regaining control.
Reporting and remediation
Provide the two-account setup, sanitized email, exact requests, token timeline, and resulting account state. Distinguish inconvenience from takeover.
Defenses include random single-use tokens, server-configured canonical origins, short expiration, strict account binding, generic responses, layered throttling, session revocation, and user notifications for recovery events.
Original Bugflare guide informed by PortSwigger's authentication and password-reset security material.