Verificatore di SRI

Come funziona questo controllo

Scanaris scorre l'HTML della tua pagina principale e si concentra su due tipi di tag: <script src="..."> e <link rel="stylesheet" href="...">. Risolve ogni URL rispetto a quello della pagina e lo considera esterno se la sua origine (schema, dominio e porta) è diversa dalla tua; questo include gli URL che iniziano con //, che caricano dalla CDN con il protocollo della pagina. Scarta data: e blob:. Per ogni risorsa esterna verifica se ha l'attributo integrity; se manca, la annota. Se ce n'è almeno una, apre un rilievo di gravità bassa con il numero di risorse e i primi dieci URL. Gli script e gli stili del tuo stesso dominio non vengono segnalati: lì il SRI non aggiunge nulla.

Perché è importante

Quando carichi una libreria da una CDN stai eseguendo nel browser dei tuoi utenti ciò che quella CDN decide di servire. Se la CDN viene compromessa, o se il suo dominio cambia proprietario, il file può essere sostituito con un altro che fa la stessa cosa e in più ruba i moduli o reindirizza a truffe. È successo nel giugno 2024 con polyfill.io: il dominio è stato venduto, lo script ha iniziato a iniettare codice malevolo e più di centomila siti che lo includevano l'hanno servito senza accorgersene. L'attributo integrity contiene l'hash del file che tu hai controllato; il browser calcola l'hash di ciò che scarica e, se non coincide, non lo esegue. È gravità bassa perché richiede che la CDN venga attaccata prima, ma quando succede il danno è totale e silenzioso.

Come risolvere

Opzione 1: aggiungere integrity ai tag

<script src="https://cdn.jsdelivr.net/npm/chart.js@4.4.0/dist/chart.umd.min.js"
  integrity="sha384-..." crossorigin="anonymous"></script>

L'hash si ottiene scaricando il file esatto ed eseguendo:

curl -s https://cdn.jsdelivr.net/npm/chart.js@4.4.0/dist/chart.umd.min.js | openssl dgst -sha384 -binary | openssl base64 -A

cdnjs e jsDelivr mostrano l'hash pronto da copiare accanto a ogni file. L'attributo crossorigin="anonymous" è obbligatorio perché il browser possa verificare una risorsa di un'altra origine. E l'URL deve puntare a una versione fissa (@4.4.0), mai a latest: se la CDN aggiorna il file, l'hash smette di coincidere e il tuo sito smette di caricare quella libreria, che è esattamente ciò che vuoi davanti a un cambiamento non revisionato.

Opzione 2: servire le librerie dal tuo dominio

Installale con npm e lascia che il tuo bundler (Vite, webpack, Nuxt, Next.js) le includa nel tuo build. Così il file esce dal tuo server, con hash nel nome, e il SRI non è più necessario. È l'opzione abituale nei progetti moderni e quella che risolve il rilievo alla radice.

Ciò che non ammette SRI

I fogli di stile di Google Fonts cambiano a seconda del browser che li richiede, quindi il loro hash non è stabile: o accetti quel rilievo o ospiti i font tu stesso (il che migliora anche privacy e velocità). Gli script di analitica e pubblicità che si aggiornano da soli (gtag.js, il pixel di Meta) non ammettono nemmeno loro un hash fisso; lì la difesa è la CSP, che limita cosa può fare ogni origine e che misura CSP debole.

Verifica che sia risolto

curl -s https://tuodominio.it | grep -oE '<(script|link)[^>]*(src|href)="(https?:)?//[^"]+"[^>]*>' | grep -v integrity

Ogni riga che esce è una risorsa esterna senza integrity. Se restano solo quelle che non lo ammettono (font, analitica), hai finito.

Domande frequenti

Il SRI rallenta il caricamento?

Non in modo apprezzabile: calcolare un hash SHA-384 di un file di qualche centinaio di kilobyte richiede millisecondi. Quello che fa è obbligarti a fissare le versioni, che è buona pratica comunque.

Se aggiorno la libreria, devo cambiare l'hash?

Sì, ed è il punto: l'aggiornamento passa dalle tue mani. Se usi npm e il tuo bundler, il processo è lo stesso di sempre e l'hash lo gestisce il build.

E le vecchie versioni delle librerie sulla CDN?

Il SRI garantisce che il file sia quello che hai scelto, non che sia sicuro. Un jQuery 1.12 con l'hash corretto ha ancora le sue falle; lo rileva librerie obsolete.