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 trusts a user-controlled id parameter and renders the selected user’s password into an HTML password field. Browser masking changes only presentation: the underlying value remains available to the client. Selecting the administrator record therefore discloses the lab credential and enables vertical privilege escalation.

The exercise states that an existing password is sent to the account page in a masked field and supplies `wiener:peter` as the initial login.
The exercise states that an existing password is sent to the account page in a masked field and supplies `wiener:peter` as the initial login.

Lab objective/setup

Log in as wiener:peter, recover the synthetic administrator password, sign in as administrator, and delete carlos.

What I observed

The profile displayed username and password fields, with the account selected through /my-account?id=wiener. Changing the parameter to administrator returned the administrator’s profile. Although the password appeared as dots, the page had already received its value.

The `wiener` profile includes a pre-populated password input whose bullets only hide the value visually.
The `wiener` profile includes a pre-populated password input whose bullets only hide the value visually.
Changing the account selector to `administrator` returns that profile and fills the Password field with the administrator's masked credential.
Changing the account selector to `administrator` returns that profile and fills the Password field with the administrator's masked credential.

Why it is vulnerable

The endpoint lacks object-level authorization, and the application sends a reusable password to the browser. An <input type="password"> merely obscures text on screen; it does not protect data in the DOM or response source. Passwords should not be retrievable in plaintext at all.

Walkthrough in the authorized PortSwigger lab

  1. Sign in as wiener and change the account id to administrator.
  2. Inspect the password input’s value in developer tools or the response source.
  3. Use the disclosed synthetic credential to sign in as administrator.
  4. Open the admin panel and delete carlos.
DevTools shows that the administrator credential is present in an ordinary input element whose `type=password` setting controls only display masking.
DevTools shows that the administrator credential is present in an ordinary input element whose `type=password` setting controls only display masking.
Changing the DOM attribute from `type=password` to `type=text` makes the full administrator password visible in the account form.
Changing the DOM attribute from `type=password` to `type=text` makes the full administrator password visible in the account form.
Authenticating with the disclosed administrator credential opens `/admin`, where the Users list provides a delete link for `carlos`.
Authenticating with the disclosed administrator credential opens `/admin`, where the Users list provides a delete link for `carlos`.
After the administrator deletes `carlos`, the page reports success and the Academy displays the solved status.
After the administrator deletes `carlos`, the page reports success and the Academy displays the solved status.

Verification

The normal account can load the administrator profile, and inspecting the returned field reveals the lab password. The Academy marks the exercise solved after that credential is used for the required admin action. The exact synthetic password is intentionally not reproduced here.

Impact and defensive lesson

The combination permits administrator account takeover and may amplify password reuse risk. Enforce ownership on every account lookup, never return existing passwords to a client, and store passwords with a modern one-way password-hashing function.

References