What is Privilege escalation?
An attacker who already has SOME access elevates to MORE access. Vertical: low-privilege user → admin. Horizontal: user A → user B's data (BOLA / IDOR). The most common bug class in AI-generated apps.
Full explanation
Privilege escalation is the bridge between an initial foothold (any authenticated access, often a normal user account) and a damaging outcome (admin access, cross-user data, system control). Two flavors: vertical privilege escalation (gain a higher role than your own — user → admin) and horizontal privilege escalation (gain access to a peer's data — BOLA / IDOR). Most AI-generated authorization bugs are horizontal escalation: missing ownership checks let any authenticated user request any other user's data.
Example
An /api/users/[id] handler that returns the user record without comparing the requested ID against the authenticated session's ID. User A authenticates, requests /api/users/<userB-id>, gets user B's email + profile. Horizontal escalation. Fix: every handler that takes an ID compares ownership against the session.
Related
FAQ
How does this differ from privilege escalation in OS contexts (sudo / setuid)?
Same pattern, different surface. OS privilege escalation is a process gaining root from a non-root context. Web-app privilege escalation is a request gaining higher permissions than the requester's session. The defense is the same: explicit role/ownership checks at every privileged operation.
Does RLS prevent privilege escalation?
RLS prevents one specific escalation surface (database row access). It does not prevent: API endpoints that read from a service-role context and skip RLS, business-logic operations that bypass the database (sending an email, charging a card, calling a third-party API), or vertical escalation via missing role checks. Defense in depth: RLS + app-layer authorization checks at every privileged operation.