Overview
Password reset flows are a frequent source of bug bounty findings, so testing them (safely, with test accounts) is high-value. This lesson covers reset-flow testing.
Learning objectives
- Identify reset-flow weaknesses to hunt for.
- Explain safe, in-scope reset testing.
- Connect reset flaws to account takeover.
Core concept
Reset-flow testing checks a password-reset process for the weaknesses covered earlier (web-security authentication, ethical-hacking auth-testing): predictable/non-expiring/reusable tokens, account enumeration in reset responses, tokens not bound to the correct account, manipulable reset links (e.g. via a spoofable host header), and missing session invalidation on reset. Because a reset can set a new password, flaws here can enable account takeover — making reset flows a high-value bug bounty target. Testing is done safely, using the researcher's own test accounts, never against real users.
How it works
Using test accounts, the researcher examines the reset flow: requesting resets to compare responses for existing vs non-existent accounts (enumeration); inspecting reset tokens for predictability, expiration, and single-use; checking whether a token is tied to the account being changed (or could affect another); testing how the reset link is generated (e.g. whether inputs like the host header influence it); and verifying sessions invalidate on reset. All of this uses the researcher's own test accounts — never resetting or accessing real users' accounts, which would be harmful and violate program rules. Confirmed weaknesses are documented with evidence and fixes.
Practical example
Testing an in-scope reset flow with test accounts, the researcher finds the reset response differs for a real vs unknown email (enumeration) and that reset tokens do not expire. Both are documented as findings with fixes (uniform responses; short-lived single-use tokens). The researcher confirms these using only their own test accounts and never attempts to reset or take over any real user's account. Reset flaws like these can enable account takeover, making them valuable findings — identified responsibly.
Cybersecurity relevance
Reset flows are a common account-takeover vector and thus a high-value, frequently-rewarded bug bounty area — flaws include weak tokens, enumeration, unbound tokens, manipulable links, and missing session invalidation (mapping to the web-security reset-flow defenses). Because a reset can grant account access, testing must stay strictly safe and in-scope: use the researcher's own test accounts, never real users', per program rules. This applies the earlier authentication knowledge to bug bounty. Findings drive secure reset design and are often significant.
Common mistakes
- Testing reset flows against real user accounts instead of the researcher's own test accounts.
- Overlooking enumeration in reset responses or token weaknesses (predictable/non-expiring/reusable).
- Not checking token-account binding, link generation, or session invalidation on reset.
Key takeaways
- Reset-flow testing hunts for weak tokens (predictable/non-expiring/reusable), account enumeration, unbound tokens, manipulable reset links, and missing session invalidation.
- Because a reset can set a new password, flaws can enable account takeover — a high-value bug bounty area (mapping to web-security reset defenses).
- Test safely with the researcher's own test accounts, never real users', per program rules; report findings with evidence and fixes.
Check your understanding
- What reset-flow weaknesses can lead to account takeover?
- Why must reset testing use the researcher's own test accounts rather than real users'?