php.ini Best Practices: How to Configure php.ini Like a Pro

What is the PHP.ini file?

The default PHP configuration file is called php.ini. By defining different settings and instructions for PHP’s functionality, it controls how PHP acts. A PHP interpreter reads the php.ini file to check its configuration when it first starts.

Key features

Global Settings:

It sets global configurations for all PHP scripts running on the server, unless overridden at runtime or by .htaccess files (in case of Apache).

Directive Configuration:

It includes a wide range of directives, like error reporting levels, memory limits, session behavior, and file upload configurations.

Customizability:

You can tweak this file to optimize performance, enforce security measures, or suit application-specific needs.

File Location:

The location of php.ini depends on the server setup. For example, in MAMP, it might be in a folder like /Applications/MAMP/bin/php/phpX.X.X/conf/.

Default vs. Customized:

PHP ships with a default php.ini file, but developers often customize it for their specific environment.

How to protect or how to configure it properly.

1. Disable Dangerous Functions

Reducing the attack surface of your server is mostly dependent on restricting possibly harmful PHP operations. If taken advantage of, these capabilities can let attackers run system-level commands.

disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

📍 Note

A) Customize Based on Your Application Needs

• Only disable functions that your application does not require. For instance, if your application uses curl_exec to make API requests, you should not disable it.
• Test your application after making changes to ensure functionality isn’t broken.

B) Why are these functions risky

• exec, passthru, shell_exec, system: Execute shell commands directly.
• proc_open, popen: Spawn processes and interact with the system shell.
• curl_exec, curl_multi_exec: Can be abused for SSRF (Server-Side Request Forgery) if improperly validated.
• parse_ini_file, show_source: Can expose sensitive configuration details.

C) Alternative Security Measures

• Use robust input validation and sanitization to reduce the risk of exploits.
• Consider using application-level APIs for specific tasks instead of relying on system commands.

2. Hide PHP Version

By default, PHP exposes its version number in HTTP headers, such as X-Powered-By. This information can help attackers tailor their exploits to known vulnerabilities in specific PHP versions. Hiding the PHP version adds a layer of obscurity, making it harder for attackers to gather information about your server.

expose_php = Off

• When expose_php is set to Off, PHP stops sending the X-Powered-By header in HTTP responses.
• This minimizes the information attackers can glean from server responses, reducing your application’s exposure to targeted attacks

If you want to check, open your terminal and execute the following command:

curl -I http://examplesite.com

The -I option fetches only the HTTP headers, not the full response body.

Run the curl command again to confirm that the X-Powered-By header is gone.

3. Disallow Remote File Inclusion

Remote file inclusion (RFI) vulnerabilities occur when an attacker exploits the ability to include files from external servers, potentially executing malicious code on your server. To mitigate this risk, disable the inclusion of files via URLs.

allow_url_include = Off

• When allow_url_include is enabled, PHP allows files to be included via URL (e.g., include(“http://example.com/file.php");).
• This can be exploited by attackers to include remote scripts, leading to unauthorized code execution or data breaches.

Why It’s Important:

• RFI is one of the most common vulnerabilities exploited in PHP applications.
• Disabling this feature ensures that only local files can be included, significantly reducing the attack surface.

Addtionally

allow_url_fopen = Off

This prevents PHP from opening remote files, further limiting potential vulnerabilities.

Run the command below, then you can find out if allow_url_include is disabled:

php -i | grep allow_url_include

4. Disable Error Display

Exposing error messages in a production environment can inadvertently provide attackers with valuable information about your application’s structure, configuration, or vulnerabilities. Instead, errors should be logged for debugging purposes without being displayed to users.

display_errors = Off

log_errors = On

error_log = /path/to/php_error.log

Explanation:

display_errors = Off:

• Prevents PHP from displaying error messages to the end user.
• Errors in production should be hidden to avoid exposing sensitive information like file paths, configuration details, or database queries.

log_errors = On:

• Ensures that errors are logged instead of displayed. These logs can then be reviewed by developers for debugging and monitoring.

error_log:

• Specifies the file where PHP should log errors. Make sure the log file is located in a directory not accessible to the public.

Why It’s Important:

1. Information Leakage: Exposed error messages might reveal:

• Absolute file paths.
• SQL queries and database details.
• Server or framework configurations.

5. Harden Session Cookies

PHP session cookies store sensitive data to maintain user state. Misconfigured session handling can expose your application to security risks such as XSS (Cross-Site Scripting), CSRF (Cross-Site Request Forgery), and session fixation attacks. Strengthening session cookie settings is essential for secure session management.

session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Strict
session.use_strict_mode = 1

Explanation of Each Setting

1. session.cookie_httponly = 1:

• Ensures that session cookies are inaccessible via JavaScript.
• Protects against XSS attacks where attackers might attempt to steal session cookies using malicious scripts.

2. session.cookie_secure = 1:

• Forces session cookies to be transmitted only over HTTPS.
• Prevents interception of cookies during transmission (e.g., via man-in-the-middle attacks).

3. session.cookie_samesite = Strict:

• Prevents the session cookie from being sent with cross-origin requests.
• Protects against CSRF attacks by ensuring cookies are only sent in same-site contexts.

4. session.use_strict_mode = 1:

• Enforces strict mode for session handling, preventing session fixation attacks.
• Ensures that only cookies with valid session IDs are accepted.

Why is it important ?

Prevention of Common Attacks:

• Reduces the risk of session hijacking, fixation, XSS, and CSRF.

6. Disable File Uploads (If Not Needed)

File uploads are a common attack vector, especially when file validation and sanitization are improperly implemented. If your application does not require file uploads, disabling this functionality altogether eliminates a significant attack surface.

file_uploads = Off

Why Disable File Uploads?

1. Reduce Attack Surface:

Prevent attackers from uploading malicious files (e.g., scripts, executables) that can be executed on your server.

2. Simplicity:

• If your application does not use file uploads, there’s no reason to leave the functionality enabled.

What If File Uploads Are Necessary?

If your application requires file uploads, consider these security best practices:

1. Restrict Upload Types:

Only allow specific file types (e.g., .jpg, .png, .pdf).

1. Set Upload Limits:

 upload_max_filesize = 2M
 post_max_size = 3M

3. Sanitize File Names:

• Remove special characters and validate file names to prevent path traversal attacks.

4. Store Files Outside the Web Root:

• Store uploaded files in a directory that is not directly accessible via the web.

Keep in mind, these php.ini settings aren’t one-size-fits-all—adjust them thoughtfully based on what your project truly needs to stay secure and functional.