Why is this an issue?

In Unix file system permissions, the "others" category refers to all users except the owner of the file system resource and the members of the group assigned to this resource.

Granting permissions to this category can lead to unintended access to files or directories that could allow attackers to obtain sensitive information, disrupt services or elevate privileges.

What is the potential impact?

Unauthorized access to sensitive information

When file or directory permissions grant access to all users on a system (often represented as "others" or "everyone" in permission models), attackers who gain access to any user account can read sensitive files containing credentials, configuration data, API keys, database passwords, personal information, or proprietary business data. This exposure can lead to data breaches, identity theft, compliance violations, and competitive disadvantage.

Service disruption and data corruption

Granting write permissions to broad user categories allows any user on the system to modify or delete critical files and directories. Attackers or compromised low-privileged accounts can corrupt application data, modify configuration files to alter system behavior or disrupt services, or delete important resources, leading to service outages, system instability, data loss, and denial of service.

Privilege escalation

When executable files or scripts have overly permissive permissions, especially when combined with special permission bits that allow programs to execute with the permissions of the file owner or group rather than the executing user, attackers can replace legitimate executables with malicious code. When these modified files are executed by privileged users or processes, the attacker’s code runs with elevated privileges, potentially enabling them to escalate from a low-privileged account to root or administrator access, install backdoors, or pivot to other systems in the network.

How to fix it in Core PHP

The most restrictive possible permissions should be assigned to files and directories. Use chmod() with appropriate permission values that restrict access to the "others" category. For example, use 0750 instead of 0777 to prevent any access from "others".

Code examples

Noncompliant code example

chmod("foo", 0777); // Noncompliant

Compliant solution

chmod("foo", 0750);

When using umask(), set it to a value that restricts permissions for the "others" category. The umask value 0027 ensures that newly created files and directories do not grant any permissions to "others".

Noncompliant code example

umask(0); // Noncompliant
umask(0750); // Noncompliant

Compliant solution

umask(0027);

How to fix it in Laravel

When using Laravel’s Filesystem component, ensure that chmod() is called with restrictive permission values. Use 0750 instead of 0777 to prevent access from the "others" category.

Code examples

Noncompliant code example

use Illuminate\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0777); // Noncompliant

Compliant solution

use Illuminate\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0750);

How to fix it in Symfony

When using Symfony’s Filesystem component, ensure that chmod() is called with restrictive permission values. Use 0750 instead of 0777 to prevent access from the "others" category.

Code examples

Noncompliant code example

use Symfony\Component\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0777); // Noncompliant

Compliant solution

use Symfony\Component\Filesystem\Filesystem;

$fs = new Filesystem();
$fs->chmod("foo", 0750);

Resources

Documentation

Standards