Scansione esterna passiva. Ogni risultato include l'osservazione grezza del relativo scanner
e un comando da eseguire autonomamente per riprodurla: nulla di quanto riportato è generato da un modello.
14 gruppi di controllo:
Risoluzione DNS e verifica dei record CAA · Verifica di SPF e DMARC · Analisi del certificato TLS e delle versioni del protocollo · Test del reindirizzamento da HTTP a HTTPS · Lettura delle intestazioni di sicurezza della risposta · Verifica degli attributi dei cookie · Analisi della policy CORS · Ricerca di banner di versione · Verifica dei metodi HTTP consentiti · Scansione della homepage alla ricerca di contenuti misti e moduli non sicuri · Ricerca di file di configurazione e di controllo versione esposti · Verifica della presenza di elenchi di directory · Lettura di robots.txt e security.txt · Verifica delle porte di servizio esposte
Avvio in corso…
0%
Informazioni Scansione sicurezza sito web
Molti scanner ti consegnano un voto in lettere e un elenco di parole allarmanti. Anche questo dà un voto, ma ogni punto tolto è legato a un rilievo che mostra la risposta ottenuta davvero e il comando di una riga che ti restituisce la stessa risposta: un rilievo è qualcosa che puoi verificare, non qualcosa a cui devi credere.
Cosa fa
Controlla DNS e CAA, SPF e DMARC, il certificato TLS e TLS 1.0/1.1, il reindirizzamento a HTTPS, gli header di sicurezza, gli attributi dei cookie, CORS, i banner di versione, i metodi HTTP, i contenuti misti, 23 percorsi sensibili, gli elenchi di directory, robots.txt, security.txt e 12 porte di servizio.
Ogni risultato porta con sé l'osservazione grezza e un comando shell per riprodurlo.
I controlli che non sono riusciti a eseguire vengono segnalati come "non controllato" - mai silenziosamente come superati.
3Leggi i risultati, ciascuno con la sua prova, e verifica quelli che contano.
Nessun risultato è inventato
Lo scanner non contiene alcun modello linguistico. Gravità, impatto e correzione sono fissi per ogni controllo, e ogni rilievo nasce da un'osservazione reale. Il report a schermo e i download in Markdown e JSON sono costruiti dagli stessi rilievi, senza alcun modello.
Come si calcola il voto
Il punteggio parte da 100 e perde 34 punti per ogni rilievo critico, 13 per ogni alto, 5 per ogni medio e 1,5 per ogni basso, con un tetto per gravità (alto 45, medio 22, basso 9). I risultati informativi e superati non costano nulla. Da 90 in su è A, da 75 B, da 60 C, da 40 D, sotto F. Un solo file .env esposto o una porta di database raggiungibile porta un sito pulito da 100 a 66, una C; due rilievi così danno 32, una F.
Come evita i falsi allarmi
Prima di sondare percorsi come /.git/HEAD o /backup.sql, lo scanner richiede un indirizzo casuale che non può esistere e registra come risponde il sito. Un percorso è segnalato come esposto solo se restituisce HTTP 200, differisce da quella risposta di riferimento e corrisponde alla firma del file stesso, così un sito che risponde a ogni URL con la home page non si riempie di rilievi critici.
Un rapporto pulito non è un certificato
Questi sono controlli passivi su un sito in funzione. Non coprono la logica dell'applicazione, l'autenticazione, il controllo degli accessi, o qualsiasi cosa dietro un login - i luoghi dove le violazioni reali di solito iniziano. I controlli che non sono riusciti a completarsi sono elencati come non controllati esattamente per questo motivo: un superamento derivato da una connessione fallita è una falsa rassicurazione, e una scansione senza risultati significa che non è stato trovato nulla, non che non ci sia nulla.
Scansiona solo ciò che è tuo
Scansiona domini che possiedi o per cui hai un permesso scritto di test. Lo strumento rifiuta host che si risolvono in indirizzi privati o interni, ed è limitato per IP, ma l'autorizzazione resta comunque tua responsabilità.
Domande
Questo è un attacco attivo?
No. Esegue normali richieste GET, HEAD e OPTIONS, handshake TLS (compresi tentativi con TLS 1.0 e 1.1), interrogazioni DNS tramite il DNS su HTTPS di Cloudflare e semplici connessioni TCP verso 12 porte. Nulla viene sfruttato, nessun modulo viene inviato e nulla viene modificato.
Posso scansionare qualsiasi sito web?
Solo quelli che possiedi o che sei autorizzato a testare. Scansionare infrastrutture di terze parti senza permesso può essere illegale dove ti trovi.
Perché un controllo dice "non controllato"?
Perché non è stato possibile completarlo - di solito perché nulla ha risposto su quell'origine. Viene segnalato onestamente invece di essere registrato come superato.
Posso esportare il rapporto?
Sì, in Markdown o JSON, per un'ora: il report resta nella cache del server per quel tempo così i download funzionano, poi scade. Nessuna esportazione usa un modello. Il registro d'uso contiene il numero di rilievi e il voto, non il dominio.
Quali file e porte controlla?
File: 23 percorsi fissi, tra cui /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env, e ciascuno viene segnalato solo se la risposta corrisponde alla firma propria di quel file; /.well-known/security.txt conta a tuo favore se è pubblicato. Porte: una semplice connessione TCP, mai un tentativo di accesso, verso 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080. Una porta di database raggiungibile (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) o Telnet è valutata critica.
Cosa segnalano i controlli SPF e DMARC?
Entrambi i record vengono letti dal DNS pubblico, anche per un sito che non invia email, perché senza di essi chiunque può inviare email che sembrano provenire dal tuo dominio. Nessun record SPF è media; un SPF che contiene +all, che autorizza qualsiasi server su internet, è alta. Nessun record DMARC in _dmarc è media; p=none (o nessun tag p=) si limita a monitorare ed è bassa; p=quarantine o p=reject supera il controllo. Un dominio che non invia alcuna email può pubblicare v=spf1 -all.
Quali header di sicurezza controlla e quale valore supera il controllo?
Sei header nella risposta della tua homepage. Se mancano, HSTS e Content-Security-Policy sono alta, X-Content-Type-Options e X-Frame-Options media, Referrer-Policy e Permissions-Policy bassa. Strict-Transport-Security richiede un max-age di almeno 15552000 (180 giorni): inferiore è bassa, max-age=0 è media. Content-Security-Policy viene segnalata come indebolita (media) se script-src consente 'unsafe-inline', la policy consente 'unsafe-eval' o default-src o script-src contengono un carattere jolly * isolato. X-Content-Type-Options deve essere esattamente nosniff. X-Frame-Options deve essere DENY o SAMEORIGIN, e non serve se la CSP imposta frame-ancestors. Referrer-Policy viene segnalata solo con unsafe-url o no-referrer-when-downgrade. Permissions-Policy deve solo essere presente. Ogni header mancante o debole è accompagnato da un comando curl -sI per verificarlo da solo.
Come controlla gli attributi dei cookie (Secure, HttpOnly, SameSite)?
Legge ogni header Set-Cookie nella risposta della tua homepage (fino a 12 cookie) e controlla per ciascuno Secure, HttpOnly e SameSite. Se manca Secure o HttpOnly la gravità è media; se manca solo SameSite è bassa, e SameSite=None senza Secure viene segnalato perché i browser rifiutano quel cookie. Un cookie con tutti e tre gli attributi è promosso. La correzione abituale è Secure; HttpOnly; SameSite=Lax (in Django: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY e SESSION_COOKIE_SAMESITE). La scansione non effettua l'accesso, quindi i cookie impostati solo dopo il login non vengono visti. Verificalo da solo con curl -sI https://your-site/ | grep -i set-cookie
Come funziona il controllo CORS e quando è critico?
Invia una richiesta GET alla tua homepage con Origin: https://scanner-probe.example e legge Access-Control-Allow-Origin e Access-Control-Allow-Credentials nella risposta. Nessun header Access-Control-Allow-Origin, o un'origine fissa che non ripete quella del test, è promosso. Restituire l'origine del test insieme ad Access-Control-Allow-Credentials: true è critico, perché qualsiasi sito visitato da un utente autenticato potrebbe leggere le sue risposte. Restituire l'origine senza credenziali è media. Un carattere jolly * è bassa, o media se sono consentite anche le credenziali (i browser rifiutano questa combinazione). Viene testata solo la homepage e non viene inviata alcuna richiesta preflight OPTIONS, quindi verifica le route della tua API a parte con curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
Che cosa verifica il controllo TLS (scadenza del certificato, TLS 1.0 e 1.1)?
Si collega alla porta 443 e convalida la catena del certificato e il nome host. Un certificato che non si convalida è di gravità alta, uno scaduto viene segnalato anche come critico e uno con meno di 15 giorni rimasti è medio; altrimenti soggetto, emittente, data di scadenza e nomi SAN vengono mostrati come superato. Il protocollo negoziato deve essere TLS 1.2 o TLS 1.3, qualsiasi versione precedente è alta. Poi prova separatamente un handshake TLS 1.0 e uno TLS 1.1: se il server ne accetta uno, il risultato è medio, perché entrambi sono deprecati dalla RFC 8996. Se l'OpenSSL dello scanner non può offrire la versione vecchia, non viene segnalato nulla invece di tirare a indovinare. La correzione in nginx è ssl_protocols TLSv1.2 TLSv1.3; Controlla le date da solo con echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
Controlla che HTTP reindirizzi a HTTPS?
Sì. Richiede http://your-site/ senza seguire i reindirizzamenti. Un 301 o 308 verso un indirizzo https:// è superato. Un 302, 303 o 307 verso HTTPS è basso, perché i browser non ricordano un reindirizzamento temporaneo e ogni nuova visita inizia con una richiesta non cifrata. Una pagina servita in HTTP non cifrato (risposta 2xx) è alta. Se la porta 80 non risponde affatto, è informativo, non un errore. La correzione in nginx è server { listen 80; return 301 https://$host$request_uri; }, poi aggiungi Strict-Transport-Security. Controlla da solo con curl -I http://your-site/
Quali metodi HTTP segnala (TRACE, PUT, DELETE)?
Invia una sola richiesta OPTIONS alla tua home page e legge l'intestazione Allow, oppure Access-Control-Allow-Methods se Allow manca. TRACE, TRACK, PUT o DELETE annunciati sono di gravità media; PATCH o CONNECT da soli sono bassi; solo metodi di lettura standard è superato. Se il server non invia nessuna delle due intestazioni, non viene segnalato nulla. Annunciare un metodo non prova che funzioni, quindi verificalo prima di cambiare qualcosa. TRACE può rimandare al chiamante le intestazioni della richiesta, cookie compresi (Cross-Site Tracing). nginx rifiuta TRACE per impostazione predefinita; su Apache imposta TraceEnable Off. Limita PUT e DELETE alle route API che ne hanno bisogno, dietro autenticazione. Controlla da solo con curl -X OPTIONS -i https://your-site/
Come rileva il directory listing ("Index of /")?
Richiede 7 percorsi: /, /static/, /assets/, /uploads/, /images/, /files/ e /backup/. Un percorso che risponde HTTP 200 con una pagina il cui titolo o intestazione principale inizia con "Index of /" viene segnalato come medio (CWE-548), perché l'elenco mostra file non collegati da nessuna parte, come backup, esportazioni e vecchie versioni. Se nessuno lo fa, il controllo è superato; se il sito non è raggiungibile, risulta non eseguito. La correzione su nginx è autoindex off; (il valore predefinito, quindi cerca un autoindex on esplicito), su Apache Options -Indexes, poi sposta fuori dalla web root tutto ciò che è sensibile. Controlla da solo con curl -s https://your-site/uploads/ | head -20
Rileva i contenuti misti e i moduli che inviano in HTTP?
Sì, sulla homepage. Legge l'HTML così come viene servito (nessun JavaScript viene eseguito) ed elenca ogni tag script, link, iframe o img il cui src o href inizia con http://. Se uno di questi è un file .js o .css il risultato è medio, perché uno script o un foglio di stile sostituito durante il transito viene eseguito nella tua pagina HTTPS; solo immagini e frame danno basso; nessuno è superato (CWE-311). Un modulo il cui action inizia con http:// è valutato alto (CWE-319), perché tutto ciò che vi si digita, password comprese, viaggia in chiaro. La correzione: portare quegli URL a https:// o renderli relativi, e aggiungere l'header Content-Security-Policy: upgrade-insecure-requests come rete di sicurezza. Verificalo tu con curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
Cosa controlla in robots.txt e security.txt?
robots.txt: scarica /robots.txt e, se risponde HTTP 200 come file di testo, legge le righe Disallow nei primi 8000 caratteri. Un percorso Disallow che contiene admin, internal, private, backup, config, staging, test, api, secret, dev è valutato basso (CWE-200): robots.txt è pubblico e chiede soltanto ai crawler corretti di non entrare, quindi elencare quei percorsi li pubblicizza. Proteggili con un login e usa noindex per tenere le pagine fuori dalla ricerca. security.txt: richiede /.well-known/security.txt, la posizione stabilita dalla RFC 9116, e lo conta a tuo favore quando il file ha una riga Contact:. Se manca, non perdi punti. La RFC 9116 richiede anche un campo Expires:, che la scansione non controlla, quindi pubblica entrambi, per esempio Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z. Verificalo tu con curl -s https://your-site/.well-known/security.txt
Cosa cerca il controllo CAA e come aggiungo un record CAA?
Interroga i record CAA (RFC 8659) del nome host inserito, tramite DNS over HTTPS di Cloudflare. Se ne trova, il controllo è superato e la prova ne mostra fino a 5; se non ne trova, segnala "No CAA record" con gravità bassa, perché allora qualsiasi autorità di certificazione pubblica può emettere un certificato per quel nome. Un record CAA elenca le CA che usi davvero, per esempio your-site. IN CAA 0 issue "letsencrypt.org", più 0 iodef "mailto:security@your-site" per ricevere le segnalazioni. Aggiungi una riga issue per ogni CA che usi e una riga issuewild se i certificati wildcard devono arrivare da un'altra CA. Verifica tu stesso con dig CAA your-site
Perché la scansione di www o di un sottodominio segnala che mancano CAA, SPF o DMARC?
Ogni controllo DNS gira sul nome esatto inserito, quindi www.example.com viene interrogato come www.example.com, non come example.com, e i tre record si ereditano in modo diverso. CAA: un'autorità di certificazione che non trova record CAA su www.example.com sale a example.com e usa quello (RFC 8659, sezione 3), quindi "No CAA record" su un sottodominio può essere un falso allarme. DMARC: i destinatari ricorrono alla policy del dominio organizzativo, che può fissare una policy separata per i sottodomini con sp= (RFC 9989, che rende obsoleto l'RFC 7489), quindi un record mancante in _dmarc.www.example.com di solito è coperto da _dmarc.example.com. SPF: non c'è ereditarietà (RFC 7208), quindi "No SPF record" è corretto per quel nome; un nome host che non invia email può pubblicare v=spf1 -all. Anche una query DNS fallita appare come record mancante. Scansiona anche il dominio senza www, oppure verifica con dig CAA example.com e dig TXT _dmarc.example.com