php.ini Security Settings
debt(d5/e3/b5/t5)
Closest to 'specialist tool catches' (d5). The term's detection_hints list phpinfo, semgrep, and lynis as tools — these are specialist security/configuration scanners rather than default IDE linters. Misconfigurations like expose_php=On or display_errors=On in production require intentional auditing with these tools or manual review; they won't be caught by standard PHP syntax checking.
Closest to 'simple parameterised fix' (e3). The quick_fix shows a checklist of ini directives that can be changed in one file, but fixing php.ini misconfigurations often requires understanding which pool/vhost/context is affected, potentially touching multiple configuration files (php-fpm pool configs, .htaccess, vhost configs). It's more than a one-line patch but typically contained within the server configuration layer rather than application code.
Closest to 'persistent productivity tax' (b5). php.ini settings apply across web and CLI contexts as noted in applies_to, affecting every PHP process on the server. The common_mistakes highlight that CLI and FPM often need different settings — this creates ongoing maintenance burden as the team must track which settings apply where. The choice shapes debugging workflows, deployment procedures, and security posture across all work streams without being completely architectural.
Closest to 'notable trap' (t5). The misconception explicitly states developers wrongly assume php.ini settings apply uniformly to all PHP processes, when in fact settings can be overridden at multiple levels (per-directory, per-virtualhost, per-pool, runtime). Understanding INI_ALL/INI_SYSTEM/INI_PERDIR permission levels is a documented gotcha that most PHP developers eventually learn, but causes confusion during debugging.
Also Known As
TL;DR
Explanation
Key security settings in php.ini include: display_errors=Off and log_errors=On (prevent information leakage), expose_php=Off (hides version), allow_url_include=Off (prevents RFI), disable_functions listing dangerous functions (exec, system, passthru, shell_exec), open_basedir restricting file access to the application directory, session.use_strict_mode=On and session.cookie_httponly=On (session security), post_max_size and upload_max_filesize (DoS prevention). Review settings regularly as PHP defaults favour development over security.
Common Misconception
Why It Matters
Common Mistakes
- Not having separate php.ini for CLI and FPM — they often need different memory_limit and timeout values.
- Leaving expose_php = On — the X-Powered-By header advertises your PHP version to attackers.
- Not setting session.cookie_secure, session.cookie_httponly, and session.cookie_samesite at the php.ini level as defaults.
- Using large upload_max_filesize without corresponding post_max_size — POST data is silently truncated.
Code Examples
; php.ini security issues:
expose_php = On ; Advertises PHP version
display_errors = On ; Stack traces to users in production
allow_url_include = On ; Enables remote file inclusion
register_globals = On ; Removed in PHP 5.4 but shows config hygiene issues
session.cookie_httponly = 0 ; Cookies readable by JS; Key php.ini settings
; Development:
error_reporting = E_ALL
display_errors = On
display_startup_errors = On
; Production:
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
display_errors = Off ; CRITICAL — never expose to users
log_errors = On
error_log = /var/log/php/error.log
expose_php = Off ; hides X-Powered-By header
max_execution_time = 30
memory_limit = 256M
upload_max_filesize = 10M
post_max_size = 12M
date.timezone = UTC
; Check active settings at runtime:
ini_get('memory_limit'); // specific value
phpinfo(); // full page — NEVER in production