Skip to main content

🗂️PortSwigger Lab Writeup: User ID Controlled by Request Parameter with Data Leakage in Redirect

PortSwigger lab banner: User ID controlled by request parameter with data leakage in redirect

🎯 Objective​

The objective of this lab is to exploit a broken access control where the app has a horizontal privilege escalation vulnerability on the user account page which leaks sensitive information in the body of redirect response. The goal is to obtain the API key for the user carlos.

  • Lab URL: https://portswigger.net/web-security/access-control/lab-user-id-controlled-by-request-parameter-with-data-leakage-in-redirect
  • Category: Access Control
  • Difficulty: Apprentice

🧪 Exploitation Steps​

🕵️Step 1: Observe the Website​

  • Firstly open the lab URL in your browser, and observe what it is about and how it works. Shopping website homepage displaying product listings and navigation menu
    Login page interface with username and password fields
  • At first glance, the website seems to be a shopping website with a login page. In the lab description, it is mentioned that we need to obtain the API key for the user carlos.

📝Step 2: Login as wiener​

  • Login with the credentials of user wiener to access the account page first. Login page with wiener credentials
  • Now, On user account page /my-account?id=wiener we can see the API key of wiener. User account page showing wiener's profile with API key displayed
  • Now, Change the /my-account?id=wiener to /my-account?id=carlos to access the account page of carlos
  • But we are redirected to the login page.
  • Open the HTTP History in Burpsuite and see the GET /my-account?id=carlos request. Burp Suite HTTP history showing redirect response with carlos API key leaked in response body
  • Hence, In the actual response intercepted in Burpsuite we can see the API key of user carlos.

🧑‍💼Step 3: Submit API of carlos​

  • Copy the API key of carlos and submit it in Submit Solution. Lab solved confirmation message after submitting carlos API key
  • And Finally, the Lab is solved.

🧠 Conclusion​

  • This lab demonstrated how data leakage in HTTP responses enables privilege escalation even when access control redirects users. The application exposed sensitive API keys in the response body before performing the redirect, allowing attackers to intercept this data via proxy tools.
  • The impact is high — sensitive data should never be included in responses that will be redirected, as attackers can intercept the raw response before following redirects using proxies or direct HTTP clients.
  • Fix: never include sensitive data in response bodies before redirects, validate authorization checks before processing requests (not after), ensure HTTP response bodies are cleared when issuing redirects, and implement proper server-side authorization that prevents data exposure regardless of whether a redirect occurs.