Scanner de panneaux exposés

Comment fonctionne cette vérification

Scanaris demande une liste de chemins correspondant à des panneaux et outils de débogage qui ne devraient jamais répondre en production, et vérifie que la réponse est bien celle de l'outil et pas la page générique de ton site. Les chemins et leur sévérité : /actuator/health de Spring Boot (élevée), /actuator/env et /actuator/heapdump (critiques : variables d'environnement et vidage mémoire), /telescope/requests de Laravel Telescope (élevée), /_ignition/health-check de Laravel Ignition en mode debug (critique, parce que des versions vulnérables permettaient d'exécuter du code), /_profiler de Symfony (élevée), /.vscode/sftp.json avec des identifiants de déploiement (critique), /server-status d'Apache (moyenne) et /phpmyadmin/ (élevée).

Pourquoi c'est important

Ces outils existent pour montrer les entrailles de l'application à celui qui la développe : configuration, variables d'environnement avec mots de passe, requêtes récentes avec leurs paramètres, traces d'erreur complètes, contenu de la mémoire du processus. En développement, ils sont précieux ; en production, ouverts sur internet, c'est une porte avec la clé dessus. Un /actuator/env accessible contient souvent la chaîne de connexion à la base. Un phpMyAdmin public est un point d'entrée pour tester des mots de passe contre ta base 24 heures sur 24.

Pourquoi ça arrive

Parce que la même configuration sert au développement et à la production. Le mode debug de Laravel (APP_DEBUG=true), les endpoints Actuator exposés par défaut dans les vieilles versions de Spring, le profiler Symfony avec APP_ENV=dev, un phpMyAdmin installé « pour regarder la base un instant » et jamais retiré. Les outils d'IA qui génèrent le projet distinguent rarement les environnements, et le déploiement hérite de la configuration de développement.

Comment corriger

• Laravel : APP_DEBUG=false et APP_ENV=production dans le .env de production. Telescope seulement en local (TELESCOPE_ENABLED=false ou le gate d'autorisation). Mets à jour Ignition vers une version sans la vulnérabilité.
• Spring Boot : management.endpoints.web.exposure.include=health au maximum, sans env ni heapdump, et avec une sécurité devant /actuator. Mieux encore, expose l'actuator sur un port de gestion distinct qui ne sort pas sur internet.
• Symfony : APP_ENV=prod et APP_DEBUG=0 ; le profiler n'est enregistré qu'en dev.
• phpMyAdmin : désinstalle-le du serveur public. Si tu en as besoin, accède-y par tunnel SSH ou restreins-le par IP avec une authentification supplémentaire.
• Apache server-status : Require ip 127.0.0.1 dans la directive Location /server-status, ou désactive le module.
• Fichiers d'éditeur comme .vscode/sftp.json : ils ne doivent jamais être déployés. Ajoute .vscode/ au .gitignore et, s'il a été publié, change le mot de passe qu'il contient.

Vérifie que c'est corrigé

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://tondomaine.com/$p"
done

Attendu : 404, 403 ou 401 partout. Un 200 n'est acceptable que si ce qu'il renvoie est ta page générique et non l'outil.

Questions fréquentes

Mon panneau demande un mot de passe. Est-ce encore un constat ?

Scanaris vérifie le contenu, donc un panneau protégé par authentification qui renvoie 401 n'est pas signalé. Malgré tout, un phpMyAdmin avec login est une cible de force brute ; mieux vaut hors d'internet.

Et /actuator/health ? Il dit seulement « UP ».

Il confirme la technologie et la version de Spring que tu utilises, et indique généralement que les autres endpoints sont exposés aussi. Si tu as besoin d'un health check public pour ton équilibreur, crée une route minimale à toi plutôt que d'ouvrir l'actuator.

J'utilise Next.js ou Nuxt. Ça me concerne ?

Ces chemins précis non, mais le principe oui : les routes d'API de débogage ou de seed (/api/debug, /api/seed) que l'IA crée pour tester doivent disparaître avant le déploiement.