Scaricare i siti web che utilizzano jsDelivr

Informazioni su jsDelivr

Ogni script che una pagina carica dal dominio di qualcun altro è un piccolo atto di fiducia, rinnovato a ogni visualizzazione. jsDelivr è uno dei domini a cui quella fiducia si rivolge, una rete di distribuzione pubblica e gratuita che serve pacchetti, release e risorse di plugin a qualsiasi pagina disposta a collegarvisi.

Nessuno acquista il servizio, e questo cambia il significato di un suo conteggio. Non c’è contratto né account, quindi un sito compare qui perché uno sviluppatore ha incollato un URL o, più spesso, perché un tema, un plugin o un template di documentazione lo ha fatto anni fa e nessuno ha più riconsiderato la scelta. Di conseguenza la rilevazione è diretta, dato che la destinazione della richiesta è scritta nel markup che scarichiamo. La rilevazione non può stabilire, invece, se il titolare del sito sappia che la dipendenza è lì.

A ottobre 2026 il file contiene 5.736.664 siti che caricano risorse dalla rete, di cui 3.013.734 negli Stati Uniti, con una distribuzione dei domini in cui l’estensione .com è fortemente rappresentata. Su una scala di questo ordine si regge l’intero ragionamento sulla sicurezza. Una rete pubblica presente su così tante pagine è un’infrastruttura, e un’infrastruttura fornita gratuitamente è un’infrastruttura senza alcun rapporto cliente-fornitore su cui contare quando qualcosa va storto.

Il progetto è attivo dal 2012 con licenza MIT, è finanziato da sponsorizzazioni e si appoggia a diverse reti commerciali con failover automatico. L’apertura è un punto di forza reale ed è anche il motivo per cui un questionario di due diligence ne chiede conto. Un URL fissato a una versione è riproducibile e si comporta come una dipendenza. Un URL fissato in modo approssimativo, o non fissato affatto, è una promessa permanente che qualunque cosa il manutentore pubblichi in seguito verrà eseguita dentro le pagine del sito, dove le sessioni degli utenti sono a portata di mano. La distinzione tecnica è invisibile in una colonna booleana, ed è per questo che il riferimento grezzo conta più del flag.

I team di sicurezza applicativa vogliono la visione d’insieme della popolazione perché i loro inventari coprono solo i domini che ricordano di possedere, ed è nei marchi acquisiti e nei microsite delle campagne che si accumulano le origini di terze parti. I fornitori di strumenti per la subresource integrity, per le content security policy o per la scansione delle dipendenze cercano potenziali clienti le cui pagine attingono già a origini esterne. I manutentori di pacchetti vogliono sapere dove le loro release vengono realmente utilizzate, cosa che i conteggi di download dei registri non mostrano mai, perché una richiesta a una rete di distribuzione non è l’installazione di un pacchetto.

I limiti meritano di essere dichiarati con chiarezza. Registriamo l’origine a cui una pagina fa riferimento, non ciò che è stato restituito, quindi un collegamento obsoleto a qualcosa rimosso da tempo conta comunque come riferimento. Le risorse iniettate in seguito da un altro script possono sfuggire del tutto. Un indicatore a livello di sito nasconde inoltre la profondità, perché una piccola libreria su un modulo di contatto e un’intera shell applicativa piena di dipendenze appaiono identiche in una colonna sì o no, e il rischio che rappresentano non è neanche lontanamente lo stesso.

Una ricerca per singolo dominio dice se una pagina fa riferimento alla rete oggi. Il download risponde a ciò che viene dopo: quali settori contengono riferimenti pubblici a servizi della categoria CDN, come si è spostata la quota man mano che i bundler diventavano lo standard, quali provider di hosting e quali paesi concentrano l’esposizione, e quali siti combinano questa origine con diverse altre sulla stessa pagina. Ogni riga riporta paese, estensione e il resto dello stack rilevato, così l’esposizione verso terze parti si può dimensionare su un intero mercato invece di campionarla un hostname alla volta.