Cómo reforzar php.ini en sitios web en producción: cada ajuste explicado

Endurecer (hardening) el php.ini de un sitio web en producción se reduce a unos pocos ajustes: ocultar los errores a los visitantes y registrarlos en un log (display_errors = Off, log_errors = On), dejar de anunciar su versión de PHP (expose_php = Off), proteger las cookies de sesión (session.cookie_secure, session.cookie_httponly, session.cookie_samesite, session.use_strict_mode) y fijar límites razonables para la subida de archivos. disable_functions y open_basedir pueden añadir una capa más, pero el propio manual de PHP aclara que no son barreras de seguridad completas. A continuación explicamos cada ajuste en lenguaje sencillo, con una configuración de ejemplo que puede entregar a su desarrollador o proveedor de hosting.

Antes de cambiar nada

• Encuentre el archivo correcto. Un servidor puede tener varios php.ini (línea de comandos, web, uno por versión de PHP). En el contexto web, la línea "Loaded Configuration File" de phpinfo() indica cuál está activo. Revíselo en una página temporal y bórrela enseguida.
• Sepa dónde están las excepciones. Paneles como cPanel (MultiPHP INI Editor) y Plesk (PHP Settings) escriben ajustes propios por sitio. Los archivos de pool de PHP-FPM también pueden fijar valores con php_admin_value, que los scripts no pueden cambiar después.
• Parta de php.ini-production. PHP incluye dos plantillas, php.ini-development y php.ini-production. La de producción ya trae valores más seguros, como display_errors = Off.
• Pruebe primero en staging y luego recargue PHP-FPM o el servidor web para aplicar los cambios.

Manejo de errores: registrar, no mostrar

display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/site-error.log

Qué hace: con display_errors activado, PHP imprime advertencias y errores directamente en la página. Esos mensajes pueden revelar rutas de archivos, nombres de bases de datos, fragmentos de consultas y versiones de plugins, lo que ayuda a un atacante a planificar. El manual de PHP lo dice claramente: mostrar errores "nunca debe usarse en sistemas de producción". El log conserva la misma información donde su equipo la ve y los visitantes no.

Consejo: asegúrese de que el archivo de log esté fuera de la raíz web y de que alguien lo revise o lo envíe a su sistema de monitoreo.

Deje de anunciar su versión de PHP

expose_php = Off

Qué hace: por defecto, PHP añade el encabezado X-Powered-By: PHP/8.x.y a cada respuesta. Desactivarlo no corrige ninguna vulnerabilidad, pero evita que los escáneres automáticos relacionen al instante su sitio con fallas conocidas de esa versión exacta. Solo puede configurarse en php.ini, no por directorio.

Atributos de la cookie de sesión

session.use_strict_mode = 1
session.use_only_cookies = 1
session.use_trans_sid = 0
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Lax

Si su sitio tiene inicio de sesión (un portal de clientes, WooCommerce, un área de miembros), estos ajustes protegen la cookie que mantiene a los usuarios conectados:

• use_strict_mode rechaza los identificadores de sesión que el servidor no creó. El manual de PHP lo considera "obligatorio para sesiones seguras", y aun así viene desactivado por defecto.
• use_only_cookies y use_trans_sid = 0 mantienen los identificadores de sesión fuera de las URL, donde se filtran a través de marcadores, enlaces compartidos y logs.
• cookie_httponly impide que JavaScript lea la cookie de sesión, lo que limita el daño de una falla de cross-site scripting.
• cookie_secure envía la cookie solo por HTTPS. Actívelo cuando todo el sitio funcione con HTTPS (como debe ser).
• cookie_samesite (Lax o Strict) indica a los navegadores que no envíen la cookie en la mayoría de las solicitudes entre sitios, lo que ayuda contra la falsificación de solicitudes (CSRF). Lax es la opción más práctica si los usuarios llegan desde enlaces de correo y esperan seguir conectados.

Muchos frameworks (WordPress, Laravel, Symfony) gestionan sus propias cookies, así que verifique que la configuración de la aplicación también coincida.

Límites para subir archivos

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

Qué hace: limita el tamaño de cada archivo subido y la cantidad de datos que puede enviar una solicitud. Los valores por defecto de PHP son 2 MB por archivo y 8 MB por solicitud; post_max_size debe ser mayor que upload_max_filesize. Ajústelos a lo que su sitio realmente necesita, no "lo más grande posible". Los límites muy altos facilitan agotar el espacio en disco o la memoria. Si el sitio nunca acepta archivos, file_uploads = Off es la protección más sencilla.

Los límites de tamaño son solo una parte de las subidas seguras. Validar los tipos de archivo y bloquear la ejecución de scripts en las carpetas de subida importa más.

Límites de recursos

max_execution_time = 30
max_input_time = 60
memory_limit = 256M

Evitan que una sola solicitud lenta o maliciosa acapare el servidor. Los valores dependen de la aplicación (algunas importaciones e informes necesitan más), así que tómelos como punto de partida.

disable_functions: un reductor de velocidad, no un muro

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

Qué hace: elimina funciones de PHP que ejecutan comandos del sistema operativo. Muchas web shells dependen de ellas, así que desactivarlas puede frenar un paso habitual después de una intrusión.

Lo que conviene saber:

• Solo puede configurarse en php.ini (no por directorio ni en tiempo de ejecución).
• El manual de PHP advierte que "puede eludirse y no debe considerarse una medida de seguridad suficiente para entornos de hosting compartido".
• Algunos programas legítimos necesitan estas funciones (procesamiento de imágenes, plugins de copias de seguridad, Composer, algunos paneles de control). Pruebe antes de aplicarlo y revise el log de errores después.

open_basedir: una red de seguridad adicional

open_basedir = /home/site/public_html:/home/site/tmp

Qué hace: limita los directorios desde los que los scripts PHP pueden abrir archivos, para que un script comprometido en un sitio no pueda leer sin más archivos de otras partes del servidor.

Lo que conviene saber: el manual de PHP lo describe como "solo una red de seguridad adicional, que de ninguna manera es completa". No restringe los sockets Unix, desactiva la caché realpath de PHP (lo que puede ralentizar sitios con mucho tráfico), y la separación real se logra ejecutando cada sitio con su propio usuario del sistema, su propio pool de PHP-FPM y permisos de archivo correctos.

Otros ajustes que vale la pena revisar

• allow_url_include = Off (valor por defecto): manténgalo desactivado para que el código no pueda incluir archivos desde URL remotas.
• session.save_path: guarde las sesiones en un directorio que solo pueda leer el usuario de ese sitio, no en un /tmp accesible para todos.
• session.cookie_lifetime = 0: la cookie de sesión termina al cerrar el navegador, salvo que la aplicación implemente "recordarme" de forma deliberada.

Lista de verificación para producción

• php.ini correcto (y ajustes por sitio) identificado
• display_errors = Off, log_errors = On, log guardado fuera de la raíz web
• expose_php = Off
• Atributos de la cookie de sesión configurados; HTTPS obligatorio en todo el sitio
• Límites de subida y de POST ajustados a las necesidades reales
• disable_functions y open_basedir probados en staging, si se usan
• Cambios documentados y PHP-FPM recargado

¿Quiere una segunda opinión?

Es común que la configuración se desordene con el tiempo: un ajuste corregido en un sitio rara vez llega al siguiente. Core Florida IT revisa y refuerza servidores PHP, cPanel/WHM y servidores Linux para empresas de Miami-Dade y el sur de Florida, y de forma remota en todo el país. Solicite una evaluación de TI gratuita y revisaremos su configuración actual con usted.

Fuentes

• Manual de PHP: Configuración de errores y registro
• Manual de PHP: Directivas del núcleo de php.ini
• Manual de PHP: Configuración INI segura de sesiones
• OWASP: PHP Configuration Cheat Sheet