Skip to content

CWE-732: Incorrect Permission Assignment for Critical Resource

Overview

This vulnerability occurs when critical resources (files, directories, services) are assigned overly broad or incorrect permissions, allowing unauthorized users to access or modify them.

OWASP Classification

A01:2025 - Broken Access Control

Risk

High: Attackers or unauthorized users can read, modify, or delete sensitive resources, leading to data breaches, privilege escalation, or system compromise.

Remediation Steps

Core principle: Apply least privilege to permissions/ACLs; default-deny and minimize who can read/write/execute.

Locate the incorrect permission assignment in your code

  • Review the flaw details to identify the specific file, directory, or resource with incorrect permissions
  • Understand the data flow: what resource is being created, who needs access, what operations are required
  • Identify current permissions: use ls -l (Unix), Get-Acl (Windows), or application-specific tools to view current permissions
  • Determine sensitivity: is this a config file, database file, log file, API key file, user data file?

Apply least privilege to all resources (Primary Defense)

  • Assign minimum necessary permissions: Grant only the permissions required for legitimate operations
  • Remove write/execute unless required: Most config files need read-only (400/600), not write (666/777)
  • Use numeric permissions explicitly:
    • 400: Owner read-only (sensitive config, private keys)
    • 600: Owner read/write (database files, user data)
    • 644: Owner read/write, group/world read (public config)
    • 755: Owner all, group/world read/execute (scripts, binaries)
  • Avoid dangerous permissions: Never use 777 (world-writable), 666 (all write), or 755 for sensitive files

Use secure defaults and explicit permissions

  • Set secure defaults for new resources: Use umask 027 or umask 077 to create files with restrictive permissions by default
  • Explicitly define permissions: Use chmod, os.chmod(), File.setReadable(), etc. to set permissions explicitly in code
  • Don't rely on system defaults: System defaults may be too permissive (often 644 or 755)
  • Apply permissions immediately: Set restrictive permissions before writing sensitive data to file

Apply additional permission controls

  • Use appropriate ownership: Set correct user/group ownership with chown or application-specific APIs
  • Implement file system ACLs: Use ACLs for fine-grained control when simple permissions aren't sufficient
  • Encrypt sensitive files: Combine proper permissions with encryption for sensitive data (keys, credentials, PII)
  • Use temporary file APIs: Use tempfile.NamedTemporaryFile(), Files.createTempFile() which create files with secure permissions

Regularly review and audit permissions

  • Periodically review resource permissions for unnecessary access (automated scans: find / -perm -002, security scanning tools)
  • Use automated tools to detect and remediate misconfigurations (Lynis, OpenSCAP, cloud security tools)
  • Log all access and modification events for sensitive resources (file access logs, audit logs)
  • Alert on unauthorized or suspicious activity (failed permission checks, privilege escalation attempts)

Test the permission changes thoroughly

  • Verify the specific overly permissive setting is corrected (check with ls -l, Get-Acl, stat())
  • Test with different user contexts to ensure permissions are restrictive (try accessing as different user/group)
  • Verify legitimate functionality still works (application can read config, write logs, etc.)
  • Test edge cases (file creation, rotation, backup/restore)
  • Re-scan with security scanner to confirm the issue is resolved

Common Vulnerable Patterns

  • Granting world-writable or world-readable permissions
  • Using default or inherited permissions without review

World-Writable Permissions on Critical File (Bash)

# Creates file with world-writable permissions
chmod 777 /etc/critical.conf

Secure Patterns

Owner-Only Read/Write Permissions (Bash)

# Creates file with restricted permissions (owner read/write only)
chmod 600 /etc/critical.conf
# or for read-only by owner:
chmod 400 /etc/critical.conf

Why this works:

  • Restricts file access to owner only (6=rw-, 4=r-- for owner, no access for group/others)
  • Prevents unauthorized users from reading sensitive data like passwords, keys, or configuration
  • Blocks attackers from modifying critical files to inject malicious code or alter application behavior
  • Follows principle of least privilege by granting minimal necessary permissions
  • Protects against privilege escalation through unauthorized file modification

Additional Resources