Privilege Escalation Prevention
Security measures that prevent users from gaining unauthorized access to resources or functions beyond their assigned permissions, whether by elevating their own role or accessing other users' data.
Description
Privilege escalation prevention addresses two types of unauthorized access elevation: vertical escalation (a lower-privileged user gains higher-privileged access, e.g., a regular user performing admin actions) and horizontal escalation (a user accesses resources belonging to another user at the same privilege level, e.g., viewing another user's private data by manipulating IDs). Both are among the most critical and common web application vulnerabilities, consistently appearing in the OWASP Top 10 as 'Broken Access Control'.
Vertical escalation prevention requires enforcing authorization checks on every request, not just on the UI layer. Common mistakes include hiding admin buttons in the UI but not enforcing permissions on the API, trusting client-side role claims without server-side validation, and allowing users to modify their own role or permission assignments through API manipulation. Every API endpoint must independently verify that the authenticated user has the required privileges, regardless of how the request was initiated.
Horizontal escalation prevention requires verifying resource ownership or access rights in every data-access query. Instead of fetching a resource by ID alone (SELECT * FROM orders WHERE id = ?), always include the user context (SELECT * FROM orders WHERE id = ? AND user_id = ?). Use parameterized queries with the authenticated user's ID, implement data-access layers that automatically scope queries to the current user's accessible data, and avoid exposing sequential or guessable identifiers (use UUIDs instead). Comprehensive server-side authorization testing, including negative test cases (attempting actions as the wrong user or role), is essential to catch these vulnerabilities during development.
Prompt Snippet
Prevent privilege escalation by implementing server-side authorization at three layers: (1) Route-level: apply @RequiresRole or @RequiresPermission guards on every endpoint, never rely on UI-only hiding. (2) Resource-level: in data access layers, always scope queries with the authenticated user's ID or tenant_id -- use a repository pattern that automatically injects WHERE user_id = $currentUser or WHERE tenant_id = $currentTenant. (3) Field-level: strip or reject role/permission fields from user-submitted update payloads. Use UUIDs for resource identifiers instead of sequential integers. Write integration tests that explicitly attempt cross-user data access and role escalation via direct API calls. Implement IDOR detection by logging access patterns where requested resource owner differs from the authenticated user.
Tags
Related Terms
RBAC (Role-Based Access Control)
An access control model where permissions are assigned to roles, and users are granted roles, simplifying permission management at scale.
ABAC (Attribute-Based Access Control)
An access control model that evaluates policies against attributes of the user, resource, action, and environment to make authorization decisions.
Auth Middleware / Guards
Reusable middleware or guard components that intercept requests to enforce authentication and authorization policies before they reach route handlers.
Audit Logging for Auth Events
Comprehensive, tamper-evident logging of all authentication and authorization events to support security monitoring, incident investigation, and compliance requirements.
Scope-Based Permissions
A permission model where access tokens carry scope strings that define the specific actions and resources the token is authorized to access.