När dina CDN-beroenden blir en säkerhetsmardröm: Lärdomar från ett domänövertagande

Varje webbplats är en blandning av kod du skriver och kod du litar på. De flesta utvecklare lägger massor av tid på att säkra det förra. Beroenden och externaliteter får betydligt mindre uppmärksamhet – tills något går fel.

En nyligen upptäckt i verkligheten har blåst liv i frågan. Den visar ett scenario som borde få varje utvecklare att stanna upp och granska sina tredjepartsberoenden.

Historien om en domän ingen ville ha längre

Tänk dig följande: en populär CDN-tjänst som drevs i över ett decennium och levererade statiskt innehåll till tusentals WordPress-sajter lägger ner. Företaget blir uppköpt, verksamheten avvecklas och till slut löper domänregistreringen ut. Någon annan köper den. Och den personen kontrollerar nu alla subdomäner som någonsin pekade mot dina assets.

Det här är inte en teoretisk övning. Det är exakt vad som hände med netdna-ssl.com – den asset-domän som låg bakom MaxCDN, en tjänst som många WP Engine-kunder använde för att leverera statiska filer. När MaxCDN absorberades av StackPath och till slut lades ner, tilläts domänen att gå ut. I juli 2025 registrerades den på nytt.

Den nya ägaren fick omedelbart kontroll över wildcard-DNS för hela *.wpengine.netdna-ssl.com-namnrymden. Varje hash-baserad subdomän som din sajt kanske fortfarande refererar till? Nu kontrollerad av en främmande person som driver en Instagram-nedladdare med Google AdSense.

Varför det här är värre än du tror

Du tänker kanske: "Vad spelar det för roll? Ingen använder det här längre. Det är legacy-infrastruktur."

Men här misstar vi oss.

Forskning visar att ungefär 4 000 filer på GitHub ensamt fortfarande innehåller referenser till dessa legacy-domäner. Vi pratar inte om övergivna repositories heller – projekt som Mozillas webxr-polyfill, tillsammans med sajter tillhörande Kong, Nextcloud, Yale Daily News och otaliga andra organisationer, hämtar fortfarande assets från dessa nedlagda slutpunkter.

Ännu mer oroande? Cloudflare Radar rankar netdna-ssl.com bland de topp 20 000 globala domänerna. Det betyder att riktiga webbläsare fortfarande resolverar detta namn, i betydande volym. Det här är inte arkeologiska kuriositeter – de är aktiva, levande beroenden.

Problemet med den laddade pistolen

Här blir situationen särskilt farlig. Just nu är de legacy asset-URL:erna i praktiken brutna. Den nya ägaren har satt upp Cloudflare med ett standard-SSL-certifikat som täcker apex-domänen och några proxy-subdomäner, men inte wildcard-mönstret för legacy asset-värdar. När en webbläsare försöker ladda ett skript eller typsnitt från en subdomän som xyz123.wpengine.netdna-ssl.com, misslyckas TLS-handskakningen.

Kortsiktigt skyddar det användarna. Webbläsaren blockerar innehållet istället för att köra det.

Men fundera på vad det betyder: Attackeraren har redan fullständig DNS-kontroll. De har redan monetiseringsinfrastruktur igång. De har redan hosting konfigurerad. Det enda som skiljer situationen från en katastrof är en enda konfigurationsändring i Cloudflares Advanced Certificate Manager.

Säkerhetsproffs kallar detta en "laddad pistol" – en sårbarhet som för närvarande inte är utnyttjad men som kan bli katastrofal med minimal ansträngning från angriparen.

Vi har sett det här förut

Om det här scenariot känns obehagligt bekant är det för att vi bevittnade samma sak i juni 2024 med polyfill.io. En domän som hela webben hade lärt sig att lita på bytte ägare, och över 100 000 sajter fann sig plötsligt leverera kod från en operatör med helt andra intentioner. Tillitsmodellen bröt samman för att vi förväxlade "den här domänen har alltid serverat säkert innehåll" med "den här domänen kommer alltid att servera säkert innehåll."

Den obekväma sanningen är att vi pillar vår säkerhet på domäner snarare än kod. När domäner byter ägare ärver varje sajt som litade på dem den nya ägarens avsikter, vad de än må vara.

Vad du bör göra nu

Granska dina beroenden omedelbart. Sök igenom dina kodbaser, databaser och dokumentation efter referenser till nedlagda eller tredjeparts-CDN-domäner. Anta inte att en tjänst som lagt ner har inerta domäner.

Överväg självhosting av kritiska assets. Om ett typsnitt, skript eller stylesheet är viktigt för din applikation, ta det in-house. Den minimala infrastrukturkostnaden är försumbar jämfört med risken att användarnas webbläsare hämtar kod från en opålitlig källa.

Implementera Subresource Integrity (SRI). När du måste använda tredjeparts-CDN-resurser, lägg till kryptografiska hashvärden i dina <script> och <link>-taggar. SRI säkerställer att även om en angripare får kontroll över en domän kan de inte leverera modifierad kod utan att bryta dina integrity-kontroller.

Övervaka din supply chain. Tjänster som Report URI och diverse CSP-verktyg kan varna dig för oväntade domäner som dyker upp i dina säkerhetsrapporter. Sätt upp dessa aviseringar och ta dem på allvar.

Den större bilden

Den här händelsen belyser en fundamental spänning i modern webbutveckling: vi bygger på tillit, men vi granskar sällan den tilliten över tid. Ett beroende som var fullständigt säkert förra året kan leverera skadlig kod nästa år om domänen byter ägare.

Vi pratar mycket om domänsäkerhet på den här bloggen – DNSSEC, SSL-certifikat, registrar lås. Men historier som den här påminner oss om att den verkliga säkerhetsutmaningen inte bara handlar om att skydda dina egna domäner. Det handlar om att vara medveten om vilka domäner du väljer att lita på från första början, och att ha system på plats för att upptäcka när den tilliten kan vara felplacerad.

Webben kör på tillit. Se till att din är placerad klokt.