Guida alla sicurezza di un sito

HTTPS incapsula il traffico in un canale TLS, garantendo riservatezza e integrità dei dati in transito. La qualità di questo livello dipende da più fattori: le versioni di protocollo abilitate (TLS 1.2 e 1.3 accettabili, le versioni precedenti vanno disattivate), la robustezza dei cipher suite negoziati, la validità e la catena del certificato, e la sua scadenza. Non basta che il certificato esista: la versione in chiaro su HTTP deve reindirizzare verso HTTPS, altrimenti un attaccante in posizione di rete può forzare un downgrade e intercettare la connessione. L'header HSTS (Strict-Transport-Security) rende vincolante l'uso di HTTPS per le visite successive, e l'inclusione nella preload list dei browser ne estende la protezione anche alla primissima visita.

Gli header di risposta istruiscono il browser su come trattare i contenuti del sito, neutralizzando intere classi di attacco prima che il codice entri in gioco. I principali sono: la Content-Security-Policy, che definisce le origini autorizzate per script e risorse ed è la difesa primaria contro l'XSS; X-Frame-Options o la direttiva frame-ancestors, contro il clickjacking; X-Content-Type-Options, che blocca il MIME sniffing; Referrer-Policy, che limita la fuga di URL interni verso siti terzi; Permissions-Policy, che restringe l'accesso alle API sensibili del browser (geolocalizzazione, fotocamera, microfono, pagamenti). Sui siti moderni si aggiungono gli header di isolamento cross-origin (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy), che proteggono da una categoria di attacchi basati sulla condivisione di memoria tra contesti. L'assenza di questi header non implica una compromissione, ma segnala una configurazione difensiva incompleta.

I cookie che trasportano l'identità dell'utente vanno protetti a livello di configurazione con tre attributi: Secure, che ne impedisce l'invio su connessioni non cifrate; HttpOnly, che li rende inaccessibili al JavaScript e quindi più difficili da rubare tramite XSS; SameSite, che ne limita l'invio in contesti cross-site, mitigando gli attacchi CSRF. Sono impostazioni indipendenti dalla logica applicativa e spesso lasciate ai valori di default, meno sicuri.

Un dominio senza autenticazione della posta è facilmente impersonabile: chiunque può inviare messaggi che sembrano provenire dai tuoi indirizzi. La difesa si costruisce su record DNS pubblici. SPF dichiara i server autorizzati all'invio; DKIM firma crittograficamente i messaggi; DMARC stabilisce la policy sui messaggi non autenticati (monitoraggio, quarantena o rifiuto) e ne raccoglie la reportistica. A questi si aggiungono meccanismi più avanzati: MTA-STS e TLS-RPT, che impongono e rendicontano il trasporto cifrato della posta, e BIMI, che lega il logo del brand a un'autenticazione DMARC rigorosa. È l'insieme che rende un dominio difficile da usare per phishing e frodi a tuo nome.

Il DNS è la radice della fiducia: se è manipolabile, cade tutto il resto. DNSSEC firma crittograficamente le risposte DNS, prevenendo lo spoofing e l'avvelenamento della cache. Il record CAA vincola quali autorità possono emettere certificati per il dominio, riducendo il rischio di certificati fraudolenti. Vanno inoltre evitati i record "dangling" — voci che puntano a servizi esterni non più attivi — che aprono la porta al subdomain takeover, cioè alla possibilità per un estraneo di rivendicare un sottodominio abbandonato e servirvi contenuti a tuo nome.

Ogni informazione che il perimetro rivela agevola un attaccante. Gli header Server e X-Powered-By possono divulgare software e versione esatta dell'infrastruttura, indirizzando la ricerca di exploit noti. Sullo stesso piano stanno i file sensibili lasciati accessibili (cartelle di controllo versione, file di ambiente con credenziali, backup, dump di database), il listing delle directory abilitato per errore e le pagine di errore verbose che espongono percorsi interni, stack trace o dettagli del framework. Il principio guida è la minima esposizione: mostrare all'esterno solo ciò che è strettamente necessario.

Al confine tra internet e il sito operano le difese di rete: un Web Application Firewall che filtra il traffico ostile, il rate limiting che frena brute force e abusi automatici, la protezione anti-DDoS che assorbe i picchi malevoli. Rientrano qui anche la restrizione dei metodi HTTP consentiti (disabilitando quelli non necessari) e la protezione dei pannelli di amministrazione dietro autenticazione forte e restrizioni di rete. Sono controlli di configurazione dell'infrastruttura, non del codice.

La sicurezza è anche processo. Il file security.txt (standard RFC 9116) pubblica un canale di contatto per la segnalazione responsabile delle vulnerabilità: la sua presenza indica un'organizzazione che ha previsto cosa fare quando qualcuno scopre un problema, invece di improvvisare. È un segnale di maturità, non un requisito tecnico.

Tutto quanto sopra è osservabile e valutabile dall'esterno senza toccare il sito. Resta fuori, per definizione, il livello applicativo: vulnerabilità nel codice (SQL injection, XSS attivi, difetti di autorizzazione), robustezza effettiva delle credenziali, sicurezza delle dipendenze e configurazione dei sistemi interni. Quel livello richiede revisione del codice e penetration test condotti da specialisti — un'attività diversa, attiva e mirata, che un controllo di superficie non sostituisce né pretende di sostituire. Conoscere con precisione questo confine è parte del lavoro fatto bene: dichiarare cosa si copre, e cosa no, è la prima misura di serietà.