Nessun header di sicurezza HTTP supera il 42% di adozione. Meno dell'1% delle policy CSP effettivamente presenti sui siti italiani è configurato in modo restrittivo. Il file security.txt, che permette di segnalare una vulnerabilità in modo responsabile, esiste su appena il 2,4% dei domini.

Sono alcuni dei primi risultati di IWSS - Italian Web Security Study, la ricerca che F-Hack sta portando avanti da luglio 2026 con l'obiettivo di misurare, con metodo scientifico e dati citabili, la configurazione di sicurezza del web italiano su larga scala.

Cosa abbiamo misurato

10.022 domini .it, l'intero pool disponibile dalla lista Tranco top-1M (data lista: 2026-07-08), analizzati con una metodologia puramente passiva: nessun exploit, nessun brute force, nessuna scansione attiva. Solo le stesse richieste HTTP, TLS e DNS che invierebbe qualunque browser nel caricare una homepage pubblica.

Il campionamento è casuale, non un elenco dei siti più noti: un controllo diretto contro un set disposable di 105 domini "famosi" (91 raggiungibili, stessa dinamica campionati/riusciti vista in tutto lo studio) ha confermato che i siti conosciuti hanno una configurazione di sicurezza sistematicamente migliore (HSTS al 52,7% contro il 31,5% del campione casuale di controllo, CSP al 31,9% contro il 17,6%). Usare un campione casuale, invece di un elenco a mano, è quindi la scelta metodologicamente corretta per un dato che vuole essere rappresentativo, non ottimistico.

Su 10.020 scansioni completate, l'88,1% dei domini (8.829, IC 95% [87,5%-88,7%]) risponde a una normale richiesta HTTP.

Gli header di sicurezza restano l'eccezione

Sugli 8.829 siti raggiungibili, nessun header HTTP di sicurezza supera il 42% di adozione:

Header Adozione Intervallo di confidenza 95%
X-Frame-Options 41,8% [40,8%, 42,9%]
X-Content-Type-Options 37,6% [36,6%, 38,6%]
HSTS 32,8% [31,8%, 33,8%]
Referrer-Policy 29,0% [28,0%, 30,0%]
Content-Security-Policy 18,7% [17,9%, 19,5%]
Permissions-Policy 11,2% [10,6%, 11,9%]

In altre parole: la maggioranza dei siti italiani nel campione non dichiara nessuna delle protezioni HTTP di base.

Le CSP che ci sono, spesso non proteggono davvero

Delle 1.646 policy CSP analizzate a livello di direttiva, solo lo 0,7% (11 su 1.646, IC 95% [0,4%-1,2%]) rispetta un criterio di restrittività definito in modo esplicito e verificabile: presenza di default-src o script-src, nessun unsafe-inline, nessun unsafe-eval, nessuna sorgente jolly.

Il 45,4% delle policy usa unsafe-inline, una direttiva che vanifica gran parte della protezione contro il cross-site scripting che la CSP dovrebbe garantire. L'11,1% usa una sorgente wildcard.

Questo dato non va letto come "solo l'1% dei siti ha una CSP sicura": è attribuito a una definizione precisa e falsificabile, non a un giudizio generico sulla sicurezza dei siti coinvolti.

Su 7.240 cookie osservati:

  • manca l'attributo SameSite nel 51,8% dei casi
  • manca HttpOnly nel 51,8% dei casi
  • manca Secure nel 47,5% dei casi

Non esiste ancora una classificazione per tipo di cookie (sessione/autenticazione vs. analytics/tracking): un cookie di sessione senza Secure e un cookie _ga senza Secure non sono lo stesso problema, quindi questi numeri descrivono attributi osservati sui cookie nel loro complesso, non specificamente un rischio sull'autenticazione.

La buona notizia: TLS

Non tutto è negativo. Su 8.864 handshake TLS completati, zero cifrature deboli rilevate (RC4/DES/MD5/EXPORT) e l'87,3% dei siti negozia già TLS 1.3 come standard di fatto, contro il 12,7% ancora su TLS 1.2.

Email spoofing: un dominio su due resta esposto

Su un sottoinsieme esteso di 9.520 scansioni:

Meccanismo Adozione
SPF 55,5% [54,5%, 56,5%]
DMARC 43,8% [42,9%, 44,8%]
DKIM 36,6% [35,6%, 37,6%]
security.txt (RFC 9116) 2,4% [2,1%, 2,7%]

SPF, DMARC e DKIM riguardano la resistenza allo spoofing email del dominio, una configurazione distinta da quella del sito web vero e proprio, ma altrettanto rilevante per chi valuta il rischio complessivo di un'organizzazione.

Cosa gira dietro i siti .it

Cloudflare guida la classifica delle tecnologie rilevate (3.053 siti), seguito da WordPress (2.487), Nginx (1.777) e Apache (1.509). Questi dati sono raccolti come variabile di contesto, utile per spiegare differenze di configurazione tra tecnologie diverse, non come indicatore di sicurezza in sé.

Metodologia e trasparenza

Ogni richiesta è una GET HTTP standard, non autenticata, con uno User-Agent identificabile e un contatto. Nessun payload, nessun fuzzing, nessuna sonda di vulnerabilità: il codice per scansioni attive non è mai stato integrato in questa pipeline, per scelta strutturale, non per una configurazione disattivabile. Non viene salvato alcun corpo di risposta HTTP, solo hash SHA-256 e metadati.

I domini pubblicati nel dataset sono pseudonimizzati, non anonimizzati in senso stretto: ogni dominio è sostituito da uno SHA-256 senza salt. Poiché i nomi a dominio .it sono informazione pubblica, non si tratta di un'esposizione grave, ma l'hash è invertibile con un attacco a dizionario contro i domini .it noti, e questo viene dichiarato esplicitamente nel dataset e nel paper.

Dataset e codice pubblici

L'intera pipeline di misurazione (crawler, analyzer, modulo statistico) e un export pseudonimizzato del dataset sono pubblicati su GitHub, con licenza MIT per il codice e CC-BY 4.0 per il dataset, così che chiunque possa riprodurre in autonomia ogni numero riportato in questo articolo.

Repository: github.com/giovannimanetti11/italian-web-security-study
Infografica interattiva completa (IT/EN): f-hack.com/analisi-sicurezza-web-italiano-2026
Paper (v1.0, PDF): 10.5281/zenodo.21322437

Prossimi passi

Questi sono risultati preliminari, non ancora sottoposti a peer review. Il prossimo passo è estendere il campione oltre i 10.022 domini attualmente disponibili da Tranco, e impostare una ricerca longitudinale per misurare come cambia la configurazione di sicurezza del web italiano nel tempo, sfruttando uno schema dati versionato pensato fin dall'inizio per questo scopo.

Chi utilizza questo dataset o questa metodologia nel proprio lavoro è invitato a citare sia il repository sia il paper accompagnatorio (DOI: 10.5281/zenodo.21322437). Il DOI del solo dataset sarà disponibile a breve.