This weakness occurs when software fails to properly check or respond to permission errors before attempting a sensitive operation. Instead of gracefully…
This weakness occurs when software fails to properly check or respond to permission errors before attempting a sensitive operation. Instead of gracefully denying access or alerting the user, the application may proceed with partial execution, expose sensitive information, or leave itself in an inconsistent state. The result is that unprivileged users can sometimes perform actions they shouldn't, or the system behaves unpredictably when permissions are missing.
Most applications need to verify that a user or process has the right to perform an action before executing it. This check typically happens in two places: at the application level (does this user role have access?) and at the system level (does the process have the OS-level capability?). When developers skip these checks, assume permissions will always be present, or fail to handle permission-denial errors, the door opens to unauthorized access. The weakness is especially common in code that transitions between privilege levels, accesses shared resources, or delegates operations to background processes without re-validating permissions.
An attacker with a low-privilege account can escalate to perform administrative actions, read confidential files, or modify system settings. In multi-tenant systems, one tenant may access another's data. Background jobs or scheduled tasks may fail silently or execute with stale privilege assumptions, leaving data in an unsafe state. The impact ranges from information disclosure to complete system compromise, depending on what operation the unprivileged user can now perform.
import os
def read_sensitive_file(filename):
# No permission check before opening
with open(filename, 'r') as f:
return f.read()
# Called from a web request handler
user_input = request.args.get('file')
content = read_sensitive_file(user_input)
return contentWhy it's vulnerable:
The function assumes the caller has permission to read any file and does not verify the current user's role or the file's access control list before opening it. An unprivileged user can request any filename and receive its contents.
import os
def read_sensitive_file(filename, user_role):
# Check user permission before proceeding
if user_role not in ['admin', 'editor']:
raise PermissionError(f"User role '{user_role}' cannot read files")
# Validate filename is within allowed directory
allowed_dir = '/var/app/data'
full_path = os.path.abspath(filename)
if not full_path.startswith(allowed_dir):
raise PermissionError("Access denied: file outside allowed directory")
with open(full_path, 'r') as f:
return f.read()
# Called from a web request handler
user_role = session.get('role')
user_input = request.args.get('file')
try:
content = read_sensitive_file(user_input, user_role)
except PermissionError as e:
return error_response(str(e), 403)<?php
function delete_user_account($user_id) {
// No permission check
$wpdb->delete('wp_users', array('ID' => $user_id));
return true;
}
// Called from a form submission
if ($_POST['action'] === 'delete_user') {
$target_id = intval($_POST['user_id']);
delete_user_account($target_id);
wp_redirect(admin_url());
}
?>Why it's vulnerable:
The function deletes any user without verifying that the current user is an administrator or has the capability to delete accounts. A subscriber could craft a POST request to delete any user.
<?php
function delete_user_account($user_id, $current_user_id) {
// Check current user capability
if (!current_user_can('delete_users')) {
throw new Exception('Insufficient permissions to delete users');
}
// Prevent self-deletion
if ($user_id === $current_user_id) {
throw new Exception('Cannot delete your own account');
}
// Proceed with deletion
$wpdb->delete('wp_users', array('ID' => $user_id));
return true;
}
// Called from a form submission
if ($_POST['action'] === 'delete_user') {
try {
$target_id = intval($_POST['user_id']);
delete_user_account($target_id, get_current_user_id());
wp_redirect(admin_url());
} catch (Exception $e) {
wp_die(esc_html($e->getMessage()), 'Forbidden', array('response' => 403));
}
}
?>Check your application logs for repeated HTTP 403 errors or permission exceptions from the same user or IP, which may indicate an attacker probing for unprotected endpoints. Review your admin or sensitive-data access logs for activity from accounts that should not have those permissions. If you find unexpected admin users, recently modified files in system directories, or data deletions by low-privilege accounts, investigate whether permission checks were bypassed.
