Accessing another user’s API key by changing the username parameter

• Platform: PortSwigger Web Security Academy
• Category: Access Control
• Vulnerability: Insecure Direct Object Reference(IDOR)
• Difficulty: Apprentice
• Objective: Retrieve Carlos's API key.
• Tools: Web browser

Understanding Horizontal privilege escalation and IDOR

Horizontal privilege escalation occurs when a user can access resources belonging to another user of the same privilege level. This is commonly caused by an Insecure Direct Object Reference (IDOR), where the application uses user-supplied input (such as a username, numeric ID, or GUID) to access objects directly without verifying that the authenticated user is authorized to view them.

In other words, the server trusts the client to identify which resource should be accessed, and fails to check ownership.

Reconnaissance:

With Burp Suite running, I navigated to the /my-account page and logged in using the credentials provided by the lab (wiener:peter).

After logging in, my account page was displayed along with a unique API key:

Your API Key is: 4OWLcmsVrMv███████████

Your API Key is: 4OWLcmsVrMv███████████

I observed that the URL for the account page included a parameter containing my username:

https://███████████.web-security-academy.net/my-account?id=wiener

https://███████████.web-security-academy.net/my-account?id=wiener

This pattern — where the resource is identified directly by the user's own input — is a classic indicator of a potential IDOR.

Exploitation

Step 1: Change the username parameter

I changed the id parameter from wiener to carlos:

https://████████████████.web-security-academy.net/my-account?id=carlos

https://████████████████.web-security-academy.net/my-account?id=carlos

The server returned Carlos's account page, including his API key — without challenging the request or verifying that the logged-in user was authorized to view it.

Impact

An IDOR vulnerability allows attackers to access, modify, or sometimes delete other users' data by simply changing an identifier in the request.

In real-world applications, this can lead to:

• Unauthorized access to other users' private data, documents, financial records, or messages;
• Disclosure of sensitive tokens, API keys, or credentials;
• Full hijack of another user's account if the data includes enough information;
• If the affected resource belongs to an administrator, the horizontal escalation can become a vertical escalation.

Remediation

To prevent IDOR vulnerabilities, applications should:

• Never trust user-supplied identifiers to determine resource access. Validate on the server that the authenticated user owns or is authorized to access the requested object;
• Use indirect references (e.g., per-session mappings) instead of exposing direct identifiers like usernames or sequential IDs;
• Switch to non-predictable identifiers (e.g., GUIDs) rather than incrementing integers, but note that obscurity alone does not prevent IDOR if no ownership check is performed;
• Implement object-level authorization checks ("is this user allowed to access this object?") on every request that retrieves or modifies a resource;
• Log and monitor suspicious access patterns; alert on unusual cross-user access attempts.

Disclaimer

This write-up was created for educational purposes only. All testing was performed in an authorized PortSwigger Web Security Academy laboratory environment. Never test systems without explicit authorization.