Detector de logs expuestos

Cómo funciona esta comprobación

Scanaris pide siete rutas donde las aplicaciones más comunes escriben sus registros cuando nadie les dice otra cosa: /debug.log, /error.log, /error_log, /laravel.log, /storage/logs/laravel.log, /npm-debug.log y /wp-content/debug.log. Si alguna responde con un archivo de texto que parece un registro, y no con la página genérica de tu web, abre un hallazgo de severidad media con la ruta. Los registros no suelen contener la base de datos entera, por eso no es crítico; pero rara vez hay un archivo que cuente tanto sobre cómo funciona tu web por dentro.

Por qué importa

Un registro de errores es un diario de todo lo que ha fallado: rutas internas del servidor, nombres de archivos y de funciones, versiones exactas de librerías, consultas a la base de datos que fallaron con sus parámetros, direcciones IP de usuarios, a veces correos o tokens que aparecían en una petición. Con eso, alguien que busca una vulnerabilidad sabe exactamente dónde mirar y qué versión atacar. Y el registro crece: cada día que está expuesto cuenta más.

Por qué ocurre

WordPress con WP_DEBUG_LOG activado escribe en wp-content/debug.log, que es una carpeta pública; es el caso más común. Laravel guarda sus registros en storage/logs, que no debería ser accesible, pero lo es cuando el servidor apunta a la raíz del proyecto en lugar de a public/. Apache en hosting compartido deja error_log junto a los archivos de la web. Y npm-debug.log aparece cuando una instalación falló en el servidor y nadie limpió.

Cómo arreglarlo

• WordPress: en producción, define('WP_DEBUG', false); en wp-config.php. Si necesitas el registro temporalmente, muévelo fuera de la carpeta pública con define('WP_DEBUG_LOG', '/ruta/privada/debug.log'); y borra el archivo actual.
• Laravel: el servidor web debe apuntar a la carpeta public/ del proyecto, nunca a la raíz. Con eso storage/ deja de ser alcanzable. Y APP_DEBUG=false.
• Node y otros: escribe los registros fuera del directorio servido y envíalos a un servicio de registros si puedes. Borra los npm-debug.log y similares del servidor.
• Bloquea la extensión en el servidor como segunda barrera. En nginx: location ~* \.log$ { deny all; }. En Apache: <FilesMatch "\.log$"> Require all denied </FilesMatch>.
• Reduce lo que registras en producción: nivel de error en lugar de depuración, sin volcar cuerpos de petición completos ni tokens.

Comprueba que está arreglado

for p in debug.log error.log error_log laravel.log storage/logs/laravel.log npm-debug.log wp-content/debug.log; do
  printf "%-28s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tudominio.com/$p"
done

Lo esperado es 404 o 403 en todos. Si tu web es una aplicación de una sola página y responde 200 con su HTML, no es el registro; ábrelo para confirmarlo.

Preguntas frecuentes

Mi registro no tiene nada sensible, solo avisos de PHP.

Esos avisos incluyen rutas completas del servidor y versiones de plugins, que es justo lo que un atacante usa para elegir qué exploit probar. Y hoy no hay nada sensible; mañana, con un error nuevo, puede haberlo.

¿Necesito desactivar los registros del todo?

No. Necesitas que no sean públicos. Registra lo que quieras en una carpeta que el servidor web no sirva, o en un servicio externo.

¿Esto me aplica en Vercel o Netlify?

Casi nunca: allí los registros no se escriben en archivos públicos, se ven en el panel. El hallazgo aparece sobre todo en servidores propios, WordPress y hosting compartido.