Ho fatto analizzare i miei siti. Metà dei problemi non li avevo messi io.

Di Davide Gargantini · 31 ottobre 2026 · tecnico

Nella pagina Il tuo sito e Google consiglio di far analizzare il proprio sito con Webbkoll, uno strumento gratuito e open source che mostra cosa fa una pagina con i dati di chi la visita. Mi è sembrato giusto farlo prima io, sui siti che gestisco: questo, il mio sito di consulenza (davidegargantini.it), il sito che uso come banco di prova (laruotazen.it) e tre siti di clienti.

I siti dei clienti non li nomino: alcune delle cose raccontate qui sotto sono successe su di loro, e non sta a me metterle in vetrina.

Il risultato, in breve: nessun disastro, parecchie cose da sistemare, e una sorpresa. Una buona parte dei problemi non l’avevo introdotta io. L’aveva aggiunta Cloudflare, il servizio che sta davanti ai server, con impostazioni attive in partenza.

Cosa ha segnalato il test

Su questo sito, il primo giro ha dato cinque voci da guardare:

Content Security Policy: non implementata. È l’elenco, mandato dal server al browser, delle fonti da cui la pagina può caricare script, stili e immagini. Tutto il resto il browser lo blocca. È una rete di sicurezza: se un giorno qualcuno riuscisse a infilare del codice in una pagina, il browser si rifiuterebbe di eseguirlo.
Referrer parzialmente trapelati. Quando un visitatore clicca un link verso un altro sito, il browser dice al sito di destinazione da dove arriva. Usciva solo il dominio, non la pagina, ma usciva.
Subresource Integrity mancante sullo script delle statistiche. È un’impronta dello script scritta nella pagina: se il file cambia, il browser non lo esegue.
HSTS senza sottodomini, sul sito di consulenza: la regola che obbliga il browser a usare sempre https valeva per il dominio ma non per i suoi sottodomini.
Rapporti inviati a terzi: due intestazioni, NEL e Report-To, chiedevano al browser del visitatore di mandare a Cloudflare una segnalazione quando qualcosa va storto nella connessione.

Cosa dipendeva da me

La Content Security Policy. L’ho aggiunta nella forma più rigorosa: tutto vietato per impostazione, poi ogni tipo di risorsa ammesso esplicitamente, solo dal sito stesso. Per arrivarci ho dovuto spostare in un file a parte un piccolo script scritto dentro la pagina (quello che applica il tema chiaro o scuro prima che la pagina compaia), perché una politica rigorosa non ammette codice scritto direttamente nell’HTML.

Il referrer. Una riga nella configurazione del server: ora il browser lo manda solo tra pagine di questo sito. Verso l’esterno non esce più niente.

L’impronta sullo script delle statistiche. Qui c’era un problema vero da risolvere. Lo script di Umami, lo strumento di statistiche che uso, arriva da un server mio, ma cambia a ogni aggiornamento: un’impronta fissa nella pagina avrebbe bloccato le statistiche al primo aggiornamento, senza avvisare nessuno. La soluzione: a ogni pubblicazione il sito prende una copia dello script, la mette tra i suoi file e ne calcola l’impronta. Ha anche un vantaggio che non avevo messo in conto: se il server delle statistiche venisse compromesso, potrebbe al massimo ricevere visite false, non far eseguire codice nel browser di chi legge.

HSTS sul sito di consulenza. Esteso ai sottodomini, dopo aver controllato che fossero tutti in https. Il passo successivo, l’inserimento negli elenchi dei browser (preload), invece non l’ho fatto: è quasi irreversibile, e per un sito come il mio il vantaggio è piccolo.

Cosa non dipendeva da me

Cloudflare sta davanti ai server: protegge da attacchi e accelera le pagine. Per farlo vede ogni richiesta, e può modificare le risposte. Due delle sue modifiche erano attive senza che le avessi chieste.

La riscrittura degli indirizzi email. Per nascondere gli indirizzi ai programmi che li raccolgono per lo spam, Cloudflare sostituiva ogni mailto: nelle pagine con un link a un suo indirizzo interno, e aggiungeva uno script per ricomporlo nel browser. L’HTML che arrivava ai visitatori non era quello che avevo pubblicato. Su uno dei siti dei clienti aveva anche un effetto collaterale concreto: per un programma che non esegue JavaScript, come gli strumenti che controllano i link di un sito, ogni indirizzo email diventava un link rotto. Un controllo SEO ne contava uno per ogni pagina, quasi quattrocento in tutto. Si spegne con un interruttore, ed è spenta.

Le segnalazioni degli errori di rete (NEL e Report-To). Sui miei due siti è bastato spegnere l’interruttore relativo. Sui siti dei clienti no: lì le pagine sono ospitate da Cloudflare Pages, il servizio che costruisce e pubblica il sito, ed è Pages ad aggiungere le intestazioni, non la configurazione del dominio. L’interruttore non le tocca. Le toglie una regola che modifica le risposte prima che partano (una Transform Rule).

Con una trappola, in cui sono caduto: nel pannello di Cloudflare ci sono due tipi di regola uno accanto all’altro, una che agisce sulle richieste e una sulle risposte. Con il tipo sbagliato la regola risulta attiva, con la spunta verde, e non fa assolutamente niente.

Il peso reale di queste segnalazioni è piccolo: partono solo in caso di errore, e Cloudflare vede già tutto il traffico. Ma sono un invio a terzi che parte dal browser del visitatore senza che nessuno l’abbia chiesto, ed è esattamente il tipo di cosa di cui questo sito parla.

Sui siti dei clienti: le cose che si rompono in silenzio

I siti dei clienti sono costruiti in modo diverso dal mio: hanno un pannello con cui i titolari aggiornano testi e foto da soli. Portarci la stessa politica di sicurezza è stato più delicato, e ha insegnato più cose.

La politica la scrive il generatore del sito in ogni pagina, con l’impronta di ogni pezzo di codice che inserisce. Il pannello di redazione resta fuori, perché parla con servizi esterni e una politica scritta per il sito lo romperebbe. Fin qui, tutto previsto. Le sorprese sono state altre.

Un modulo di contatto che non avrebbe più inviato niente. Su un sito, lo script che manda il messaggio era scritto in un modo che il generatore non include nella politica. Con la protezione attiva il browser lo avrebbe bloccato: il modulo sarebbe comparso normalmente, ma premendo “invia” non sarebbe successo niente. Nessun confronto visivo l’avrebbe mostrato, perché la pagina era identica pixel per pixel. L’ha trovato un controllo automatico che verifica, per ogni pezzo di codice nella pagina, che la sua impronta sia nella politica.

I filtri di un catalogo, stessa storia. Su un altro sito, il filtro delle opere per categoria e disponibilità era scritto allo stesso modo. Prima di pubblicare l’ho riscritto e l’ho provato davvero, con un browser comandato a distanza: stessi risultati del sito di prima, in tutte e due le lingue.

Due minuti di statistiche perse. Un sito aveva l’indirizzo del server delle statistiche scritto in un punto diverso dagli altri. La politica non lo conosceva, e il browser ha cominciato a bloccare l’invio delle visite. Lo script si caricava, le visite no: nessun errore visibile. Me ne sono accorto controllando la pagina pubblicata subito dopo, e la correzione è arrivata due minuti dopo.

Un sito che ha smesso di pubblicare. Collaudando la nuova versione del pannello, una foto inserita in un testo ha preso un percorso che il sito non sa gestire. Il controllo dei link che gira prima di ogni pubblicazione se n’è accorto e ha fermato tutto: il sito è rimasto com’era, intatto, ma da quel momento nessuna modifica sarebbe andata online. La protezione ha funzionato come doveva; il problema è che nessuno se ne sarebbe accorto finché la titolare non avesse chiesto perché la sua modifica non compariva. Ora un piccolo passaggio prima della pubblicazione corregge quei percorsi, su tutti i siti.

La lezione comune: le cose più pericolose non sono quelle che si rompono, sono quelle che si rompono senza fare rumore. Un confronto visivo non basta. Servono controlli che guardino cosa fa la pagina, non solo come appare.

Cosa ho lasciato rosso, e perché

Un punteggio perfetto non era l’obiettivo. L’obiettivo era sapere perché ogni voce è com’è. Due restano rosse, di proposito.

HSTS senza sottodomini, sui siti dei clienti. Su uno di questi domini la webmail del fornitore di posta funziona solo in http. Estendere la regola ai sottodomini l’avrebbe resa irraggiungibile, senza nessun messaggio che colleghi la cosa al sito.
Lo script delle statistiche senza impronta, sui siti dei clienti. Sui miei siti la copia con l’impronta funziona perché li ricostruisco io quando aggiorno il server delle statistiche. Sui siti dei clienti vorrebbe dire ricostruire a ogni aggiornamento progetti che stanno nei loro account, e legare la pubblicazione del loro sito a un servizio mio che deve restare facoltativo. Il rischio che l’impronta copre, un server compromesso, è basso; il costo di gestirla no.

Fallo anche tu

Apri Webbkoll e inserisci l’indirizzo del tuo sito. Ci vuole un minuto.
Guarda prima le voci che riguardano i visitatori: cookie, richieste a terze parti, referrer. Sono quelle che toccano la privacy di chi ti legge. La pagina Il tuo sito e Google spiega da dove arrivano di solito.
Poi quelle di sicurezza: Content Security Policy, HSTS, impronte degli script. Qui non serve il punteggio pieno, serve sapere il motivo di ogni voce rossa.
Se il sito sta dietro Cloudflare, controlla due impostazioni: Email Address Obfuscation e le intestazioni NEL. Sono attive in partenza, e quasi nessuno sa di averle.
Chiedi a chi ha fatto il sito di spiegarti ogni voce rossa. Se la risposta è “è normale” senza un perché, è una buona occasione per fare altre domande.

Questo sito oggi passa tutti i controlli principali; restano grigie solo voci che Webbkoll stesso indica come facoltative. Cosa gira e dove lo trovi in Dove gira questo sito.