This weakness occurs when a privilege, role, or permission is granted to perform a legitimate action, but the system also allows that same privilege to be…
This weakness occurs when a privilege, role, or permission is granted to perform a legitimate action, but the system also allows that same privilege to be misused for unintended and dangerous operations. Even when access controls correctly assign the privilege to the right user, the privilege itself is too broad or poorly scoped, enabling harm. The root cause is not broken access control, but rather a flaw in how the privilege is *defined*.
A privilege is typically designed to grant a user the ability to perform a specific task—for example, "edit user profiles" or "manage database backups." However, if the privilege is defined too broadly or without proper constraints, a user holding that privilege can leverage it to perform related but unintended actions. This often happens when:
- A privilege grants access to a powerful API or function without limiting *which* objects or operations it can affect. - A role bundles multiple capabilities together without considering the security implications of their combination. - The system fails to enforce secondary checks or constraints once a privilege is verified. - A privilege intended for one context (e.g., administrative tasks during business hours) is not restricted by time, location, or other conditions.
The access control mechanism itself may be working correctly—the user *does* have the privilege—but the privilege was never designed with safety boundaries in mind.
When a privilege is defined unsafely, legitimate users can inadvertently (or deliberately) cause serious harm. Examples include an administrator with "system configuration" rights using that privilege to disable security logging, a content moderator with "delete posts" rights deleting all posts from a competitor, or a backup operator with "restore database" rights restoring a backup to overwrite production data. The consequences range from data loss and service disruption to compliance violations and reputational damage.
# User has 'admin' role, which grants broad system access
def handle_user_request(user, action, target):
if user.has_role('admin'):
# No further checks; admin can do anything
if action == 'delete_user':
delete_user(target)
elif action == 'disable_logging':
disable_audit_logging()
elif action == 'export_all_data':
export_database_to_file(target)
return "Action completed"
else:
return "Access denied"Why it's vulnerable:
The admin role is defined so broadly that it permits any action without secondary validation. A legitimate admin can misuse the role to disable logging before performing unauthorized actions, or to export sensitive data, because the privilege itself has no built-in safety constraints.
# Privileges are narrowly scoped; each action requires explicit permission
def handle_user_request(user, action, target):
if action == 'delete_user' and user.has_permission('delete_users'):
validate_target_is_not_self(user, target)
delete_user(target)
elif action == 'disable_logging' and user.has_permission('manage_audit_logs'):
require_mfa_confirmation(user)
disable_audit_logging()
elif action == 'export_data' and user.has_permission('export_user_data'):
validate_export_scope(user, target)
export_data(target)
else:
return "Access denied"<?php
// User role 'editor' grants broad content and user management rights
function handle_request($user, $action, $target) {
if ( user_has_role($user, 'editor') ) {
// No further checks; editor can do anything
if ($action === 'publish_post') {
publish_post($target);
} elseif ($action === 'delete_user') {
delete_user($target);
} elseif ($action === 'modify_settings') {
update_site_settings($target);
}
return "Done";
}
return "Denied";
}
?>Why it's vulnerable:
The editor role is defined to permit multiple unrelated actions without secondary checks. An editor can delete users or modify site settings even though those actions should require separate, more restrictive permissions.
<?php
// Permissions are granular; each action requires explicit capability
function handle_request($user, $action, $target) {
if ($action === 'publish_post' && user_can($user, 'publish_posts')) {
publish_post($target);
} elseif ($action === 'delete_user' && user_can($user, 'delete_users')) {
require_admin_confirmation($user);
delete_user($target);
} elseif ($action === 'modify_settings' && user_can($user, 'manage_options')) {
log_sensitive_action($user, $action);
update_site_settings($target);
} else {
return "Access denied";
}
}
?>Review your access control system for overly broad roles or permissions that bundle unrelated actions together. Check audit logs for unusual patterns—for example, an administrator disabling logging immediately before performing sensitive operations, or a moderator account exporting large volumes of user data. Look for roles that have been granted permissions they should not logically need (e.g., a content editor with database backup rights).
