Privilege Escalation

Also Known As

TL;DR

Explanation

Privilege escalation occurs when authorisation decisions are based on attacker-controllable data — a URL parameter, POST field, or cookie value — rather than server-side session state. Example: checking $_GET['admin'] === 'true' instead of $_SESSION['role'] === 'admin'. The fix is always to derive permissions exclusively from server-side state that the user cannot tamper with.

How It's Exploited

Common Misconception

Why It Matters

Common Mistakes

• Storing the user role or is_admin flag in the session without re-verifying against the database on sensitive actions.
• Not checking ownership when performing actions on resources — user A can modify user B's data by changing the resource ID.
• Mass assignment vulnerabilities that allow setting role or is_admin through form fields.
• Admin functionality that validates the role only in the UI, not in the server-side handler.

Code Examples

// Role stored in JWT payload — user can edit it client-side
\$role = \$jwtPayload['role']; // never trust client-supplied roles
if (\$role === 'admin') { grantAdminAccess(); }

// Always fetch authoritative role from the database
\$user = User::findOrFail(\$jwtPayload['sub']); // look up by ID only
if (\$user->role === 'admin') { grantAdminAccess(); }

// Or use signed, server-verified JWT with short expiry
// Never embed mutable authorisation claims in long-lived tokens

References

• ↗ https://owasp.org/www-project-top-ten/2021/A01_2021-Broken_Access_Control
• ↗ https://cwe.mitre.org/data/definitions/269.html

Tags

Related Terms