De Verborgen Risico's van CDN-afhankelijkheden: Lessen uit een Domain Takeover

Elke website bestaat uit code die je zelf schrijft en code waar je op vertrouwt. Ontwikkelaars besteden veel tijd aan het beveiligen van het eerste deel, maar het tweede krijgt vaak beduidend minder aandacht. Een recente ontdekking heeft deze onbalans scherp in beeld gebracht en laat zien dat elke ontwikkelaar even stil zou moeten staan bij zijn externe afhankelijkheden.

Het Verhaal van een Domein dat Niemand Wilde

Stel je voor: een populaire CDN-dienst die duizenden WordPress-sites meer dan tien jaar lang van stroom voorzag, sluit plotseling de deuren. Het bedrijf wordt overgenomen, activiteiten worden afgebouwd en uiteindelijk vervalt de domeinregistratie. Iemand anders koopt het domein en heeft nu controle over elk subdomein dat ooit naar jouw assets heeft gewezen.

Dit is geen theoretisch scenario. Dit is exact wat er is gebeurd met netdna-ssl.com, het asset-domein achter MaxCDN waar veel WP Engine-klanten op vertrouwden voor statische content. Toen MaxCDN werd opgeslokt door StackPath en later werd afgestoten, mocht het domein vervallen. In juli 2025 werd het stilletjes opnieuw geregistreerd.

De nieuwe eigenaar kreeg meteen controle over wildcard DNS voor de volledige *.wpengine.netdna-ssl.com naamruimte. Elk hash-gebaseerd subdomein dat jouw site nog steeds aanspreekt? Nu in handen van een volslagen vreemde die een Instagram-downloader runt met Google AdSense.

Waarom Dit Belangrijker Is Dan Je Denkt

Je denkt misschien: "Nou en? Niemand gebruikt dit nog. Oude infrastructuur." Maar hier gaat onze intuïtie de fout in.

Onderzoek toont aan dat ongeveer 4.000 bestanden op GitHub alleen al verwijzingen bevatten naar deze legacy-domeinen. We hebben het niet over verlaten repositories – projecten zoals Mozilla's webxr-polyfill, samen met sites van Kong, Nextcloud, Yale Daily News en tal van andere organisaties, halen nog steeds assets van deze deprecated eindpunten.

Nog verontrustender? Cloudflare Radar rangschikt netdna-ssl.com binnen de top 20.000 domeinen wereldwijd. Dit betekent dat echte browsers deze naam nog steeds resolven, in aanzienlijke volumes. Dit zijn geen archeologische curiosa; het zijn actieve, levende afhankelijkheden.

Het Geladen Geweer Probleem

Hier wordt het echt gevaarlijk. Op dit moment zijn die legacy asset-URL's eigenlijk kapot. De nieuwe eigenaar heeft Cloudflare ingesteld met een standaard SSL-certificaat dat het apex-domein en enkele proxy-subdomeinen dekt, maar niet het wildcard-patroon voor legacy asset-hosts. Wanneer een browser probeert een script of font te laden vanaf een subdomein zoals xyz123.wpengine.netdna-ssl.com, faalt de TLS-handshake.

Korte termijn is dit gebruikersbescherming. De browser blokkeert de content in plaats van deze uit te voeren. Maar denk na over wat dit betekent: de aanvaller heeft nu al volledige DNS-controle. Hij heeft al monetisatie-infrastructuur draaien. Hij heeft al hosting geregeld. Het enige dat dit scheidt van een catastrofe is één configuratietoggle in Cloudflare's Advanced Certificate Manager.

Dit noemen beveiligingsprofessionals een "geladen geweer" – een kwetsbaarheid die nu niet exploiteerbaar is, maar met minimale inspanning van de aanvaller catastrofaal zou kunnen worden.

We Hebben Dit Verhaal eerder Gezien

Als dit scenario je ongemakkelijk bekend voorkomt, is dat omdat we dit in juni 2024 zagen gebeuren met polyfill.io. Een domein waarop het hele web had geleerd te vertrouwen, wisselde van eigenaar en meer dan 100.000 sites ontdekten plotseling dat ze code serveerden van een partij met totaal andere bedoelingen. Het vertrouwensmodel brak omdat we "dit domein heeft altijd veilige content geleverd" verwarden met "dit domein zal altijd veilige content leveren."

De ongemakkelijke waarheid is dat we onze beveiliging vastpinnen aan domeinen in plaats van code. Wanneer domeinen van eigenaar wisselen, erft elke site die erop vertrouwde de nieuwe intenties van de nieuwe eigenaar, wat die ook mogen zijn.

Wat Je Nu Zou Moeten Doen

Controleer je afhankelijkheden direct. Doorzoek je codebases, databases en documentatie naar verwijzingen naar deprecated of externe CDN-domeinen. Ga er niet vanuit dat, omdat een dienst is gestopt, zijn domeinen inactief zijn.

Overweeg zelf hosting voor kritieke assets. Als een font, script of stylesheet essentieel is voor je applicatie, haal het dan in eigen huis. De geringe infrastructuurkosten zijn niets vergeleken bij het risico dat browsers van je gebruikers code ophalen van een niet-vertrouwde bron.

Implementeer Subresource Integrity (SRI). Wanneer je externe CDN-bronnen moet gebruiken, voeg dan cryptografische hashes toe aan je <script> en <link> tags. SRI zorgt ervoor dat zelfs als een aanvaller controle krijgt over een domein, hij geen aangepaste code kan serveren zonder je integriteitscontroles te breken.

Monitor je supply chain. Diensten zoals Report URI en diverse CSP-monitoringtools kunnen je waarschuwen wanneer onverwachte domeinen verschijnen in je beveiligingsrapportages. Stel deze alerts in en neem ze serieus.

Het Grotere Plaatje

Dit incident belicht een fundamentele spanning in moderne webontwikkeling: we bouwen op vertrouwen, maar controleren dat vertrouwen zelden over tijd. Een afhankelijkheid die vorig jaar perfect veilig was, zou volgend jaar malware kunnen serveren als het domein van eigenaar wisselt.

Bij NameOcean hebben we het vaak over domeinbeveiliging – DNSSEC, SSL-certificaten, registrar locks. Maar verhalen als dit herinneren ons eraan dat de echte beveiligingsuitdaging niet alleen is het beschermen van je eigen domeinen; het is nadenken over welke domeinen je in de eerste plaats kiest om te vertrouwen, en systemen hebben om te detecteren wanneer dat vertrouwen mogelijk misplaatst is.

Het web draait op vertrouwen. Zorg ervoor dat het jouwe verstandig wordt geplaatst.