This weakness occurs when a resource—such as a file, database, API endpoint, or configuration—is made accessible to users or systems that should not have…
This weakness occurs when a resource—such as a file, database, API endpoint, or configuration—is made accessible to users or systems that should not have permission to access it. The exposure is unintentional, typically the result of misconfigured access controls, overly permissive default settings, or a failure to restrict visibility based on user roles. The consequence is that unauthorized parties gain access to sensitive information or functionality they were never meant to reach.
Access control decisions are made at multiple layers: file system permissions, web server configuration, application logic, and database schemas. When these layers are not aligned or when defaults are not explicitly tightened, resources can leak into the wrong "sphere"—the set of actors who should legitimately access them. Common causes include:
- Leaving default credentials or public read permissions on files, directories, or cloud storage buckets. - Failing to check user roles or ownership before serving a resource in application code. - Exposing internal APIs or admin endpoints without authentication or rate limiting. - Storing sensitive data (backups, logs, configuration files) in web-accessible directories. - Misconfiguring web server directives so that files meant to be private are served publicly.
The flaw is often not a single line of code but rather a gap between intent and implementation—the developer intended the resource to be private, but did not enforce that intent consistently.
Exposure of resources to the wrong sphere can lead to disclosure of passwords, API keys, personal data, or proprietary information. An attacker may discover a backup file, a misconfigured S3 bucket, or an unauthenticated admin panel and gain unauthorized access to accounts, systems, or sensitive business logic. In regulated industries, such exposure can trigger compliance violations and legal liability. Even if the exposed resource itself is not immediately exploitable, it may provide reconnaissance information that enables further attacks.
from flask import Flask, send_file, request
app = Flask(__name__)
@app.route('/download/<filename>')
def download_file(filename):
# No check: does the current user own this file?
# No check: is filename safe from path traversal?
return send_file(f'/uploads/{filename}')
@app.route('/api/user/<user_id>')
def get_user(user_id):
# No authentication or role check
user_data = db.query(f"SELECT * FROM users WHERE id = {user_id}")
return user_dataWhy it's vulnerable:
The first endpoint serves any file from the uploads directory without verifying the requester owns it. The second endpoint exposes user data to any caller without authentication. Both grant access across sphere boundaries.
from flask import Flask, send_file, request, abort
from functools import wraps
app = Flask(__name__)
def require_auth(f):
@wraps(f)
def decorated(*args, **kwargs):
if not request.headers.get('Authorization'):
abort(401)
return f(*args, **kwargs)
return decorated
@app.route('/download/<filename>')
@require_auth
def download_file(filename):
current_user = get_current_user(request)
file_owner = db.query("SELECT owner FROM files WHERE name = ?", (filename,))
if file_owner != current_user.id:
abort(403)
return send_file(f'/uploads/{filename}')
@app.route('/api/user/<user_id>')
@require_auth
def get_user(user_id):
current_user = get_current_user(request)
if int(user_id) != current_user.id:
abort(403)
user_data = db.query("SELECT * FROM users WHERE id = ?", (user_id,))
return user_data<?php
// Assume user is logged in; no further checks
if (isset($_GET['file'])) {
$filename = $_GET['file'];
readfile('/var/www/uploads/' . $filename);
}
// Admin endpoint with no authentication
if ($_GET['action'] === 'delete_user') {
$user_id = $_GET['user_id'];
$wpdb->query("DELETE FROM wp_users WHERE ID = $user_id");
echo "User deleted";
}
?>Why it's vulnerable:
The first block serves any file without checking ownership. The second block allows any visitor to delete users if they know the parameter name. Neither enforces role-based access control.
<?php
// Check authentication and ownership
if (!is_user_logged_in()) {
wp_die('Unauthorized', 401);
}
if (isset($_GET['file'])) {
$filename = sanitize_file_name($_GET['file']);
$file_owner = $wpdb->get_var(
$wpdb->prepare("SELECT post_author FROM wp_posts WHERE post_name = %s", $filename)
);
if ($file_owner != get_current_user_id()) {
wp_die('Forbidden', 403);
}
readfile('/var/www/uploads/' . $filename);
}
// Admin endpoint: check capability
if ($_GET['action'] === 'delete_user') {
if (!current_user_can('delete_users')) {
wp_die('Forbidden', 403);
}
$user_id = intval($_GET['user_id']);
wp_delete_user($user_id);
echo "User deleted";
}
?>OPTIONS and GET requests on directories; serve only named files.
.git directories, backup files, cloud storage buckets, and admin panels accessible without authentication.
Check your web server logs and file system for unexpected access patterns: requests for files outside the intended directory structure (e.g., ../../../etc/passwd), access to admin endpoints from non-admin IP ranges, or downloads of backup or configuration files. Review cloud storage bucket policies and file permissions for overly permissive settings (e.g., public-read on sensitive buckets, world-readable files in upload directories). If you find such patterns, investigate whether unauthorized parties accessed the exposed resources.
