Scanner voor blootgestelde panels

Hoe deze controle werkt

Scanaris vraagt een lijst paden op die horen bij panelen en debugtools die in productie nooit zouden moeten antwoorden, en controleert dat het antwoord echt dat van de tool is en niet de generieke pagina van je site. De paden en hun ernst: /actuator/health van Spring Boot (hoog), /actuator/env en /actuator/heapdump (kritiek: omgevingsvariabelen en geheugendump), /telescope/requests van Laravel Telescope (hoog), /_ignition/health-check van Laravel Ignition in debugmodus (kritiek, omdat kwetsbare versies code lieten uitvoeren), /_profiler van Symfony (hoog), /.vscode/sftp.json met deploy-inloggegevens (kritiek), /server-status van Apache (gemiddeld) en /phpmyadmin/ (hoog).

Waarom dit belangrijk is

Deze tools bestaan om wie de applicatie ontwikkelt het binnenste te laten zien: configuratie, omgevingsvariabelen met wachtwoorden, recente verzoeken met hun parameters, volledige foutsporen, inhoud van het procesgeheugen. In ontwikkeling zijn ze waardevol; in productie, open op internet, zijn ze een deur met de sleutel erin. Een bereikbare /actuator/env bevat vaak de verbindingsstring naar de database. Een openbare phpMyAdmin is een ingang om 24 uur per dag wachtwoorden tegen je database te proberen.

Waarom het gebeurt

Omdat dezelfde configuratie dient voor ontwikkeling en productie. De debugmodus van Laravel (APP_DEBUG=true), de Actuator-endpoints die in oude Spring-versies standaard open staan, de Symfony-profiler met APP_ENV=dev, een phpMyAdmin die "even om in de database te kijken" is geïnstalleerd en nooit verwijderd. AI-tools die het project genereren, maken zelden onderscheid tussen omgevingen, en de deploy erft de ontwikkelconfiguratie.

Hoe je het oplost

• Laravel: APP_DEBUG=false en APP_ENV=production in de .env van productie. Telescope alleen lokaal (TELESCOPE_ENABLED=false of de autorisatie-gate). Werk Ignition bij naar een versie zonder de kwetsbaarheid.
• Spring Boot: hooguit management.endpoints.web.exposure.include=health, zonder env of heapdump, en met security voor /actuator. Nog beter: stel de actuator beschikbaar op een aparte managementpoort die niet op internet uitkomt.
• Symfony: APP_ENV=prod en APP_DEBUG=0; de profiler wordt alleen in dev geregistreerd.
• phpMyAdmin: verwijder het van de openbare server. Heb je het nodig, benader het dan via een SSH-tunnel of beperk het op IP met extra authenticatie.
• Apache server-status: Require ip 127.0.0.1 in de richtlijn Location /server-status, of schakel de module uit.
• Editorbestanden zoals .vscode/sftp.json: die mogen nooit worden gedeployd. Voeg .vscode/ toe aan de .gitignore en, als het is gepubliceerd, wijzig het wachtwoord dat erin staat.

Controleer of het opgelost is

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://jouwdomein.nl/$p"
done

Verwacht: overal 404, 403 of 401. Een 200 is alleen acceptabel als wat terugkomt je generieke pagina is en niet de tool.

Veelgestelde vragen

Mijn paneel vraagt een wachtwoord. Is dat nog steeds een bevinding?

Scanaris controleert de inhoud, dus een door authenticatie beschermd paneel dat 401 teruggeeft, wordt niet gemeld. Toch is een phpMyAdmin met login een brute-force-doelwit; beter buiten internet.

En /actuator/health? Die zegt alleen "UP".

Die bevestigt de technologie en de Spring-versie die je gebruikt, en wijst er meestal op dat de andere endpoints ook open staan. Heb je een openbare health check nodig voor je load balancer, maak dan een eigen minimale route in plaats van de actuator te openen.

Ik gebruik Next.js of Nuxt. Geldt dit voor mij?

Deze specifieke paden niet, maar het principe wel: debug- of seed-API-routes (/api/debug, /api/seed) die de AI aanmaakt om te testen, moeten weg voor de deploy.