I Pericoli Nascosti nei CDN di Terze Parti: Cosa Abbiamo Imparato dal Caso del Domain Takeover

Ogni sito web è un mosaico di codice scritto da noi e codice di cui ci fidiamo ciecamente. Sulla sicurezza del primo spendiamo ore e ore. Sul secondo? Quasi mai ci fermiamo a controllare.

Una storia recente ha riportato tutto questo alla luce del sole, mostrando uno scenario che dovrebbe far rabbrividire qualsiasi sviluppatore.

La Storia di un Dominio che Nessuno Voleva Più

Immagina un servizio CDN amato da migliaia di siti WordPress, attivo per oltre dieci anni. Ad un certo punto chiude i battenti. L'azienda viene acquisita, le operazioni si fermano, e alla fine scade anche la registrazione del dominio.

A quel punto qualcun altro lo registra. E improvvisamente controlla ogni subdomain che ha mai servito i tuoi asset.

Non è fantascienza. È esattamente quello che è successo con netdna-ssl.com, il dominio degli asset dietro MaxCDN, il servizio su cui facevano affidamento molti clienti WP Engine per i contenuti statici. Quando MaxCDN è stata assorbita da StackPath e poi chiusa, il dominio è scaduto. Nel luglio 2025 è stato registrato di nuovo.

Il nuovo proprietario ha ottenuto il controllo completo del DNS wildcard su tutto il namespace *.wpengine.netdna-ssl.com. Ogni subdomain basato su hash che il tuo sito ancora referencing? Ora è in mano a uno sconosciuto che gestisce un sito per scaricare video da Instagram con Google AdSense.

Perché Dovrebbe Importarti

Potresti pensare: "E chi se ne frega? Nessuno usa più roba del genere. È legacy."

Ecco, qui sta l'errore.

La ricerca mostra che circa 4.000 file su GitHub contengono ancora riferimenti a questi domini abbandonati. Non parliamo di repository dimenticati: progetti attivi come Mozilla webxr-polyfill, insieme ai siti di Kong, Nextcloud, Yale Daily News e molte altre organizzazioni, continuano a scaricare asset da questi endpoint deprecati.

E non è finita. Cloudflare Radar colloca netdna-ssl.com nella top 20.000 dei domini globali. Significa che browser reali continuano a risolvere questo nome, in volumi significativi.

Non sono curiosità archeologiche. Sono dipendenze attive e funzionanti.

Il Problema della Pistola Carica

Arriviamo al punto più delicato. Al momento, quei vecchi URL degli asset sono sostanzialmente fuori uso. Il nuovo proprietario ha configurato Cloudflare con un certificato SSL standard che copre il dominio apex e alcuni subdomain di proxy, ma non il pattern wildcard per gli host legacy.

Quando un browser cerca di caricare uno script o un font da un subdomain come xyz123.wpengine.netdna-ssl.com, il handshake TLS fallisce.

Nel breve periodo, questo protegge gli utenti. Il browser blocca il contenuto invece di eseguirlo.

Ma pensa a cosa significa: l'attaccante ha già il controllo totale del DNS. Ha già l'infrastruttura per monetizzare. Ha già l'hosting pronto. L'unica cosa che separa questa situazione da una catastrofe è un singolo toggle nella configurazione di Cloudflare Advanced Certificate Manager.

In gergo tecnico si chiama "loaded gun": una vulnerabilità che al momento non è sfruttabile, ma potrebbe diventare devastante con uno sforzo minimo.

L'Abbiamo Già Visto

Se ti sembra di aver già sentito questa storia, hai ragione. L'abbiamo vista accadere a giugno 2024 con polyfill.io. Un dominio che tutta la web aveva imparato a fidare ha cambiato mani, e oltre 100.000 siti si sono ritrovati improvvisamente a servire codice da qualcuno con intenzioni completamente diverse.

Il modello di fiducia si è rotto perché abbiamo confuso "questo dominio ha sempre servito contenuti sicuri" con "questo dominio servirà sempre contenuti sicuri".

La verità scomoda è che piniamo la nostra sicurezza sui domini invece che sul codice. Quando i domini cambiano mano, ogni sito che si fidava eredita le intenzioni del nuovo proprietario. Qualunque esse siano.

Cosa Fare Adesso

Controlla le tue dipendenze subito. Cerca nei codebase, nei database, nella documentazione qualsiasi riferimento a domini CDN deprecati o di terze parti. Non dare per scontato che un servizio chiuso sia un dominio innocuo.

Valuta l'auto-hosting per gli asset critici. Se un font, uno script o un foglio di stile è essenziale per la tua applicazione, portalo dentro casa. Il costo infrastrutturale è trascurabile rispetto al rischio che il browser dei tuoi utenti scarichi codice da una fonte non attendibile.

Implementa Subresource Integrity (SRI). Quando devi proprio usare risorse da CDN di terze parti, aggiungi hash crittografici ai tuoi tag <script> e <link>. SRI garantisce che anche se un attaccante prende il controllo di un dominio, non può servire codice modificato senza rompere i tuoi controlli di integrità.

Monitora la tua supply chain. Servizi come Report URI e vari strumenti di monitoraggio CSP possono avvisarti quando domini inaspettati appaiono nei tuoi report di sicurezza. Configura questi alert e prendili sul serio.

Il Quadro Più Ampio

Questa storia mette in luce una tensione fondamentale nello sviluppo web moderno: costruiamo sulla fiducia, ma raramente la rivediamo nel tempo. Una dipendenza perfettamente sicura l'anno scorso potrebbe servire malware il prossimo anno se il dominio cambia mano.

Da NameOcean parliamo spesso di sicurezza dei domini: DNSSEC, certificati SSL, blocchi presso il registrar. Ma storie come questa ci ricordano che la vera sfida non è solo proteggere i propri domini. È essere consapevoli di quali domini scegliamo di fidare, e avere sistemi per accorgerci quando quella fiducia potrebbe essere mal riposta.

Il web gira sulla fiducia. Assicurati che la tua sia ben riposta.