Detector de paneles expuestos

Cómo funciona esta comprobación

Scanaris pide una lista de rutas que corresponden a paneles y herramientas de depuración que nunca deberían responder en producción, y comprueba que la respuesta es la real de esa herramienta y no la página genérica de tu web. Las rutas y su severidad: /actuator/health de Spring Boot (alta), /actuator/env y /actuator/heapdump (críticas: variables de entorno y un volcado de memoria), /telescope/requests de Laravel Telescope (alta), /_ignition/health-check de Laravel Ignition en modo debug (crítica, porque versiones vulnerables permitían ejecutar código), /_profiler de Symfony (alta), /.vscode/sftp.json con credenciales de despliegue (crítica), /server-status de Apache (media) y /phpmyadmin/ (alta).

Por qué importa

Estas herramientas existen para enseñar las tripas de la aplicación a quien la desarrolla: configuración, variables de entorno con contraseñas, consultas recientes con sus parámetros, trazas de error completas, el contenido de la memoria del proceso. En desarrollo son valiosísimas; en producción, abiertas a internet, son una puerta con la llave puesta. Un /actuator/env accesible suele incluir la cadena de conexión a la base de datos. Un phpMyAdmin público es un punto de entrada para probar contraseñas contra tu base de datos las 24 horas del día.

Por qué ocurre

Porque la misma configuración sirve para desarrollar y para producción. El modo debug de Laravel (APP_DEBUG=true), los endpoints de Actuator expuestos por defecto en versiones antiguas de Spring, el profiler de Symfony con APP_ENV=dev, un phpMyAdmin instalado "para mirar la base de datos un momento" y nunca retirado. Las herramientas de IA que generan el proyecto rara vez distinguen entornos, y el despliegue hereda la configuración de desarrollo.

Cómo arreglarlo

• Laravel: APP_DEBUG=false y APP_ENV=production en el .env de producción. Telescope solo en entornos locales (TELESCOPE_ENABLED=false o el gate de autorización). Actualiza Ignition a una versión sin la vulnerabilidad.
• Spring Boot: management.endpoints.web.exposure.include=health como máximo, sin env ni heapdump, y con seguridad por delante de /actuator. Mejor aún, exponer el actuator en un puerto de gestión distinto que no salga a internet.
• Symfony: APP_ENV=prod y APP_DEBUG=0; el profiler solo se registra en dev.
• phpMyAdmin: desinstálalo del servidor público. Si lo necesitas, accede por túnel SSH o restríngelo por IP y con autenticación adicional.
• Apache server-status: Require ip 127.0.0.1 en la directiva Location /server-status, o desactiva el módulo.
• Archivos de editor como .vscode/sftp.json: nunca deben desplegarse. Añade .vscode/ al .gitignore y, si estuvo publicado, cambia la contraseña que contiene.

Comprueba que está arreglado

for p in actuator/health actuator/env telescope/requests _ignition/health-check _profiler .vscode/sftp.json server-status phpmyadmin/; do
  printf "%-26s " "$p"; curl -s -o /dev/null -w "%{http_code}\n" "https://tudominio.com/$p"
done

Lo esperado es 404, 403 o 401 en todos. Un 200 solo es aceptable si lo que devuelve es tu página genérica y no la herramienta.

Preguntas frecuentes

Mi panel pide contraseña. ¿Sigue siendo un hallazgo?

Scanaris comprueba el contenido, así que un panel protegido con autenticación que devuelve 401 no se marca. Aun así, un phpMyAdmin con login es un objetivo de fuerza bruta; mejor fuera de internet.

¿Y /actuator/health? Solo dice "UP".

Confirma qué tecnología usas y qué versión de Spring, y suele indicar que los demás endpoints también están expuestos. Si necesitas un health check público para tu balanceador, crea una ruta propia mínima en vez de abrir el actuator.

Uso Next.js o Nuxt. ¿Esto me aplica?

Estas rutas concretas no, pero el principio sí: las rutas de API de depuración o de semilla (/api/debug, /api/seed) que la IA crea para probar tienen que desaparecer antes de desplegar.