Capire se un sito è sicuro: guida tecnica per una verifica consapevole
Ecco una guida dettagliata su come capire se un sito è sicuro. La prima verifica da fare è vedere se l’indirizzo inizi con HTTPS e non solo che compaia il lucchetto: il simbolo, da solo, non garantisce affidabilità. Apri i dettagli del certificato e controlla emittente, validità e Subject Alternative Name (SAN), che deve includere il dominio visitato, il Common Name infatti non è più sufficiente. Un sito ben configurato usa TLS 1.2 o 1.3, evita suite di cifratura deboli e preferisce chiavi con forward secrecy. La presenza dell’header Strict-Transport-Security (HSTS) impone l’uso di HTTPS anche in caso di errori o redirect, riducendo i rischi di downgrade. Verifica che non ci sia mixed content: il caricamento di risorse in HTTP su una pagina HTTPS vanifica la protezione. Un ulteriore segnale positivo è l’OCSP stapling, che accelera e rende più solida la verifica di revoca del certificato, e la presenza di SCT per i Certificate Transparency log, utile a rilevare certificati emessi in modo improprio. Se il sito reindirizza sistematicamente http → https con 301 e risponde con un set coerente di cifrari moderni, la base crittografica è in ordine.
Come capire se un sito è sicuro: header di sicurezza
Passa poi alla superficie applicativa. Un sito attento espone header come Content-Security-Policy (CSP) per limitare le origini da cui può essere eseguito JavaScript, caricato CSS o immagini; politiche restrittive riducono drasticamente XSS e injection. L’uso di Subresource Integrity (SRI) sui file di terze parti (ad esempio librerie su CDN) garantisce che il contenuto non sia stato alterato. Controlla Referrer-Policy per evitare leakage di URL sensibili, X-Content-Type-Options: nosniff per prevenire MIME sniffing, e X-Frame-Options o frame-ancestors in CSP per mitigare clickjacking. I cookie di sessione devono essere marcati Secure, HttpOnly e con SameSite (idealmente Lax o Strict; None solo se necessario e sempre con Secure). Occhio a script pesantemente offuscati che eseguono eval o creano iframe opachi: in contesti legittimi esistono, ma sono un campanello d’allarme se abbinati a comportamenti anomali. Lato infrastruttura, la presenza di DNSSEC sul dominio riduce il rischio di spoofing DNS; la corretta igiene del dominio (record SPF, DKIM, DMARC per la posta) non fa sicurezza web in senso stretto, ma indica una gestione attenta. Evita siti con directory listing attivo, risorse sensibili esposte (.git, backup) o librerie molto datate con note CVE.
Comportamento, reputazione e compliance: segni di affidabilità “viva”
Infine valuta il comportamento runtime. Un sito sicuro non inonda l’utente di pop-up, non tenta download non richiesti, non richiede permessi eccessivi del browser e non effettua redirect a catena verso domini opachi. I form inviano dati solo su HTTPS, includono token anti-CSRF e mascherano in modo corretto i campi sensibili. Le pagine di pagamento dovrebbero appoggiarsi a gateway certificati PCI DSS o a provider noti; diffida di integrazioni custom improvvisate. La presenza di una privacy policy chiara, di un cookie banner realmente granulare e di riferimenti societari verificabili è un buon segno in chiave GDPR. Indicatori tecnici ulteriori sono un set di rate limit sugli endpoint, codici di risposta coerenti, tempi di TTFB stabili e assenza di risposte di debug in chiaro. Un plus è il file /.well-known/security.txt, che indica un canale per segnalare vulnerabilità. Incrocia questi controlli con la reputazione del dominio e l’anzianità WHOIS senza cadere in bias: TLD “esotici” o domini giovani non significano automaticamente rischio. Se più segnali tecnici convergono — TLS moderno, HSTS, CSP/SRI, cookie sicuri, DNSSEC e comportamento pulito — puoi considerare il sito ragionevolmente sicuro dal punto di vista dell’utente finale.
