Advanced16 min

Privilege Escalation

Turning limited access into more — vertically to admin, or horizontally to another user's data.

By the end of this lesson, recognize the common escalation paths and the checks that close them.

How deep?

How the pieces actually move.

Privilege escalation is turning the access you have into access you shouldn't. Vertical escalation gains higher privilege (user → admin). Horizontal escalation reaches peer resources you don't own (your data → another user's data, classically via IDOR/BOLA — changing an ID in a request).

First, the whole system

First, see the whole system. Then we’ll open it up.

Two directions

A low-privilege user escalates vertically to admin capabilities or horizontally to another user's data.

flowchart TB
  user[Low-privilege user]
  user -->|vertical| admin[Admin capabilities]
  user -->|horizontal / IDOR| peer[Another user's data]

Roots: missing object-level authorization (checking authN but not 'may THIS user touch THIS object'), the confused deputy (a privileged service acting on a caller's behalf with its own rights), over-broad roles, and trusting client-side checks. Fixes: default-deny, object-level checks on every access, least privilege, and propagating the caller's authority through delegation.

Now break it

GET /api/invoices/1042 returns your invoice. You try /1043. If it returns someone else's, that's IDOR — the server authenticated you but never checked you own object 1043.

Privilege escalation

Trigger: Missing object-/function-level authorization, confused deputy, or over-broad roles.
Symptom: A principal performs actions or reads data beyond its intended scope.
Blast radius: Up to full admin or cross-tenant data exposure.
Mitigation: Object-level authZ everywhere, least privilege, delegated authority, server-side enforcement.

How it connects

What single check prevents IDOR?

Object-level authorization: verify that the authenticated subject is allowed to access the specific object identified in the request.