Account-Takeover Chains from Access Control Gaps

Individually, access control gaps can look minor: a read-IDOR here, a role flip there, a mass-assignment on a settings form. Chained, they take over accounts. This spoke is about combining the pieces from the rest of the cluster, reach plus a write plus a pivot, into full control of another account. It is where access control testing pays its biggest dividend.

Why small gaps compound

A single gap is usually bounded. A read-IDOR leaks one record. A self-service role field only touches your own account. The power comes from combining a gap that gives you reach (to a victim's object) with a gap that gives you a write (to change it) and a mechanism that turns that write into control (a reset, a login, an impersonation). Chaining is the craft of lining those three up.

Stacking an IDOR into an email change

The cleanest chain starts with a write-IDOR on a recovery field:

PUT /api/users/52/email   {"email":"[email protected]"}

If that write is not authorized against ownership, you change the victim's email to one you control, then run the normal password-reset flow. The reset lands in your inbox, and the account is yours. A write-IDOR on an email or phone field is often a one-step takeover.

Flipping a role then resetting credentials

Where a privilege escalation or mass assignment gap lets you grant yourself admin, use that privilege to reach the account tooling admins have: reset another user's password, disable their protections, or impersonate them. The role flip is the enabler, and the admin account-management feature is the weapon.

Combining mass assignment with a horizontal gap

Mass assignment and a horizontal reference gap stack neatly. Use a horizontal gap to target another user's object, then mass-assign a field that seizes it:

PUT /api/accounts/52
{"ownerId":<your-id>,"email":"[email protected]"}

One request both points at the victim (horizontal) and rewrites ownership and recovery details (mass assignment), collapsing two gaps into a takeover.

Using an admin action reached via a header override

A platform misconfiguration bypass can supply the privileged action a chain needs. If a header override or method trick reaches an admin-only endpoint, that endpoint may itself change another user's credentials or role:

GET /public HTTP/1.1
X-Original-URL: /admin/users/52/reset-password

The bypass gets you to the admin action, and the admin action completes the takeover.

Building the chain

The method is to inventory every gap you found, then ask which one controls a recovery channel or a role, because that is the pivot. Work backwards from "what would give me the account" to "which gaps get me there," and connect them. The most severe access control findings are almost always chains, not single bugs.

The fix and the mindset

The defense is the same discipline that stops each link: authorize every object on every request, bind write fields with an allow-list, protect recovery-channel changes with re-authentication, and never trust client-supplied roles or headers. Break the chain anywhere and the takeover fails. Everything you need to find and assemble these chains is in the cheat sheet. Practice building one end to end on a free live target.