SRI

SRI (Subresource Integrity) è una funzionalità HTML5 che consente di fissare l’hash SHA-256/SHA-384/SHA-512 di una risorsa esterna. Il browser calcola l’hash al momento del download e rifiuta di eseguire la risorsa se gli hash non corrispondono.

Esempio: <script src="https://cdn.example/lib.js" integrity="sha384-AbC..." crossorigin="anonymous"></script>

Cosa protegge: una compromissione del CDN. Se un attaccante prende il controllo del CDN e serve JavaScript modificato, ogni sito che include lo script tramite SRI rifiuta di eseguire la versione modificata. Senza SRI, ogni sito riceve silenziosamente il payload malevolo.

Il compromesso: fissare un hash significa che non è possibile aggiornare la risorsa senza aggiornare ogni pagina che vi fa riferimento. Per le risorse di primo livello che stai comunque costruendo, SRI è una difesa a basso costo. Per gli script CDN di terze parti (jQuery, tag analytics) è un significativo vantaggio di sicurezza a costo di una propagazione degli aggiornamenti più lenta.

SRI richiede crossorigin="anonymous" sul tag più un header CORS nella risposta del CDN — il browser deve poter leggere la risposta in modo opaco.

Incidenti reali che SRI avrebbe fermato: la famiglia di attacchi Magecart di card-skimming ha ripetutamente compromesso JavaScript di terze parti ospitato da fornitori attendibili (BrowserAloud, Inbenta, Picreel) e iniettato codice che rubava dati delle carte su migliaia di pagine di e-commerce. La violazione di Ticketmaster nel 2018 e quella di British Airways nel 2018 hanno entrambe coinvolto attaccanti che modificavano script su host inclusi dai siti tramite <script src="…">. SRI è la mitigazione specifica: se quei siti avessero fissato l’hash di integrità della versione dello script che intendevano caricare, il payload modificato avrebbe fallito il controllo e il browser avrebbe rifiutato di eseguirlo.

Come generare e ruotare gli hash SRI in modo pragmatico: per i file di tua proprietà, la pipeline di build dovrebbe emettere gli hash SRI insieme al bundle di risorse e incorporarli nell’HTML al momento del template (Next.js, Vite e Webpack supportano tutti questo con plugin). Per le librerie di terze parti, il flusso di lavoro consigliato è bloccare una versione specifica, copiare il file sul proprio CDN e fissare SRI su quello — affidarsi al CDN upstream per mantenere gli stessi byte disponibili allo stesso URL è rischioso nel corso dei mesi. L’attributo integrity accetta più hash separati da spazi, consentendo transizioni tra algoritmi di hash (distribuisci SHA-384 e SHA-512 insieme; il browser sceglie quello supportato). Correlato: CSP, SHA-256. Riferimento: W3C — Subresource Integrity.

Esempio pratico

Vuoi includere jQuery 3.7.1 da un CDN con protezione SRI. Calcola l’hash SHA-384 del file: openssl dgst -sha384 -binary jquery-3.7.1.min.js | openssl base64 -A produce qualcosa come Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc. Incorporalo: <script src="https://code.jquery.com/jquery-3.7.1.min.js" integrity="sha384-Bu3qSpvxnAdMaOTsigCcfqUyJYvP7AbsxRRpzqj7M1V2OuoP1bb98c8MQYIPHzxc" crossorigin="anonymous"></script>. Al caricamento della pagina, il browser recupera il file, calcola il suo SHA-384, lo codifica in base64 e lo confronta con l’attributo integrity. Se il CDN serve un file manomesso — anche una singola variazione di un byte — gli hash divergono, il browser blocca l’esecuzione e un SecurityError appare nei DevTools. La pagina continua a renderizzare; solo lo script con integrità fallita viene soppresso.

Quando e perché è importante

Ogni volta che il tuo sito carica JavaScript da un dominio che non controlli, stai fidandoti degli operatori di quel dominio, del loro provider CDN, del loro DNS e di ogni passaggio TLS nel mezzo. Questa fiducia è empiricamente mal riposta abbastanza spesso da fare la differenza: le compromissioni della supply chain che interessano i pacchetti npm, i plugin jQuery, i container GTM e gli script analytics hanno colpito siti importanti a un ritmo di diversi all’anno. SRI è la difesa che non richiede di fidarsi della terza parte. La strategia di distribuzione pragmatica: fissa SRI agli script di terze parti che carichi tramite URL (librerie ospitate su CDN, widget incorporati), ma non agli script che includi nel bundle e distribuisci dalla tua origine dove controlli i byte. Combina con CSP require-sri-for script (proposto ma non ancora ampiamente implementato) o script-src con hash consentiti espliciti per una difesa in profondità. Riferimento: MDN — Subresource Integrity.