Registrar con seguridad: anotar errores sin fuga de datos

En resumen: el logging en PHP con la protección de datos en mente significa: registrar por completo los eventos relevantes para la seguridad, pero no escribir nunca en el log contraseñas, tokens, identificadores de sesión ni datos sensibles de clientes. Los errores van al registro, no a la pantalla; los logs están fuera del webroot y protegidos frente a modificaciones. Cuánto tiempo se conservan los logs lo decide usted de forma consciente, junto con el delegado de protección de datos.

Entre la conservación de pruebas y la fuga de datos

Tras PHP2Shell, los medios especializados aconsejaron conservar los logs del servidor web desde el 20 de octubre de 2026. Quien quiso aplicarlo constató a menudo dos cosas. O bien los logs llevaban tiempo rotados y borrados. O bien contenían cosas que nunca deberían haber estado allí: entradas completas de formularios, contraseñas de inicios de sesión fallidos, claves de API en URL.

Ambas cosas son un problema. Sin logs, un incidente apenas puede reconstruirse. Con demasiado contenido, el propio log se convierte en objetivo, porque quien obtiene acceso al servidor lo lee de paso con gusto. El buen logging está en el medio: suficiente para la búsqueda de rastros, con la menor cantidad posible de datos dignos de protección.

Qué debería registrar una aplicación PHP

La hoja de referencia de OWASP sobre logging cita los eventos que cuentan para la seguridad y la trazabilidad. Para las aplicaciones PHP típicas pueden resumirse así:

Cada entrada debería responder a las preguntas cuándo, dónde, quién y qué: marca de tiempo, aplicación y host, dirección de origen, identificador de usuario, tipo de evento y resultado. Los nombres o las direcciones de correo pueden a menudo enmascararse o sustituirse por un identificador interno sin perder utilidad.

Con frecuencia se pasan por alto dos fuentes de datos no deseados en el log. La primera son las URL: si un token, una clave de restablecimiento de contraseña o una dirección de correo está en la query string, acaba automáticamente en el log de acceso del servidor web, en los logs de proxy y en el historial del navegador. Esos valores pertenecen al cuerpo de la petición o a una cabecera, no a la dirección. La segunda fuente es el modo de depuración. Los frameworks y plugins suelen escribir en modo de depuración peticiones completas, consultas a la base de datos y variables de entorno. Si ese modo sigue activo tras una búsqueda de errores, crece sin que nadie lo note un archivo con justo la información que busca un atacante. Compruebe tras cada búsqueda de errores que las salidas de depuración se han vuelto a desactivar y borre los archivos generados.

Logging en PHP: los ajustes básicos

El primer nivel es el propio PHP. En producción, los errores deben registrarse pero no mostrarse. El log está fuera del webroot, para que no pueda descargarse mediante una URL.

; php.ini o pool de FPM para producción
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Por qué son peligrosos los errores visibles lo describe Desactivar la salida de errores en producción. Cómo se relacionan los errores y las excepciones en PHP lo explica Errores y excepciones en PHP.

El segundo nivel es la aplicación. Muchos frameworks usan para ello una biblioteca conforme al estándar PSR-3 de PHP-FIG, que define una interfaz de logger uniforme. Lo importante no es la biblioteca, sino la disciplina: elegir deliberadamente los datos de contexto, en lugar de escribir en el log peticiones u objetos enteros.

<?php
// Neutralizar y enmascarar las entradas antes de registrarlas
function logSicher(string $text): string {
    return mb_substr(str_replace(["\r", "\n"], ' ', $text), 0, 200);
}

function maskiereMail(string $mail): string {
    [$name, $domain] = array_pad(explode('@', $mail, 2), 2, '');
    return mb_substr($name, 0, 1) . '***@' . $domain;
}

$logger->warning('Anmeldung fehlgeschlagen', [
    'benutzer' => maskiereMail(logSicher($_POST['email'] ?? '')),
    'ip'       => $_SERVER['REMOTE_ADDR'] ?? '',
    // nunca: 'passwort' => $_POST['passwort']
]);

Inyección en logs y entradas manipuladas

Si una aplicación escribe en el log entradas sin filtrar, un atacante puede generar entradas falsas con saltos de línea. Eso confunde el análisis y puede ocultar rastros. La hoja de referencia de OWASP recomienda formatos estructurados como JSON, eliminar o codificar los saltos de línea y limitar la longitud de las entradas en el log.

Igual de importante es la protección de los propios logs:

1. Almacenamiento fuera del webroot y con permisos que el usuario del servidor web necesite para escribir, pero no para borrar archivos antiguos.
2. Copia en un segundo sistema, por ejemplo mediante syslog sobre una conexión cifrada. Quien se haga con el servidor no debe poder borrar simplemente los rastros.
3. Restringir el acceso de lectura y registrarlo también. Los logs contienen casi siempre datos personales.
4. Detectar el fallo: si el log queda de repente vacío, es una señal de alarma.
5. Sincronizar la hora: todos los servidores toman la hora de la misma fuente y escriben en el log una zona horaria inequívoca. De lo contrario, tras un incidente apenas pueden combinarse las entradas del servidor web, de PHP y de la base de datos en una cronología.

Decidir de forma consciente la conservación y la protección de datos

Cuánto tiempo pueden y deben conservarse los logs es una ponderación entre el interés de seguridad, la minimización de datos y los requisitos legales o contractuales. El art. 32 del RGPD exige medidas técnicas y organizativas adecuadas al riesgo, entre otras cosas para garantizar de forma permanente la confidencialidad, la integridad y la disponibilidad de los sistemas; el registro puede contribuir a ello. Al mismo tiempo, los datos personales no pueden conservarse más tiempo del necesario.

Fije por ello un plazo para cada tipo de log, deje por escrito la justificación y acuerde ambas cosas con su delegado de protección de datos. Para una investigación en curso puede ser necesario asegurar logs más allá del plazo normal. También eso debería documentarse. Esta página es información general y no asesoramiento jurídico; ante cuestiones concretas, ayudan el delegado de protección de datos y el abogado. Cómo analizar los logs tras un ataque lo muestra Analizar los logs del servidor web tras un ataque.

¿Cómo ayuda PHP SOS en concreto?

• Comprobamos en sus logs existentes la presencia de contraseñas, tokens y otros datos que no deben estar allí.
• Configuramos PHP y la aplicación de modo que los errores se registren pero no se muestren.
• Configuramos una copia protegida de los logs en un sistema separado.
• Mediante la monitorización de seguridad analizamos de forma continua las entradas relevantes para la seguridad y comunicamos lo llamativo de forma comprensible.

Conclusión: los buenos logs son parcos en el contenido y generosos en la protección. Quien define hoy qué se registra y qué nunca, tendrá en el peor caso rastros aprovechables y no una fuga de datos adicional.

Preguntas frecuentes

Fuentes

• OWASP: Logging Cheat Sheet
• PHP-FIG: estándares PSR
• Manual de PHP
• OWASP Top 10