Basic PHP Settings for Secure, High-Performance Applications

The most important PHP settings for a secure, fast production application are: display_errors off with logging on, expose_php off, OPcache enabled and tuned, secure session cookies (Secure, HttpOnly, SameSite and strict mode), realistic upload and runtime limits, a carefully tested list of disabled functions, and security headers set at the web server.

A secure PHP setup should reduce information leakage, protect session cookies, limit risky runtime behavior, and prevent avoidable exposure. A performance-focused setup should enable OPcache, reduce filesystem overhead, tune memory carefully, and avoid unnecessary runtime checks in production.

The settings below are practical production defaults for modern PHP applications. They should be adjusted based on your framework, hosting environment, workload, and deployment process.

Production PHP Configuration Checklist

PHP documents the available php.ini directives and their changeability levels in its official ini directive list, while OWASP provides specific hardening recommendations for PHP configuration and session cookies.

1. Disable Error Display in Production

In production, PHP errors should never be shown directly in the browser. Error messages can reveal file paths, database details, environment information, framework internals, and application logic.

Recommended configuration:

display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL

This keeps errors hidden from users while still sending them to logs for debugging and monitoring.

2. Hide PHP Version Information

By default, PHP can expose version information through HTTP headers. This is unnecessary in production and gives attackers extra fingerprinting information.

expose_php = Off

This does not secure the application by itself, but it reduces avoidable information disclosure. OWASP’s PHP configuration guidance also recommends hardening PHP settings to reduce unnecessary exposure.

3. Enable and Tune OPcache

OPcache is one of the most important PHP performance settings. It stores compiled PHP bytecode in memory so PHP does not need to parse and compile scripts on every request. PHP’s OPcache documentation states that opcache.enable enables opcode caching and optimization.

Recommended production baseline:

opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0
opcache.save_comments = 1

For deployment workflows where code changes are released through CI/CD, opcache.validate_timestamps = 0 can improve performance, but you must reset OPcache during deployment.

4. Secure PHP Session Cookies

Session cookies are a common attack target. A secure PHP application should make session cookies HTTPS-only, inaccessible to JavaScript, and protected with an appropriate SameSite policy.

Recommended session settings:

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

OWASP explains that the Secure cookie attribute ensures browsers only send cookies over encrypted HTTPS connections, helping protect session IDs from network interception.

5. Control File Upload Limits

Unrestricted uploads can create security and performance issues. Keep file limits realistic for the application.

Example:

file_uploads = On
upload_max_filesize = 10M
post_max_size = 12M
max_file_uploads = 10

For applications that do not support uploads, disable them:

file_uploads = Off

6. Set Safe Runtime Limits

Runtime limits protect the server from runaway scripts, heavy requests, and memory exhaustion.

Recommended baseline:

max_execution_time = 30
max_input_time = 60
memory_limit = 256M
max_input_vars = 3000

These values should be tuned for your application. For example, ecommerce platforms, import tools, and admin dashboards may need higher limits, but public-facing endpoints should stay conservative.

7. Restrict Dangerous Functions Carefully

Some teams disable risky PHP functions to reduce attack impact. This must be handled carefully because some frameworks, queues, deployment tools, and image libraries may rely on specific functions.

Example:

disable_functions = exec,passthru,shell_exec,system,proc_open,popen

Do not blindly copy a large disable_functions list. Test the application first.

8. Use Secure HTTP Headers

Some security protections are configured at the web server or application layer rather than only inside PHP.

Recommended headers:

OWASP’s HTTP Headers Cheat Sheet explains that proper security response headers can help reduce risks such as XSS, clickjacking, and information disclosure.

9. Production vs Development Settings

Use separate PHP configurations for development and production.

Development should prioritize visibility. Production should prioritize security, stability, and performance.

10. Recommended Production php.ini Baseline

; Error handling
display_errors = Off
display_startup_errors = Off
log_errors = On
error_reporting = E_ALL

; Information disclosure
expose_php = Off

; Resource limits
max_execution_time = 30
max_input_time = 60
memory_limit = 256M
max_input_vars = 3000

; Upload controls
file_uploads = On
upload_max_filesize = 10M
post_max_size = 12M
max_file_uploads = 10

; Session security
session.cookie_secure = 1
session.cookie_httponly = 1
session.cookie_samesite = Lax
session.use_strict_mode = 1

; OPcache performance
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.validate_timestamps = 0
opcache.save_comments = 1

Final Thoughts

A secure and high-performing PHP application is not created only by writing clean code. It also depends on a well-tuned runtime environment.

At a minimum, production PHP applications should disable public error display, enable error logging, hide PHP version exposure, secure session cookies, enable OPcache, control uploads, set resource limits, and apply security headers.

The best results come from treating PHP configuration as part of the deployment pipeline, not a one-time server setup.