Privilege Escalation

An attacker gains access to functionality or data reserved for a higher privilege tier than their own account holds - a regular user reaching an admin-only action, or a support-role account reaching a super-admin capability. Confirming this class requires two things a fully unauthenticated black-box scan doesn't have by default: a known role hierarchy for the target application, and a live session token for a genuinely lower-privileged account to test from. Without both, there's no baseline to compare "what this role can do" against "what this role just did."

This needs a real, working session at a specific known-lower privilege tier, plus knowledge of what that tier is supposed to be forbidden from doing - neither of which an unauthenticated black-box crawl has access to. It's a harder precondition than horizontal-access testing (IDOR, mass assignment), which only needs two same-tier accounts and can flag "account A reached account B's data" without knowing the app's specific role model.

Authenticated multi-role testing, logging in as each defined role and systematically attempting every higher-tier action, is how this is normally confirmed. Automated IDOR and mass-assignment testing covers the adjacent, more tractable case of same-tier horizontal access, which is a real but distinct problem from cross-tier privilege escalation.

Tip: Reviewing the actual permission model, what each role, process, or service account is granted, against what it's ever really used, surfaces most of these findings faster than trying to trigger the escalation through the application's normal interface.

Real-World Impact

Privilege-escalation and privilege-management flaws let a user, process, or component end up with more access than it should have — either horizontally (reaching another user's context) or vertically (reaching an admin or system-level context) — through a gap in how permissions are assigned, checked, or dropped rather than a missing authentication check outright.

A process that retains elevated privileges longer than it needs them, a permission assignment that's broader than the resource actually requires, or a role hierarchy with a gap between what's checked and what's granted are all common shapes this takes. The impact scales directly with what the escalated privilege actually unlocks — anywhere from an unintended UI feature to full administrative or system-level control.

This class is a common second stage in a larger attack chain: an initial low-privilege foothold (from an unrelated bug) combined with a privilege-escalation flaw is how a minor finding on its own becomes a critical one in combination, which is part of why privilege boundaries are worth reviewing even when the direct entry point looks contained.

Prevention and Secure Design

Preventing Privilege Escalation takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Apply least privilege by default, everywhere. Grant a user, process, or service account only the specific permissions it needs for its current task, not a broad role that happens to include them.

Drop elevated privileges as soon as they're no longer needed. A process that briefly needs elevated rights should relinquish them immediately after, rather than holding them for the rest of its lifetime.

Centralize and audit the permission model. A single, reviewable source of truth for what each role or account can do is far easier to reason about — and to catch drift in — than permissions scattered across many individual checks.

Re-verify privilege at the point of use, not just at login. A privilege check performed once at authentication time can go stale if roles change mid-session; sensitive actions should re-check current privilege at the moment they're performed.

Test role boundaries explicitly. Authenticate as each defined role and attempt actions reserved for every other role — the gap between what's technically reachable and what's intended is exactly where this class lives.