Incorrect default permissions occur when software is installed or configured with overly permissive access controls on files, directories, databases, or…
Incorrect default permissions occur when software is installed or configured with overly permissive access controls on files, directories, databases, or services. An attacker or unauthorized user can then read, modify, or execute resources they should not have access to. This weakness is particularly dangerous because it often goes unnoticed — the system appears to work correctly, but the security boundary is already compromised from the moment of installation.
During setup, developers or installers must decide who can read, write, or execute each resource. When these decisions default to "allow everyone" or "allow the web server user" without restriction, the resource becomes accessible to unintended parties. This commonly happens when:
- Installation scripts create files or directories with world-readable or world-writable permissions (e.g., chmod 777).
- Database files, configuration files, or private keys are placed in web-accessible directories.
- Services bind to all network interfaces (0.0.0.0) instead of localhost, or listen on predictable ports without authentication.
- Backup or temporary files are created with the same permissions as the original, exposing sensitive data.
- Default user accounts or API keys are not changed or disabled after installation.
The root cause is usually a mismatch between the developer's assumption ("this will only be accessed by the admin") and the actual deployment environment.
Overly permissive defaults can lead to immediate data exposure. An attacker may read configuration files containing database credentials, private keys, or API tokens. They may modify application files to inject malicious code, alter database records, or escalate privileges. In shared hosting environments, one user's misconfigured permissions can expose another user's data. Even in single-tenant setups, a compromised low-privilege account (such as a web server process) can pivot to sensitive resources that should have been restricted to administrators only.
import os
import tempfile
# Create a temporary file for storing user session data
temp_file = tempfile.NamedTemporaryFile(mode='w', delete=False, dir='/tmp')
temp_file.write(f"user_id={user_id}\nsession_token={token}\n")
temp_file.close()
# File is created with default permissions (often 0o666 or 0o644)
# Any user on the system can read the session token
print(f"Session stored at {temp_file.name}")Why it's vulnerable:
The temporary file is created with default permissions that allow any user on the system to read it, exposing the session token and user ID.
import os
import tempfile
# Create a temporary file with restrictive permissions
fd, temp_file = tempfile.mkstemp(dir='/tmp')
os.chmod(fd, 0o600) # Owner read/write only
with os.fdopen(fd, 'w') as f:
f.write(f"user_id={user_id}\nsession_token={token}\n")
# File is now readable only by the owner
print(f"Session stored at {temp_file}")<?php
// Create a configuration file during installation
$config_content = "DB_USER=admin\nDB_PASS=secret123\nAPI_KEY=xyz789\n";
file_put_contents('/var/www/html/config.php', $config_content);
// File is created with default permissions (often 0644)
// Web server and other users can read the database credentials
?>Why it's vulnerable:
The configuration file containing database credentials and API keys is created with world-readable permissions, allowing any user or process to access sensitive data.
<?php
// Create a configuration file with restrictive permissions
$config_content = "DB_USER=admin\nDB_PASS=secret123\nAPI_KEY=xyz789\n";
$config_file = '/var/www/html/config.php';
file_put_contents($config_file, $config_content);
chmod($config_file, 0600); // Owner read/write only
// Verify permissions were set correctly
if ((fileperms($config_file) & 0777) !== 0600) {
die("Failed to set secure permissions on config file");
}
?>0600 for secrets, 0755 for directories).
chmod 777 or chmod 666 in any context; use role-based permissions instead.
127.0.0.1 or a Unix socket unless explicitly configured otherwise; avoid binding to 0.0.0.0.
Check your installation for world-readable or world-writable files using tools like find or ls -la. Look for configuration files, private keys, or database files in web-accessible directories or with overly permissive modes (e.g., 644, 666, 777). Review your service bindings to confirm they are not listening on all interfaces when they should be restricted. If you share a server with other users or applications, verify that your sensitive files are not readable by other accounts.
