CDN Scaduti, Siti in Ostaggio: la supply chain invisibile che trasforma uno script “fidato” in attacco client-side

Nel mondo della web security esiste un rischio spesso sottovalutato che nasce da una semplice dimenticanza: un dominio CDN dismesso scade, viene ri-registrato da terzi e migliaia di siti continuano a richiamarlo tramite riferimenti hard coded in pagine, documentazione e repository. Chi controlla quel dominio può impostare wildcard DNS e far risolvere qualsiasi hostname sotto di esso verso infrastrutture proprie.

Il risultato è una supply chain invisibile lato browser, in cui la decisione su cosa viene caricato nelle pagine non appartiene più al proprietario del sito ma a un soggetto esterno, senza che nulla sembri rotto o anomalo.

Questo schema ricorda casi noti in cui un dominio molto diffuso per script JavaScript ha cambiato proprietà e ha iniziato a servire contenuti diversi in modo selettivo. La lezione è chiara: anche se il tuo server non è stato compromesso, un tag script esterno inserito anni prima può trasformarsi in un vettore di attacco oggi.

Strumenti tradizionali come static analysis, dependency scanning e software composition analysis guardano ciò che l’organizzazione costruisce e distribuisce, ma non vedono ciò che il browser scarica in tempo reale da terze parti. Inoltre, la risposta di uno script remoto può variare per geografia, user agent, referrer, orario e sessione, rendendo inefficaci molti controlli basati su crawler o test singoli.

Uno script di terze parti ha privilegi equivalenti al codice first party: può leggere il DOM, intercettare campi modulo carattere per carattere, accedere a cookie e local storage ed eseguire richieste verso destinazioni esterne. Attacchi client side in stile Magecart non richiedono una violazione del server: basta che uno script autorizzato inizi a comportarsi in modo diverso.

Il punto di osservazione più affidabile è il browser stesso. La Content Security Policy non serve solo contro XSS, ma anche per sapere quali risorse vengono eseguite e per ricevere segnalazioni quando qualcosa esce dalla policy. Con la modalità report-only la CSP non blocca nulla e non rompe il sito, ma produce dati utili per costruire un inventario reale degli script e monitorare variazioni nel tempo.

Questo approccio è diventato anche un tema di compliance per chi gestisce pagamenti online, con requisiti che impongono autorizzazione, inventario, giustificazione e rilevamento di modifiche non autorizzate su pagine di pagamento e header HTTP.