Cómo proteger el debug log de WordPress

Cuando el modo de depuración de WordPress está activado, los errores y advertencias se escriben en un archivo de registro en /wp-content/debug.log. Esto es increíblemente útil durante el desarrollo. Sin embargo, en un sitio en producción, un debug log accesible públicamente es un grave riesgo de seguridad. Cualquiera que conozca la URL puede leerlo, y a menudo contiene información mucho más sensible de lo que la mayoría de los propietarios de sitios cree.

Qué contiene el debug log

El archivo debug.log no es solo una lista de advertencias de PHP. Dependiendo de la configuración de tu sitio y los plugins que ejecutes, puede contener:

• Errores y advertencias de PHP: Incluyen rutas de archivos, números de línea y nombres de funciones. Un atacante puede usar esta información para mapear la estructura de directorios de tu servidor e identificar código vulnerable.
• Errores de consultas a la base de datos: Las consultas fallidas a veces incluyen nombres de tablas, nombres de columnas e incluso fragmentos de los datos consultados. Esto da a los atacantes una visión de tu esquema de base de datos.
• Errores de plugins y temas con stack traces: Los stack traces revelan qué plugins usas, sus versiones y cómo interactúan. Esto es valioso para planear ataques dirigidos contra vulnerabilidades conocidas de plugins.
• Claves de API y credenciales: Plugins mal escritos a veces registran respuestas de API o errores de conexión que incluyen tokens de autenticación, claves de API o incluso contraseñas en texto plano.
• Datos de usuarios y direcciones de correo: Los errores relacionados con el registro de usuarios, envíos de formularios o envío de correos pueden incluir datos personales como nombres, direcciones de correo y entradas de formulario.
• Rutas del sistema de archivos: Cada error PHP incluye la ruta completa del servidor al archivo donde ocurrió. Esto revela la estructura de directorios de tu hosting, tu nombre de usuario y a veces tu proveedor de hosting.

Por qué el debug log es accesible públicamente

Por defecto, WordPress almacena debug.log dentro del directorio wp-content. Este directorio es servido por tu servidor web igual que cualquier otra carpeta de tu instalación de WordPress. A menos que hayas bloqueado específicamente el acceso, cualquiera puede escribir https://tusitio.com/wp-content/debug.log en un navegador y leer el archivo.

Muchos proveedores de hosting no bloquean esta ruta por defecto. Y como el archivo crece con el tiempo sin rotación automática, puede acumular meses o incluso años de datos sensibles de errores.

Cómo encuentran los atacantes los debug logs

Los escáneres automatizados comprueban rutinariamente /wp-content/debug.log en cada sitio WordPress que encuentran. Es una de las primeras rutas que prueban las herramientas de escaneo de seguridad. Algunos atacantes también comprueban variaciones comunes:

• /wp-content/debug.log (ubicación por defecto)
• /debug.log (a veces mal configurado)
• /wp-content/uploads/debug.log (otra mala configuración común)
• /error_log o /error.log (nombres genéricos de logs de error)

Estos escaneos son baratos, rápidos y completamente automatizados. Si tu debug log es accesible, será encontrado.

Bloquear el acceso con .htaccess (Apache)

Si tu servidor utiliza Apache, añade esta regla al archivo .htaccess dentro de tu directorio wp-content:

    Order allow,deny
    Deny from all

Esto le dice a Apache que deniegue todas las peticiones HTTP al archivo debug.log. El archivo sigue existiendo en disco y PHP puede seguir escribiendo en él, pero nadie puede descargarlo a través de un navegador. Si quieres bloquear todos los archivos de log como precaución, puedes usar una regla más amplia:

    Order allow,deny
    Deny from all

Bloquear el acceso con Nginx

Para servidores Nginx, añade este bloque location a tu configuración de servidor:

location ~* /debug\.log$ {
    deny all;
    return 404;
}

Devolver un 404 en lugar de un 403 es una decisión deliberada. Una respuesta 403 (Prohibido) le dice al atacante que el archivo existe pero está protegido. Una respuesta 404 (No encontrado) no revela nada. Tras añadir esta regla, recarga la configuración de Nginx con sudo nginx -s reload.

Mover el archivo de log fuera del web root

El enfoque más seguro es almacenar el debug log en un directorio que tu servidor web no pueda servir en absoluto. En tu wp-config.php, establece la constante WP_DEBUG_LOG a una ruta absoluta fuera de tu web root:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', '/home/tuusuario/logs/wp-debug.log');
define('WP_DEBUG_DISPLAY', false);

El directorio /home/tuusuario/logs/ debe existir y ser escribible por el proceso del servidor web. Establecer WP_DEBUG_DISPLAY a false es igualmente importante: evita que los errores PHP se muestren directamente en tus páginas, donde los visitantes (y atacantes) podrían verlos.

Desactivar el modo de depuración en sitios de producción

En un sitio de producción en vivo, la depuración casi siempre debería estar desactivada. Rara vez hay una buena razón para dejarla activada permanentemente. Establece estos valores en wp-config.php:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Si necesitas depurar un problema en producción, activa el modo de depuración temporalmente, reproduce el problema, comprueba el log y desactívalo inmediatamente después. Nunca dejes la depuración activada "por si acaso". El riesgo no compensa la comodidad.

Monitorizar el tamaño del archivo de debug log

Si mantienes la depuración activada en un sitio de staging o desarrollo, monitoriza el tamaño del debug log. Sin rotación de logs, puede crecer hasta cientos de megabytes y eventualmente llenar tu disco. Considera configurar un cron job para rotarlo o truncarlo:

# Rotar debug.log semanalmente, mantener 4 copias de seguridad
# Añadir a /etc/logrotate.d/wp-debug
/home/tuusuario/logs/wp-debug.log {
    weekly
    rotate 4
    compress
    missingok
    notifempty
}

Qué hacer si ya se han expuesto datos sensibles

Si tu debug log fue accesible públicamente y contenía información sensible, sigue estos pasos inmediatamente:

• Elimina el archivo de debug log: Quítalo del servidor de inmediato.
• Rota todas las claves de API y credenciales: Cualquier clave de API, contraseña o token que apareciera en el log debe considerarse comprometido. Regenéralos.
• Cambia las contraseñas de la base de datos: Si se registraron errores de conexión a la base de datos, las credenciales podrían haberse expuesto.
• Comprueba si hay accesos no autorizados: Revisa los logs de acceso de tu servidor en busca de peticiones a debug.log. Si alguien lo descargó, evalúa qué información obtuvo.
• Notifica a los usuarios afectados: Si se registraron datos personales (correos, nombres, envíos de formulario), puedes tener una obligación de RGPD o privacidad de notificar a las personas afectadas.

Verificar con InspectWP

InspectWP comprueba si /wp-content/debug.log es accesible públicamente en tu sitio. Tras proteger el archivo (bloqueando el acceso, moviéndolo o desactivando el modo de depuración), ejecuta un nuevo análisis de InspectWP. La sección de seguridad del informe confirmará si el archivo sigue siendo alcanzable. Si la advertencia persiste, vacía cualquier caché del lado del servidor y verifica que tus reglas de .htaccess o Nginx se aplican al directorio correcto.