Sicurezza dei siti web italiani nel 2026: HTTPS non basta

Il lucchetto accanto all'indirizzo del sito è diventato quasi invisibile. Lo diamo per scontato: il sito usa HTTPS, il browser non mostra avvisi e quindi, istintivamente, lo consideriamo sicuro.

Ma HTTPS protegge soprattutto la comunicazione tra browser e server. Non dice se il sito utilizza correttamente gli header di sicurezza, se i cookie sono protetti, se il dominio è configurato contro lo spoofing via email o se una Content Security Policy è realmente in grado di mitigare determinati attacchi.

Quanto è quindi sicuro, dal punto di vista della configurazione osservabile dall'esterno, il web italiano?

Nel luglio 2026 l'Italian Web Security Study (IWSS) ha analizzato 10.022 domini .it, corrispondenti all'intero insieme di domini italiani presente nella lista Tranco top-1M utilizzata per la ricerca. Lo studio, pubblicato con il titolo Measuring the Security Configuration of the Italian Web: A Large-Scale Passive Measurement Study, offre una fotografia interessante: TLS è ormai maturo, ma molte altre protezioni di base rimangono sorprendentemente poco diffuse.

Chi vuole esplorare direttamente grafici, dati e metodologia può consultare l'analisi interattiva completa dello studio IWSS su f-hack.

10.022 domini analizzati, senza attaccare nessuno

Prima dei risultati è importante capire cosa misura realmente lo studio.

IWSS non è una scansione di vulnerabilità e non tenta di verificare se un sito possa essere compromesso.

La raccolta è stata progettata come misurazione passiva: normali richieste HTTP, handshake TLS, interrogazioni DNS e accesso a risorse pubbliche come robots.txt, sitemap.xml e security.txt. Nessun exploit, brute force, fuzzing o tentativo di autenticazione.

Su 10.020 scansioni completate, 8.829 domini hanno risposto correttamente a una normale richiesta HTTP, pari all'88,1% del totale. Gli altri casi comprendono errori DNS, timeout, connessioni rifiutate, risposte non valide ed errori TLS.

C'è anche una distinzione metodologica importante: 10.022 domini non rappresentano tutti i domini .it esistenti. Sono l'intero sottoinsieme .it presente nella Tranco top-1M dell'8 luglio 2026. Lo studio fotografa quindi una porzione ampia e rilevante del web italiano, ma non pretende di essere il censimento completo del registro .it.

Questa cautela è importante perché nella cybersecurity le percentuali hanno senso solo se è chiaro come sono state ottenute.

Gli header di sicurezza sono ancora poco utilizzati

Una delle evidenze più immediate riguarda gli HTTP Security Headers.

Sono istruzioni che il server invia al browser insieme alla pagina e permettono di imporre alcune restrizioni sul comportamento del browser stesso. Possono mitigare classi di attacchi come clickjacking, content-type sniffing e alcune forme di cross-site scripting.

Sugli 8.829 siti raggiungibili, nessuno degli header analizzati supera il 42% di adozione.

Il dato interessante non è semplicemente che "manca qualche header".

È che protezioni mature, documentate da anni e spesso implementabili a livello di web server o reverse proxy rimangono assenti nella maggioranza dei siti osservati.

HSTS, per esempio, forza il browser a utilizzare HTTPS per le connessioni successive al dominio e riduce il rischio di downgrade verso HTTP. Eppure compare soltanto nel 32,8% dei siti analizzati.

La Content Security Policy è ancora meno diffusa: 18,7%.

Ed è proprio analizzando le CSP che emerge uno dei risultati più interessanti dello studio.

Avere una CSP non significa necessariamente avere una buona CSP

La Content Security Policy permette di dichiarare quali sorgenti il browser può utilizzare per caricare script, stili, immagini, iframe e altre risorse.

Se configurata correttamente può rappresentare un'importante linea difensiva contro il cross-site scripting.

Ma una CSP può esistere formalmente senza essere particolarmente restrittiva.

IWSS ha analizzato nel dettaglio 1.646 policy CSP. Solo 11, pari allo 0,7%, soddisfacevano il criterio di restrittività definito dallo studio: presenza di default-src o script-src, assenza di unsafe-inline, assenza di unsafe-eval e nessuna sorgente wildcard.

Il 45,4% delle CSP osservate utilizzava invece unsafe-inline, mentre l'11,1% permetteva almeno una sorgente wildcard.

Questo dato va interpretato correttamente.

Non significa che il 99,3% dei siti con CSP sia "vulnerabile". La sicurezza di un'applicazione non può essere ridotta a un singolo header.

Significa però che la semplice presenza di Content-Security-Policy non è sufficiente per valutare la qualità della configurazione.

Ed è una lezione applicabile molto oltre la CSP: nei tool automatici, un controllo booleano "presente / assente" è spesso solo il primo livello dell'analisi.

Anche i cookie mostrano margini di miglioramento

Lo studio ha osservato complessivamente 7.240 cookie.

Nel 51,8% mancava SameSite. Nel 51,8% mancava HttpOnly. Nel 47,5% mancava l'attributo Secure.

Sono tre attributi con funzioni differenti.

Secure impedisce al browser di inviare il cookie attraverso connessioni HTTP non cifrate. HttpOnly impedisce normalmente l'accesso al cookie tramite JavaScript eseguito nel browser. SameSite regola invece l'invio del cookie nelle richieste provenienti da altri siti e rappresenta una delle difese utilizzabili contro determinati scenari di CSRF.

Anche qui è necessario evitare conclusioni troppo semplicistiche.

Il dataset non classifica ogni cookie distinguendo, per esempio, un cookie di autenticazione da uno di analytics. L'assenza di HttpOnly su un cookie tecnico di tracciamento non ha lo stesso significato dell'assenza dello stesso attributo su un cookie contenente un identificatore di sessione.

Le percentuali indicano quindi la diffusione degli attributi, non la percentuale di sessioni utente vulnerabili.

È una distinzione piccola solo in apparenza: è ciò che separa una misurazione tecnica da un titolo allarmistico.

TLS è invece la buona notizia

Se header e cookie mostrano molto spazio di miglioramento, il quadro cambia radicalmente quando si osserva la cifratura della connessione.

Su 8.864 handshake completati, l'87,3% ha negoziato TLS 1.3 e il restante 12,7% TLS 1.2.

Nelle connessioni analizzate non sono state rilevate suite crittografiche deboli basate su RC4, DES, MD5 o algoritmi EXPORT.

Da questo punto di vista l'ecosistema web ha compiuto un enorme passo avanti.

HTTPS è passato in pochi anni dall'essere una configurazione da implementare consapevolmente a qualcosa che hosting, CDN, browser e sistemi di certificazione automatica rendono quasi trasparente.

Ed è probabilmente proprio questo il motivo per cui il lucchetto del browser non può più essere considerato un indicatore sufficiente di sicurezza.

Ottenere e rinnovare automaticamente un certificato TLS è ormai relativamente semplice. Configurare correttamente CSP, cookie, autenticazione email e policy applicative richiede invece una maggiore consapevolezza tecnica.

Il problema non riguarda soltanto il sito: SPF, DKIM e DMARC

Un dominio non serve soltanto pagine web.

Può anche essere utilizzato per inviare email, ed è qui che entrano in gioco SPF, DKIM e DMARC.

Su un sottoinsieme di 9.520 scansioni dello studio, SPF è stato rilevato nel 55,5% dei domini, DMARC nel 43,8% e DKIM nel 36,6%.

Questo non significa che il restante 44,5% dei domini possa automaticamente essere impersonato con successo: la sicurezza email dipende da più fattori e dalle policy effettivamente configurate.

Il dato mostra però quanto sia ancora incompleta l'adozione dei meccanismi progettati per autenticare la posta associata a un dominio.

DMARC è particolarmente importante perché permette al proprietario del dominio di indicare ai server destinatari come trattare i messaggi che non superano i controlli di autenticazione e offre strumenti di reporting utili per individuare tentativi di spoofing.

Per un'azienda, la sicurezza del sito e quella dell'email sono problemi tecnicamente distinti ma con un punto in comune: il dominio rappresenta l'identità digitale dell'organizzazione.

Proteggere bene il sito lasciando completamente scoperta la posta elettronica significa proteggere soltanto una parte di quell'identità.

security.txt: presente solo sul 2,4% dei domini

Ancora più rara è la presenza di security.txt.

Lo standard, definito dalla RFC 9116, permette a un'organizzazione di pubblicare informazioni utili a chi scopre un problema di sicurezza: principalmente un canale attraverso cui contattare il responsabile corretto e comunicare la vulnerabilità in modo responsabile.

Nel dataset IWSS il file è stato rilevato soltanto sul 2,4% dei domini analizzati nel sottoinsieme esteso.

Non avere security.txt non rende un sito meno sicuro dal punto di vista tecnico.

Ma la sua quasi totale assenza suggerisce che sul web italiano sia ancora poco diffusa una cultura strutturata della vulnerability disclosure.

Ed è un problema organizzativo prima ancora che tecnologico: anche quando qualcuno vuole comunicare responsabilmente una vulnerabilità, spesso non sa a chi scrivere.

WordPress, Cloudflare o Nginx non sono sinonimi di sicurezza

Lo studio ha raccolto anche informazioni sulle tecnologie osservabili.

Cloudflare è stato rilevato su 3.053 siti, WordPress su 2.487, Nginx su 1.777 e Apache su 1.509.

Questi numeri non rappresentano però una classifica dei prodotti più sicuri o meno sicuri.

Ed è una precisazione importante.

Sapere che un sito utilizza WordPress non consente di determinarne la sicurezza senza conoscere versione, plugin, configurazione, aggiornamenti, infrastruttura e numerosi altri fattori. Allo stesso modo, la presenza di Cloudflare non garantisce automaticamente una configurazione applicativa sicura.

La tecnologia è contesto, non verdetto.

Uno degli errori più comuni negli audit automatici è trasformare una fingerprint tecnologica in una valutazione del rischio senza avere abbastanza informazioni per farlo.

Il dato forse più interessante: i grandi siti possono falsare la percezione

Durante lo sviluppo dello studio è stato effettuato anche un controllo su un piccolo insieme di domini molto conosciuti.

Il risultato è significativo: in quel gruppo HSTS risultava presente nel 52,7% dei siti, contro il 31,5% del campione casuale utilizzato come confronto; CSP nel 31,9%, contro il 17,6%.

Non è il dataset principale della ricerca e non va utilizzato per costruire una classifica tra "grandi" e "piccoli" siti.

Dimostra però qualcosa di metodologicamente importante.

Se per valutare lo stato del web italiano osservassimo soltanto banche, grandi giornali, multinazionali, università e piattaforme molto note, otterremmo probabilmente un'immagine più sicura della realtà quotidiana del web.

Le organizzazioni con team IT strutturati hanno più risorse per gestire configurazioni, aggiornamenti, CDN, WAF e policy di sicurezza.

Il lungo elenco di siti meno conosciuti è invece quello che rende una misurazione su larga scala particolarmente interessante.

Sicurezza e SEO: meglio non inventare correlazioni

Per chi lavora nella SEO tecnica viene spontanea una domanda: implementare CSP, HSTS, Permissions-Policy o DMARC migliora il ranking?

Non abbiamo dati per sostenerlo, e sarebbe scorretto presentare questi header come fattori SEO diretti.

La sicurezza tecnica ha però effetti che vanno ben oltre il ranking.

Un sito compromesso può distribuire malware, subire defacement, perdere disponibilità, esporre dati, generare spam o finire nelle blacklist dei browser e dei motori di ricerca. In quei casi il problema SEO arriva rapidamente, ma è la conseguenza di un problema di sicurezza molto più serio.

La relazione corretta è quindi meno spettacolare ma più importante:

SEO, performance e sicurezza fanno parte della stessa qualità tecnica del sito, ma non sono la stessa cosa.

Ottimizzare una pagina per Google lasciando trascurata la sua infrastruttura significa lavorare su una sola parte del problema.

HTTPS è il punto di partenza, non quello di arrivo

Lo studio IWSS restituisce un web italiano caratterizzato da un forte contrasto.

Da una parte TLS: moderno, ampiamente aggiornato e con TLS 1.3 già dominante.

Dall'altra, configurazioni applicative e browser-side molto meno uniformi: CSP presente in meno di un sito su cinque, HSTS in circa un terzo, Permissions-Policy poco sopra l'11%, attributi di sicurezza dei cookie spesso mancanti e autenticazione email ancora incompleta.

Non significa che "il web italiano sia insicuro".

Uno studio passivo non può stabilire quanti siti siano realmente vulnerabili o compromettibili.

Significa però che molte misure difensive disponibili da anni non sono ancora diventate uno standard operativo diffuso quanto HTTPS.

Ed è forse questo il risultato più utile della ricerca.

La prossima volta che un audit restituisce un lucchetto verde e un certificato valido, la domanda non dovrebbe essere soltanto "il sito usa HTTPS?".

Dovrebbe essere:

cos'altro abbiamo configurato dopo HTTPS?

Lo studio completo, con grafici interattivi e risultati dettagliati, è disponibile nell'Italian Web Security Study pubblicato da f-hack.

Il paper Measuring the Security Configuration of the Italian Web: A Large-Scale Passive Measurement Study è inoltre disponibile su Zenodo con DOI 10.5281/zenodo.21322437: consulta la pubblicazione su Zenodo.

Vuoi controllare la configurazione del tuo sito?

PerSeo Insights integra nell'audit tecnico anche controlli di sicurezza passiva, insieme ad analisi SEO, performance e altri segnali tecnici del dominio.

Un audit automatico non sostituisce un penetration test o un vulnerability assessment, ma può essere un ottimo primo passo per individuare configurazioni mancanti e aspetti da approfondire.