HTTPS dice con quale server parli. Non dice se il file del CDN è ancora quello. SRI è l'hash sull'elemento. Senza crossorigin, la richiesta cross-origin fallisce.
HTTPS dice con quale server stai parlando. Non dice se il file che il CDN ti spedisce è ancora quello che hai messo in pagina sei mesi fa. Subresource Integrity è l’hash di quel file, sull’elemento. Se il contenuto non combacia, il browser non lo esegue. Un plugin «CDN sicuro» non calcola SHA-384.
In breve: integrity su script e su link (stylesheet, preload, modulepreload). Prefissi sha256, sha384, sha512. Cross-origin: CORS più crossorigin="anonymous", altrimenti la richiesta fallisce. TLS autentica il server, non il bit. Verifica del 19 settembre 2026 su MDN e sulla specifica W3C SRI.
Cosa trovi in questo articolo
Cosa è SRI (e cosa non è il lucchetto)
MDN, nella guida Subresource Integrity, parte da un caso banale: la pagina del tuo origin include uno script da un host terzo. Se qualcuno prende il controllo di quell’host — o sostituisce il file sul CDN — inietta quello che vuole. Si chiama attacco alla supply chain. SRI è la difesa: il browser verifica che i byte scaricati siano esattamente quelli che ti aspetti.
La specifica W3C Subresource Integrity lo mette in fila con TLS, HSTS e i pin delle chiavi: quei meccanismi autenticano il server. Un amministratore, o un attaccante, con accesso a quel server manipola il contenuto comunque. SRI pinta il contenuto. L’esempio della specifica è un framework su un origin condiviso, con SHA-384 nell’attributo integrity e crossorigin="anonymous".
Questo pezzo sta nel cluster Sicurezza, accanto a HSTS, alla CSP, al mixed content e alla checklist TLS. TLS cifra il transito. HSTS impedisce di tornare in HTTP sul nome. Mixed content è la pagina HTTPS che pesca HTTP. SRI è il quarto mestiere: il file arriva in HTTPS, da un host che conosci, e non è più lo stesso file.
integrity, hash, quale vince
MDN: l’attributo si mette sull’elemento script e sull’elemento link con rel stylesheet, preload o modulepreload. Il valore è una lista separata da spazi. Ogni pezzo: algoritmo, trattino, hash in base64. Algoritmi ammessi: sha256, sha384, sha512.
| Cosa fa il browser | |
|---|---|
| Più algoritmi insieme | tiene solo il più forte presente (SHA-512 > SHA-384 > SHA-256) e ignora gli altri |
| Più hash dello stesso algoritmo | basta che uno combaci: serve a dichiarare versioni alternative dello stesso recapito |
| Nessun match | rifiuta la risorsa, network error. Lo script non parte. Il CSS non si applica |
MDN indica anche OpenSSL: digest SHA-384 in binario, poi encoding base64, prefisso sha384-. C’è un generatore online, SRI Hash Generator, sullo stesso articolo MDN. Si calcola sull’esatto file che il CDN servirà, non su una minificazione locale che poi il pipeline rinomina. Se il vendor pubblica un nuovo jQuery e l’URL resta uguale, l’hash in pagina è un 404 funzionale: è il comportamento giusto. Si aggiorna l’attributo insieme al file. Non si toglie l’attributo «per far tornare il menù».
Senza CORS l’hash non parte
MDN è netto: le richieste cross-origin con SRI devono usare CORS. Il server della risorsa deve spedire l’header CORS di origine consentita (spesso il jolly, sui CDN). Di default uno script terzo si carica in no-cors: la pagina lo usa, ma non può leggerlo. SRI, da solo, permetterebbe a un attaccante di indovinare il contenuto dal successo o dal fallimento del load. Per chiudere quella via, i browser rifiutano SRI in no-cors. Senza l’attributo crossorigin, la richiesta con integrity fallisce sempre.
In markup: sull’elemento script, oltre a src e integrity, va crossorigin="anonymous". anonymous (o l’attributo vuoto) è CORS senza credenziali. use-credentials le include. Sull’attributo crossorigin MDN lo elenca. Un CDN che non spedisce CORS, con SRI in pagina, non «si vede lo stesso»: sparisce. In console resta l’errore. In pagina resta un buco. È lo stesso genere di buco del mixed content blockable, con un’altra causa.
Sull’origin proprio, lo script first-party non ha bisogno di quel giro. SRI resta utile lo stesso: un deploy che sovrascrive il bundle applicativo con un file diverso, a URL invariato, viene bloccato finché non si aggiorna l’hash. È un vincolo di rilascio, non un orpello.
Integrity-Policy: obbligare l’attributo
L’header HTTP Integrity-Policy, scrive MDN, fa sì che il browser blocchi le richieste di certe destinazioni senza metadati di integrità, e blocchi anche le no-cors. Non è Baseline: il supporto non è universale. La coppia report-only esiste, Integrity-Policy-Report-Only, per vedere le violazioni prima di spegnere gli script in produzione.
| Chiave | Cosa ammette MDN |
|---|---|
blocked-destinations | script, style |
sources | opzionale; oggi solo inline (l’attributo in pagina). È il default |
endpoints | nomi di endpoint definiti in Reporting-Endpoints |
Esempio da MDN: si dichiara un endpoint di report, poi Integrity-Policy con blocked-destinations su script e gli endpoint collegati.
Il report, tipo integrity-violation, porta documentURL, blockedURL, destination, reportOnly. Non sostituisce una CSP. Non sostituisce HSTS. Non mette HttpOnly sul cookie di sessione. Quattro header, quattro mestieri. Il plugin che promette tutti e quattro è un quinto script, e quello, se arriva da un CDN, vorrebbe un hash.
Errori da evitare
Mettere
integritysu uno script terzo senzacrossorigin="anonymous": la richiesta fallisce sempre.Calcolare l’hash sul file locale e servire dal CDN la versione minificata, un byte diversa.
Credere che HTTPS sul CDN basti: TLS autentica l’host, non il contenuto. Lo scrive la specifica.
Togliere SRI quando un vendor aggiorna il file allo stesso URL, invece di aggiornare l’hash.
Confondere SRI con mixed content: uno è HTTP su HTTPS, l’altro è HTTPS col file sbagliato.
Attivare
Integrity-Policyin blocking senza un giro in report-only: MDN lo marca limited availability.Mettere SRI sui plugin e lasciare
unsafe-inlineovunque nella CSP: due leve, due buchi.
In sintesi
SRI è l’hash del file, in pagina. Script e stylesheet. SHA-384 o SHA-512, CORS e crossorigin se l’host è terzo. TLS e HSTS non lo calcolano. Integrity-Policy può obbligare l’attributo; oggi non è Baseline. Si aggiorna l’hash quando si aggiorna il file, non si spegne la verifica.
Fonti
MDN, Subresource Integrity (consultata il 19 settembre 2026): elementi, algoritmi, scelta del hash più forte, CORS, no-cors, Integrity-Policy, OpenSSL.
MDN, attributo
integrity: script e link, SHA-256/384/512, rifiuto se non combacia.MDN,
Integrity-Policy(pagina modificata il 22 marzo 2026): blocked-destinations, report-only, limited availability.W3C WebAppSec, Subresource Integrity: TLS/HSTS autenticano il server, non il contenuto; esempio con SHA-384 e
crossorigin.
Immagine di copertina: tastiera retroilluminata. L’SRI si calcola sui byte del file, non sul lucchetto dell’host. Foto di Gre123gr, Wikimedia Commons, licenza CC0.
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
