Incorrect Privilege Assignment

A user, role, or process is assigned a privilege level that doesn't match what it should have according to the application's intended access model - granted too much (or, less commonly, too little) at the point of assignment, as distinct from a privilege that starts correct but is enforced incorrectly later.

Confirming this requires knowing the application's intended privilege-assignment rules and comparing actual assignments against them - an authenticated, role-model-aware review rather than something visible from unauthenticated black-box traffic.

Authenticated review of the role/permission assignment system, comparing actual granted privileges for representative accounts against the documented or intended access model.

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 Incorrect Privilege Assignment 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.