Cos'è Subresource Integrity (SRI)? Guida per siti WordPress

Subresource Integrity (SRI) è uno standard di sicurezza del W3C che ti permette di specificare un hash crittografico sui tag <script> e <link> in modo che il browser possa verificare che il file caricato corrisponda a ciò che ti aspetti. Se il file all'URL è stato modificato, intercettato o sostituito (sia da un attaccante, un CDN compromesso, o anche un aggiornamento accidentale), il browser blocca interamente l'esecuzione. SRI è stato standardizzato nel 2016 ed è supportato da ogni browser principale. È una delle mitigazioni più economiche contro gli attacchi alla supply chain su JavaScript di terze parti, che è la fonte dominante di incidenti di breach sui siti WordPress nel 2026.

Come si presenta un hash SRI, e come lo aggiungo?

Un tag script con SRI abilitato ha due attributi extra: integrity e crossorigin:

<script
  src="https://cdn.example.com/jquery-3.7.1.min.js"
  integrity="sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs"
  crossorigin="anonymous">
</script>

Il valore integrity è un hash crittografico codificato in base64 del contenuto del file, prefissato con l'algoritmo usato (sha256-, sha384- o sha512-). SHA-384 è la scelta raccomandata nel 2026: un buon equilibrio tra sicurezza e lunghezza dell'hash. SHA-512 è anche accettabile. SHA-256 funziona ancora ma è considerato il più debole dei tre; va bene per asset non critici ma non per nulla di sensibile dal punto di vista della sicurezza.

Quando il browser carica il file, calcola il suo hash e lo confronta con il valore integrity. Se gli hash coincidono, lo script viene eseguito. Se differiscono anche di un solo byte, il browser rifiuta di eseguirlo e registra un errore nella console.

Quali attacchi previene Subresource Integrity?

SRI protegge specificamente dal caso in cui un file di terze parti venga modificato tra il momento in cui hai deciso di fidarti e il momento in cui il browser di un utente lo carica effettivamente. I tre scenari più rilevanti per i siti WordPress:

• Compromissione del CDN. Se un attaccante penetra in un CDN (o nel servizio di terze parti il cui CDN usi) e modifica un file JavaScript, ogni sito che incorpora quel file tramite <script src> eseguirebbe improvvisamente il codice dell'attaccante. SRI lo cattura immediatamente: il file modificato non corrisponde all'hash, il browser lo blocca.
• Compromissione dell'account presso il provider di terze parti. Qualcuno compromette un account di analytics, widget di chat o hosting di font e pubblica un aggiornamento dannoso allo script che hai incorporato. Senza SRI, il tuo sito esegue l'aggiornamento dannoso ad ogni caricamento di pagina. Con SRI, lo script fallisce silenziosamente finché non aggiorni l'hash, il che significa finché non hai personalmente rivisitato la nuova versione.
• Manomissione a livello di rete. Un attaccante man-in-the-middle su una rete aziendale o WiFi ostile riscrive un file JavaScript mentre transita verso l'utente. HTTPS previene questo per connessioni dirette al tuo origin, ma uno script di terze parti servito da un tentativo di avvelenamento DNS controllato dall'attaccante potrebbe aggirare questo. SRI fornisce un controllo di integrità end-to-end indipendente da TLS.

Il breach di British Airways del 2018 in cui 380.000 clienti hanno avuto i loro dati di pagamento rubati è avvenuto perché l'attaccante ha modificato uno script Modernizr di terze parti che BA caricava sulla loro pagina di checkout. SRI su quel tag script avrebbe fermato l'attacco nel momento in cui il file modificato è stato caricato. Incidenti simili continuano ad accadere, con attacchi in stile Magecart sui siti e-commerce come la categoria più documentata.

A quali file dovrei aggiungere SRI?

SRI è per file di terze parti caricati tramite rete. Tre categorie contano, in ordine di priorità:

• Flussi di pagamento, checkout e login. Qualsiasi JavaScript che gira su una pagina dove gli utenti inseriscono carte di credito, password o altri dati sensibili è il bersaglio a più alta priorità. Uno script compromesso su una pagina di checkout è lo scenario peggiore. Se il tuo checkout WooCommerce carica qualsiasi cosa da un CDN, ognuno di quegli script dovrebbe avere SRI.
• Script incorporati globalmente. Qualsiasi cosa in <head> o vicino alla cima di <body> che gira su ogni pagina: tag di analytics, font, polyfill, jQuery da un CDN pubblico. Questi vengono eseguiti prima che l'utente abbia la possibilità di notare qualcosa di sbagliato.
• Script CDN iniettati da plugin. Molti plugin WordPress (widget di chat, A/B testing, pixel di marketing) caricano JavaScript remoto. Questi sono scritti da terze parti di cui ti sei fidato implicitamente, e tipicamente non includono SRI di default.

Inversamente, non aggiungere SRI a file serviti dal tuo dominio. Se un attaccante ha accesso per modificare file sul tuo server di origine, può anche modificare l'HTML che dichiara l'hash, quindi SRI non fornisce protezione reale. SRI brilla solo per risorse cross-origin.

Come genero un hash SRI per uno script di terze parti?

Tre metodi pratici:

1. Usa srihash.org. Strumento basato su web. Incolla l'URL dello script, ricevi indietro il tag <script> completo con attributi integrity e crossorigin. Percorso più veloce per aggiunte puntuali.
2. OpenSSL da riga di comando. curl -s https://cdn.example.com/file.js | openssl dgst -sha384 -binary | openssl base64 -A emette l'hash base64 che premetti con sha384-. Utile quando si fanno script o si lavora con file localmente prima del deployment.
3. Controlla la documentazione del provider. I principali CDN (cdnjs.com, jsDelivr) pubblicano l'hash SRI accanto ad ogni versione di ogni libreria che ospitano. Bootstrap, jQuery, Vue, React, ecc. pubblicano tutti il valore integrity raccomandato sulle loro pagine ufficiali di getting-started. Copia-incolla da lì.

Un avvertimento: l'hash è legato al contenuto esatto in byte del file. Se il CDN serve una versione diversa (perché hai usato un URL come jquery@3 invece di jquery@3.7.1), l'hash non corrisponderà e lo script si bloccherà. Pinna sempre a versioni specifiche quando usi SRI.

Perché l'attributo crossorigin="anonymous" è richiesto?

L'attributo crossorigin="anonymous" dice al browser di recuperare il file di terze parti usando CORS, senza inviare cookie o autenticazione. Senza di esso, il browser non può leggere il corpo di risposta del file per calcolare il suo hash (una particolarità della politica same-origin), e la verifica SRI fallisce silenziosamente aperta: lo script viene eseguito senza essere controllato.

Questo è l'errore SRI più comune. Le persone aggiungono integrity ma dimenticano crossorigin, e poi assumono che la loro configurazione funzioni perché lo script continua a caricare. Senza entrambi gli attributi, non hai alcuna protezione reale. Per verificare: apri DevTools, tab Network, clicca sullo script, guarda la risposta. Se il CDN supporta CORS (essenzialmente tutti i CDN pubblici moderni lo fanno), vedrai Access-Control-Allow-Origin: * negli header di risposta. Senza quell'header, SRI non può funzionare su quella risorsa.

Come aggiungo SRI a WordPress?

Tre scenari a seconda di come gli script entrano nelle tue pagine:

Scenario 1: script enqueued da WordPress (tema o plugin)

Il core di WordPress supporta SRI tramite il filtro script_loader_tag. Aggiungi al functions.php del tuo child theme o a un piccolo mu-plugin:

add_filter('script_loader_tag', function ($tag, $handle, $src) {
    $sri_hashes = [
        'jquery'    => 'sha384-1H217gwSVyLSIfaLxHbE7dRb3v4mYCKbpQvzx0cegeju1MVsGrX5xXxAvs/HgeFs',
        'bootstrap' => 'sha384-...il-tuo-hash-qui...',
    ];

    if (isset($sri_hashes[$handle]) && strpos($src, '://') !== false && strpos($src, home_url()) === false) {
        $tag = str_replace(
            ' src=',
            ' integrity="' . $sri_hashes[$handle] . '" crossorigin="anonymous" src=',
            $tag
        );
    }
    return $tag;
}, 10, 3);

Aggiusta i nomi handle e gli hash per corrispondere ai tuoi script. I controlli strpos assicurano che SRI venga applicato solo agli script caricati da domini esterni, non ai tuoi.

Scenario 2: script hardcoded nei template del tema

Se un tema emette direttamente tag <script src="https://..."> in header.php o altrove, modifica quei tag direttamente per aggiungere gli attributi integrity e crossorigin. Rispecchia questo nel tuo child theme per sopravvivere agli aggiornamenti del tema parent.

Scenario 3: script iniettati da JavaScript o plugin di terze parti a runtime

Widget di chat, strumenti di A/B testing e tag manager spesso iniettano tag script dinamicamente. SRI funziona ancora in questo caso: l'elemento <script> creato dinamicamente deve impostare le proprietà integrity e crossOrigin prima che lo script venga appeso al DOM. La maggior parte delle versioni enterprise di questi strumenti supportano questo tramite configurazione; i tier gratuiti tipicamente no. Per iniezioni di terze parti non gestite, il fallback pratico è una Content Security Policy con require-sri-for script (ancora in bozza) o semplicemente un audit accurato.

Qual è il carico di manutenzione di SRI?

Questo è il trade-off onesto. SRI è un compromesso tra sicurezza e convenienza. Ogni volta che la libreria upstream si aggiorna, l'hash cambia, il tuo script si rompe, e devi aggiornare l'hash. Per un sito stabile che pinna le versioni e le aggiorna raramente, questo è un compito trimestrale. Per un sito che usa jquery@latest o si affida a CDN con auto-aggiornamento, SRI è una fonte costante di rotture.

Tre pattern che rendono gestibile la manutenzione SRI:

• Pinna a versioni specifiche, non "latest". URL come https://cdn.jsdelivr.net/npm/jquery@3.7.1/dist/jquery.min.js, non jquery@latest. L'hash è quindi stabile finché non aggiorni deliberatamente.
• Usa un CDN che pubblica hash. cdnjs e jsDelivr pubblicano entrambi l'hash SRI per ogni file. Aggiornare l'hash quando aggiorni è un compito di 30 secondi.
• Self-hosta le librerie critiche. Una volta che self-hosti (cosa che dovresti considerare per ragioni GDPR comunque, vedi la discussione su Google Fonts), SRI diventa irrilevante per quello script. SRI è per casi in cui non puoi self-hostare. Per analytics, font, librerie usate su una pagina, il self-hosting è spesso la risposta migliore.

Errori comuni

• Dimenticare crossorigin="anonymous". Lo script continua a caricare ma non è più verificato per l'integrità. Il fallimento SRI silenzioso più comune.
• Usare SRI su risorse same-origin. Un attaccante che può modificare il tuo /wp-includes/js/jquery.js può anche modificare l'HTML che dichiara l'hash. Usa SRI solo su risorse cross-origin.
• Calcolare l'hash sulla versione sbagliata del file. L'hash deve corrispondere ai byte esatti che il browser riceverà, inclusa qualsiasi minificazione o trasformazione lato CDN. Recupera sempre dall'URL di produzione reale quando calcoli.
• Non aggiornare l'hash all'upgrade della libreria. Aggiorni la versione della libreria nell'URL, dimentichi di aggiornare integrity, lo script smette silenziosamente di funzionare. Sintomi: una funzionalità si rompe, la console mostra "Failed to find a valid digest in the integrity attribute".
• Usare SHA-1. SHA-1 è vulnerabile alle collisioni ed è stato deprecato per SRI. Usa SHA-384 o SHA-512.
• Provare a usare SRI su un CDN senza CORS. Il browser non può calcolare l'hash, quindi SRI è impossibile. O il CDN deve abilitare CORS, o devi self-hostare il file.

SRI e Content Security Policy (CSP)

SRI e CSP sono complementari, non ridondanti. CSP dice "solo gli script da questa lista di origini sono autorizzati a girare". SRI dice "e quello script deve corrispondere a questo hash esatto". Insieme formano un approccio defense-in-depth: CSP blocca origini sconosciute; SRI blocca la manomissione di origini conosciute. Un CSP con script-src 'self' https://trusted-cdn.com dice "ci fidiamo di trusted-cdn.com"; aggiungere hash SRI ai tuoi script su trusted-cdn.com restringe quella fiducia a versioni di file specifiche.

La direttiva CSP in bozza require-sri-for script imporrebbe che ogni script cross-origin debba avere un attributo integrity, a livello browser. Nel 2026 ha supporto limitato ma è la direzione in cui lo standard si sta muovendo.

Cosa controlla InspectWP

La sezione Sicurezza di ogni report InspectWP ispeziona i tag script e stylesheet esterni e riporta quali includono attributi integrity e quali no. SRI mancante su uno script da un CDN di terze parti viene segnalato come rilievo di severità da bassa a media, a seconda del contesto. Una pagina di login o checkout che carica JavaScript esterno senza SRI è un avvertimento di priorità più alta. Il report segnala anche valori integrity malformati (prefisso algoritmo sbagliato, base64 non valido) che possono dare una falsa sensazione di protezione mentre sono in realtà ignorati dal browser. SRI è una di quelle misure dove l'esistenza dell'attributo conta meno della sua correttezza; un hash sbagliato è funzionalmente equivalente a nessun hash perché il browser rifiuta comunque le non corrispondenze, ma un attributo crossorigin mancante rende l'intero controllo silenzioso.