Privilege Escalation in Web Apps

Privilege escalation is gaining rights you were not given. Sometimes it is as blunt as adding a role to a request, and sometimes it is a quiet abuse of a feature that runs with more privilege than you have. The goal is always the same: end the session with more power than you started with.

Role and group tampering

The first thing to test is anywhere your role or group travels in a request. If the app trusts a client-supplied role, you change it:

POST /api/profile    {"name":"me","role":"admin"}
PATCH /api/users/me  {"group":"administrators"}
Cookie: role=user    ->   role=admin

If the server reads that value and acts on it rather than deriving your role from the server-side session, you promote yourself. The root cause is covered in parameter-based access control.

Promoting yourself via a profile or settings update

The most common real escalation hides in an ordinary update. A settings form sends your name and email, but the endpoint binds the whole body to your user record. Add the field the form never exposed:

POST /account/settings
{"displayName":"me","email":"[email protected]","isAdmin":true}

Your legitimate update also sets isAdmin. This is mass assignment, and it turns a harmless-looking feature into a straight line to administrator.

Escalation through act-as and impersonation

Support and admin tooling often includes an "act as" or "impersonate" feature. Test whether the authorization to enter it is actually enforced:

• Can a normal user call the impersonation endpoint directly?
• Can you impersonate upward, into an admin, rather than only downward?
• Does the feature forget to re-check permissions once you are acting as someone else?

A weak impersonation gate hands you another account's privileges in one request.

Escalation via export and report endpoints

Export, report, and batch endpoints frequently run with elevated rights so they can read across records. If the authorization on the export is weaker than on the underlying data, you reach data (or actions) through the report that you could not reach directly:

GET /reports/all-users.csv         ->   returns every user, not just yours?
POST /admin/export                 ->   runs as a privileged job?

These endpoints are worth special attention because their whole job is to see more than a single user should.

Chaining a horizontal gap into a vertical one

The highest-value escalations start sideways. You use a horizontal gap to reach an administrator's object, then use that object to act with admin rights, or you find a reset or token mechanism through a peer's record that grants you privilege. Keep asking: does this sideways access expose anything that lets me move up? That question is the heart of account-takeover chains.

Privilege escalation is where access control testing turns into real impact. Try promoting yourself on a free live target, then read parameter-based access control for why so many of these gaps exist.