Scanner di log esposti

Come funziona questo controllo

Scanaris richiede sette percorsi dove le applicazioni più comuni scrivono i loro log quando nessuno dice loro altrimenti: /debug.log, /error.log, /error_log, /laravel.log, /storage/logs/laravel.log, /npm-debug.log e /wp-content/debug.log. Se uno di essi risponde con un file di testo che somiglia a un log, e non con la pagina generica del tuo sito, apre un rilievo di gravità media con il percorso. I log raramente contengono tutto il database, da qui il non essere critici; ma pochi file dicono così tanto sul funzionamento interno del tuo sito.

Perché è importante

Un log degli errori è il diario di tutto ciò che è fallito: percorsi interni del server, nomi di file e di funzioni, versioni esatte delle librerie, query al database fallite con i loro parametri, indirizzi IP degli utenti, a volte e-mail o token apparsi in una richiesta. Con questo, chi cerca una vulnerabilità sa esattamente dove guardare e quale versione attaccare. E il log cresce: ogni giorno di esposizione racconta di più.

Perché succede

WordPress con WP_DEBUG_LOG attivo scrive in wp-content/debug.log, che è una cartella pubblica; è il caso più frequente. Laravel tiene i suoi log in storage/logs, che non dovrebbe essere raggiungibile, ma lo è quando il server punta alla radice del progetto invece che a public/. Apache in hosting condiviso lascia error_log accanto ai file del sito. E npm-debug.log compare quando un'installazione è fallita sul server e nessuno ha pulito.

Come risolvere

• WordPress: in produzione, define('WP_DEBUG', false); in wp-config.php. Se ti serve il log temporaneamente, spostalo fuori dalla cartella pubblica con define('WP_DEBUG_LOG', '/percorso/privato/debug.log'); ed elimina il file attuale.
• Laravel: il server web deve puntare alla cartella public/ del progetto, mai alla radice. Così storage/ smette di essere raggiungibile. E APP_DEBUG=false.
• Node e altri: scrivi i log fuori dalla directory servita e inviali a un servizio di logging se possibile. Elimina npm-debug.log e simili dal server.
• Blocca l'estensione lato server come seconda barriera. In nginx: location ~* \.log$ { deny all; }. In Apache: <FilesMatch "\.log$"> Require all denied </FilesMatch>.
• Riduci ciò che logghi in produzione: livello error invece di debug, senza scaricare corpi di richiesta completi né token.

Verifica che sia risolto

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

Atteso: 404 o 403 ovunque. Se il tuo sito è una single-page app e risponde 200 con il suo HTML, non è il log; aprilo per confermare.

Domande frequenti

Il mio log non contiene nulla di sensibile, solo avvisi PHP.

Quegli avvisi includono i percorsi completi del server e le versioni dei plugin, esattamente ciò che un attaccante usa per scegliere quale exploit provare. E oggi non c'è nulla di sensibile; domani, con un nuovo errore, potrebbe esserci.

Devo disattivare completamente i log?

No. Devono solo non essere pubblici. Logga ciò che vuoi in una cartella che il server web non serve, o in un servizio esterno.

Mi riguarda su Vercel o Netlify?

Quasi mai: lì i log non vengono scritti in file pubblici, si consultano nel pannello. Il rilievo compare soprattutto su server self-hosted, WordPress e hosting condiviso.