Account Takeover Bug Bounty Checklist
Account takeover is an outcome, not a bug class. The path might start in password recovery, OAuth linking, a leaked session, or a support workflow. Hunters miss good chains by testing each screen in isolation. Build a map of every action that can establish, recover, or transfer account control.
Use two accounts you own, separate browser profiles, and two inboxes. Label them attacker and victim. This simple setup prevents the classic mistake of proving that one account can modify itself.
Recovery first
Request password resets repeatedly and compare tokens. Check length, randomness, expiry, single use, and whether issuing a new token invalidates the old one. Change the email or user identifier between the request and confirmation steps. Does the token stay bound to the original account?
Inspect host-derived links, duplicate email parameters, and API fields hidden by the UI. A reset message sent to your attacker inbox for the victim account is high-signal evidence. Do not test real users or brute-force token space.
Ask what happens after reset. Existing sessions may remain alive. MFA may disappear. Recovery codes may regenerate. Those are separate consequences that can increase impact.
Session and identity checklist
- Does logout revoke the server-side session or only delete a browser cookie?
- Does changing a password revoke other devices?
- Can a pre-authentication session survive login without rotation?
- Are session cookies scoped to an unsafe parent domain?
- Can an API token outlive account deletion or credential reset?
- Does “remember this device” bypass MFA after an email change?
Plant a harmless profile canary, such as ATO-CHECK-4821, and use it to identify which account each browser controls. Cookie names alone can lie when several subdomains share state.
OAuth and account linking
Test login and linking as different operations. A provider email matching a local email should not silently link accounts without a verified assertion and a deliberate authenticated step. Change state, remove it, reuse it, and swap authorization responses between your two browser profiles. Verify redirect_uri exactly.
Watch for orphan flows: connect Google while logged in, log out before the callback, then complete it in another session. Which account receives the link? Race the unlink and callback only with your own identities.
Sensitive account changes
Email change often becomes the shortest takeover route. Check whether confirmation goes to the old address, new address, or both; whether the link is bound to the session that requested it; and whether password or MFA is required. Try a stale confirmation link after requesting a second change.
For MFA, test recovery-code reuse, enrollment without password confirmation, method downgrade, backup email changes, and API endpoints the UI no longer exposes. A UI button requiring re-authentication means little if the underlying request accepts an old session directly.
Do not ignore support and invitation flows. Organization invitations, delegated admins, family accounts, and helpdesk recovery can transfer control without touching the password.
The takeover proof
A persuasive report ends with the attacker profile controlling the victim test account in a fresh browser. Show access to a planted canary and one reversible protected action. Stop there. Do not change production billing, expose private messages, or lock anybody out.
Write each precondition plainly: victim click, known email, active session, compromised inbox, or no interaction. Severity changes dramatically when one of those assumptions changes. “ATO” in the title cannot rescue a chain that needs the victim's password and MFA code.
OWASP's password-reset testing guide is a sturdy baseline. Treat this checklist as a chain builder: identify where identity is asserted, where it is bound, and where the application forgets to check again.