# ID-keyed account reset and update IDOR

Account reset, MFA, or profile endpoints keyed by client-supplied user id without ownership check

_Area: Web access control and IDOR. Seen in 3 disclosed reports; 2 confirmed bounties: $5,000 and $6,000; latest 2020-11-18. Updated 2026-10-23._

## How it works
An endpoint that resets a password/MFA factor or edits profile/contact data selects the target account from a client-supplied identifier (a numeric `id`, a URL path segment) instead of from the authenticated session. The code assumes that whoever reaches the endpoint is acting on their own account, or that the id is trustworthy because it came from the user's own settings page. Neither holds: the id is attacker-controlled and the session is never compared against it. Because the ids are sequential, one valid request reveals the shape of every other account's request.

## Where it shows up
- Password-reset, MFA-reset, email-change, or phone-change handlers that take a user id in the body or path.
- Settings pages whose request body carries an `id` even though the session already identifies the user.
- Logged-out checkpoint/verification/interstitial pages that render update forms for a specific account.
- Third-party SaaS consoles (tag managers, analytics) with cross-account container or user-management endpoints.
- Sequential numeric identifiers anywhere in the above.

## How to review
For each such endpoint, find where the target account is chosen and confirm it is derived from the authenticated principal, not the request. The invariant: the account being modified must equal the session's account, or the caller must hold an explicit privilege over it, checked server-side on every request. Test by changing the id in a captured request and confirming rejection; also confirm the endpoint refuses unauthenticated callers. Treat any endpoint that accepts an id it does not need as suspect.

## Variants seen
- IDOR in a third-party tag manager resetting any user's password/MFA and editing other accounts' containers [E1](https://bugbountylibrary.com/r/h1%3A217739.md).
- Unauthenticated checkpoint pages keyed by sequential user id exposing email/phone update for locked accounts [E2](https://bugbountylibrary.com/r/blog%3Aarneswinnen-net-2016-03-how-i-could-compromise-4-locked-instagram-accounts.md).
- Email-change endpoint trusting a body `id` parameter, chained to password reset for takeover [E3](https://bugbountylibrary.com/r/h1%3A950881.md).

## Impact and severity
Full account takeover in all three cases: rebind contact info, trigger reset, own the account [E2](https://bugbountylibrary.com/r/blog%3Aarneswinnen-net-2016-03-how-i-could-compromise-4-locked-instagram-accounts.md)[E3](https://bugbountylibrary.com/r/h1%3A950881.md); in E1 the same flaw reached stored XSS across many domains via a shared tag container. Severity is high because the primitive is a single request and sequential ids make it mass-exploitable; shared third-party components widen blast radius beyond one tenant [E1](https://bugbountylibrary.com/r/h1%3A217739.md).

## Evidence
- E1: https://bugbountylibrary.com/r/h1%3A217739.md
- E2: https://bugbountylibrary.com/r/blog%3Aarneswinnen-net-2016-03-how-i-could-compromise-4-locked-instagram-accounts.md
- E3: https://bugbountylibrary.com/r/h1%3A950881.md