Scanner di pannelli esposti

Come funziona questo controllo

Scanaris richiede una lista di percorsi che corrispondono a pannelli e strumenti di debug che non dovrebbero mai rispondere in produzione, e verifica che la risposta sia davvero quella dello strumento e non la pagina generica del tuo sito. I percorsi e la loro gravità: /actuator/health di Spring Boot (alta), /actuator/env e /actuator/heapdump (critici: variabili d'ambiente e dump della memoria), /telescope/requests di Laravel Telescope (alta), /_ignition/health-check di Laravel Ignition in modalità debug (critica, perché versioni vulnerabili permettevano di eseguire codice), /_profiler di Symfony (alta), /.vscode/sftp.json con credenziali di deploy (critica), /server-status di Apache (media) e /phpmyadmin/ (alta).

Perché è importante

Questi strumenti esistono per mostrare le interiora dell'applicazione a chi la sviluppa: configurazione, variabili d'ambiente con password, richieste recenti con i loro parametri, stack trace completi, contenuto della memoria del processo. In sviluppo sono preziosi; in produzione, aperti su internet, sono una porta con la chiave inserita. Un /actuator/env raggiungibile contiene spesso la stringa di connessione al database. Un phpMyAdmin pubblico è un punto d'ingresso per provare password contro il tuo database 24 ore su 24.

Perché succede

Perché la stessa configurazione serve per sviluppo e produzione. La modalità debug di Laravel (APP_DEBUG=true), gli endpoint Actuator esposti di default nelle vecchie versioni di Spring, il profiler di Symfony con APP_ENV=dev, un phpMyAdmin installato «per guardare il database un attimo» e mai rimosso. Gli strumenti di IA che generano il progetto raramente distinguono gli ambienti, e il deploy eredita la configurazione di sviluppo.

Come risolvere

• Laravel: APP_DEBUG=false e APP_ENV=production nel .env di produzione. Telescope solo in locale (TELESCOPE_ENABLED=false o il gate di autorizzazione). Aggiorna Ignition a una versione senza la vulnerabilità.
• Spring Boot: al massimo management.endpoints.web.exposure.include=health, senza env né heapdump, e con la security davanti a /actuator. Meglio ancora, esponi l'actuator su una porta di management separata che non esce su internet.
• Symfony: APP_ENV=prod e APP_DEBUG=0; il profiler viene registrato solo in dev.
• phpMyAdmin: disinstallalo dal server pubblico. Se ti serve, accedi via tunnel SSH o limitalo per IP con un'autenticazione aggiuntiva.
• Apache server-status: Require ip 127.0.0.1 nella direttiva Location /server-status, o disattiva il modulo.
• File dell'editor come .vscode/sftp.json: non devono mai essere deployati. Aggiungi .vscode/ al .gitignore e, se è stato pubblicato, cambia la password che contiene.

Verifica che sia risolto

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://tuodominio.it/$p"
done

Atteso: 404, 403 o 401 ovunque. Un 200 è accettabile solo se ciò che restituisce è la tua pagina generica e non lo strumento.

Domande frequenti

Il mio pannello chiede una password. È comunque un rilievo?

Scanaris verifica il contenuto, quindi un pannello protetto da autenticazione che restituisce 401 non viene segnalato. Comunque, un phpMyAdmin con login è un bersaglio di forza bruta; meglio fuori da internet.

E /actuator/health? Dice solo «UP».

Conferma la tecnologia e la versione di Spring che usi, e di solito indica che anche gli altri endpoint sono esposti. Se ti serve un health check pubblico per il tuo bilanciatore, crea una rotta minima tua invece di aprire l'actuator.

Uso Next.js o Nuxt. Mi riguarda?

Questi percorsi specifici no, ma il principio sì: le rotte API di debug o di seed (/api/debug, /api/seed) che l'IA crea per testare devono sparire prima del deploy.