Incorrect Privilege Assignment occurs when a system grants a user, role, or process more or sometimes fewer permissions than intended. This can allow…
Incorrect Privilege Assignment occurs when a system grants a user, role, or process more (or sometimes fewer) permissions than intended. This can allow unauthorized users to access sensitive functions, modify data they shouldn't touch, or perform administrative actions without proper authorization. It's a foundational access-control flaw that can undermine the entire security model of an application.
Privilege assignment flaws typically stem from logic errors in how permissions are checked or assigned during user creation, role updates, or permission inheritance. Common causes include hardcoded privilege levels that don't match actual role definitions, incorrect conditional logic in permission checks, role-based access control (RBAC) systems that fail to properly validate role membership before granting access, and permission inheritance chains that accidentally escalate privileges. The flaw often surfaces when a developer assumes a user has a certain role without verifying it, or when default permissions are set too broadly and never tightened.
An attacker or insider who exploits this weakness can perform actions reserved for administrators—such as creating accounts, modifying user data, accessing financial records, or changing system configuration. In some cases, a regular user might be granted administrative privileges by mistake, or an administrative account might retain privileges after being demoted to a standard user role. The impact ranges from data theft and unauthorized modification to complete system compromise, depending on which privileges are incorrectly assigned.
def get_user_permissions(user_id):
user = database.query("SELECT role FROM users WHERE id = ?", (user_id,))
if user['role'] == 'admin':
return ['read', 'write', 'delete', 'manage_users']
else:
return ['read']
def delete_record(user_id, record_id):
permissions = get_user_permissions(user_id)
# Bug: assumes 'delete' in permissions means user is authorized
# but doesn't verify the user actually has the 'admin' role
if 'delete' in permissions:
database.execute("DELETE FROM records WHERE id = ?", (record_id,))
return True
return FalseWhy it's vulnerable:
The function returns a permission list based on role, but if the role assignment logic is flawed elsewhere (e.g., a user is accidentally assigned the 'admin' role), or if permissions are cached and not refreshed after a role change, the user will retain unauthorized access.
def has_permission(user_id, required_permission):
# Always fetch fresh role from database, don't cache
user = database.query("SELECT role FROM users WHERE id = ?", (user_id,))
if user is None:
return False
# Define permissions per role explicitly
role_permissions = {
'admin': ['read', 'write', 'delete', 'manage_users'],
'editor': ['read', 'write'],
'viewer': ['read']
}
allowed = role_permissions.get(user['role'], [])
return required_permission in allowed
def delete_record(user_id, record_id):
if has_permission(user_id, 'delete'):
database.execute("DELETE FROM records WHERE id = ?", (record_id,))
return True
return False<?php
function grant_admin_access($user_id) {
// Bug: no verification that the caller has permission to grant admin access
$wpdb->update('users', ['role' => 'administrator'], ['ID' => $user_id]);
return true;
}
function handle_user_update() {
if (isset($_POST['user_id']) && isset($_POST['new_role'])) {
// Assumes current user is admin without checking
grant_admin_access($_POST['user_id']);
}
}
?>Why it's vulnerable:
The function grants administrative privileges without verifying that the caller has the authority to do so. An attacker who can reach this endpoint could promote any user to admin.
<?php
function current_user_can($capability) {
// Fetch current user's role from session/database
if (!isset($_SESSION['user_id'])) {
return false;
}
$user = $wpdb->get_row(
$wpdb->prepare("SELECT role FROM users WHERE ID = %d", $_SESSION['user_id'])
);
$role_capabilities = [
'administrator' => ['manage_users', 'edit_settings', 'delete_content'],
'editor' => ['edit_content', 'publish_content'],
'viewer' => ['read_content']
];
$allowed = $role_capabilities[$user->role] ?? [];
return in_array($capability, $allowed, true);
}
function grant_admin_access($user_id) {
// Verify caller has permission before granting
if (!current_user_can('manage_users')) {
return false;
}
$wpdb->update('users', ['role' => 'administrator'], ['ID' => $user_id]);
return true;
}
?>has_permission() or current_user_can()) and use it for every sensitive operation.
Check your user and role tables for unexpected privilege assignments—users with administrative roles who should not have them, or users whose roles don't match their job function. Review access logs for unusual activity from standard user accounts performing administrative actions (e.g., user creation, system configuration changes). Look for permission-related errors in application logs that suggest users are being denied access they should have, or granted access they shouldn't.
