Authorization disclaimer. This walkthrough is exclusively for the intentionally vulnerable PortSwigger Web Security Academy lab linked below. Only test systems you own or are explicitly authorized to assess.

Overview

The account page accepts a username in ?id= and returns that user’s record without checking whether it belongs to the authenticated session. This is a classic IDOR/BOLA condition.

PortSwigger user-controlled account ID lab introduction
The lab focuses on unauthorized access to another user's API key.

Lab objective/setup

Log in as wiener:peter, retrieve the synthetic API key belonging to carlos, and submit it through the lab interface.

What I observed

The authenticated account page displayed an API key and used /my-account?id=wiener. The visible identifier suggested that changing the parameter could select a different account. The explored email update path was not the relevant weakness; the read endpoint was.

Wiener account page displaying its own API key
The /my-account view displays the authorized wiener account before parameter mutation.
Email update request explored during the lab
The explored email-update request does not provide the useful object-selection weakness.
My account URL containing id equals wiener
The /my-account?id=carlos query directly selects the Carlos account object.

Why it is vulnerable

Authentication establishes who made the request, but the application never enforces that identity against the requested object. The user-controlled key is accepted as sufficient authority to read the record.

Walkthrough in the authorized PortSwigger lab

  1. Authenticate as wiener and open the account page.
  2. Replace id=wiener with id=carlos.
  3. Observe Carlos’s synthetic API key and submit it using the lab control.
Carlos account data exposed by changing the id parameter
The same session receives another user's account data.
Solved status after submitting the exposed API key
The solved banner confirms unauthorized access to Carlos's synthetic API key.
Authenticate as `wiener`, capture `/my-account?id=wiener`, replace only the `id` value with `carlos`, and read the returned synthetic API key. Submit that key through the lab answer form.

Verification

The response changes records solely because the query parameter changes. No session or privilege change occurs, confirming a missing object-level authorization check.

Impact and defensive lesson

IDOR can expose API keys, personal data, documents, or account actions at scale. Resolve identity from trusted session state and authorize access to every requested object.

References