Skrytá nebezpečí v CDN závislostech: Jak jeden expirovaný domain může ohrozit tisíce webů

Každý web je směsicí kódu, který napíšete, a kódu, kterému věříte. Vývojáři obvykle bedlivě střeží to první, ale tomu druhému věnují překvapivě málo pozornosti. Nedávný případ z praxe ale ukazuje, jak riskantní tato důvěra může být.

Když domain nikdo nechce

Představte si situaci: Oblíbená CDN služba, která roky poháněla tisíce WordPress stránek, náhle skončí. Firmu někdo koupí, provoz se utlumí a nakonec expirouje domain registration. Nový majitel? Ten teď ovládá všechny subdomény, na které kdysi směřovaly vaše assety.

Přesně tohle se stalo s netdna-ssl.com – asset domain služby MaxCDN, na které spoléhaly tisíce zákazníků WP Engine. Když MaxCDN absorboval StackPath a pak skončil, domain prostě vypršel. V červenci 2025 ho někdo znovu zaregistroval.

Nový majitel získal kontrolu nad wildcard DNS pro celý prostor *.wpengine.netdna-ssl.com. Každá hash-based subdoména, na kterou váš web možná pořád odkazuje? Teď ji ovládá cizí člověk provozující Instagram stahovač s Google AdSense.

Proč byste se měli bát

Možná si říkáte: "Koho to zajímá? Nikdo to už nepoužívá, je to legacy." Tady se ale naše intuice mýlí.

Research ukazuje, že přibližně 4 000 souborů na GitHubu stále obsahuje odkazy na tyto legacy domény. Nemluvíme o opuštěných repozitářích – projekty jako Mozilla webxr-polyfill, weby Kongu, Nextcloud, Yale Daily News a dalších organizací pořád tahají assety z těchto deprecated endpointů.

A co víc? Cloudflare Radar řadí netdna-ssl.com mezi top 20 000 domén celosvětově. Reální prohlížeče tuto doménu pořád aktivně resolví, a to v nemalém objemu. Nejsou to žádné archeologické kuriozity – jsou to živé, aktivní závislosti.

Problém nabité zbraně

Tady je to nejnebezpečnější. Teď jsou ty legacy asset URL v podstatě nefunkční. Nový majitel nastavil Cloudflare se standardním SSL certifikátem, který pokrývá apex domain a pár proxy subdomén, ale ne wildcard pattern pro legacy asset hosty. Když prohlížeč zkusí načíst script nebo font ze subdomény jako xyz123.wpengine.netdna-ssl.com, TLS handshake selže.

Krátkodobě to chrání uživatele – prohlížeč obsah zablokuje místo jeho spuštění. Ale uvědomte si tohle: útočník už má úplnou DNS kontrolu. Už má monetization infrastrukturu. Už má hosting. Jediná věc, která ho dělí od katastrofy, je jedno kliknutí v nastavení Cloudflare Advanced Certificate Manager.

Bezpečnostní profesionálové tomu říkají "loaded gun" – zranitelnost, která teď není využitelná, ale s minimálním úsilím se může stát katastrofální.

Tohle už jsme viděli

Pokud vám ten scénář přijde povědomý, je to proto, že jsme tohle sledovali v červnu 2024 s polyfill.io. Domain, kterému celý web naučil věřit, změnil majitele a přes 100 000 stránek najednou servírovalo kód od provozovatele s úplně jinými úmysly. Model důvěry se rozbil, protože jsme zaměnili "tato doména vždycky servírovala bezpečný obsah" s "tato doména vždycky bude servírovat bezpečný obsah".

Nepohodlná pravda je, že svou bezpečnost zakládáme na doménách, ne na kódu. Když domain změní majitele, každý web, který jí důvěřoval, automaticky dědí nové záměry toho majitele.

Co dělat hned teď

Proauditujte své závislosti. Prohledejte kód, databáze i dokumentaci pro jakékoli odkazy na deprecated nebo třetí stranou provozované CDN domény. Nepředpokládejte, že když služba skončila, její domény jsou neaktivní.

Zvažte self-hosting kritických assetů. Pokud je font, script nebo stylesheet pro vaši aplikaci zásadní, přemístěte ho k sobě. Minimální náklady na infrastrukturu jsou zanedbatelné ve srovnání s rizikem, že prohlížeče vašich uživatelů stáhnou kód z nedůvěryhodného zdroje.

Implementujte Subresource Integrity (SRI). Když musíte použít third-party CDN resources, přidejte kryptografické hash do vašich <script> a <link> tagů. SRI zajistí, že i když útočník získá kontrolu nad doménou, nemůže servírovat upravený kód bez rozbítí vašich integritních kontrol.

Monitorujte svůj supply chain. Služby jako Report URI a různé CSP monitoring nástroje vás upozorní na neočekávané domény ve vašich bezpečnostních reportech. Nastavte tyto alerty a berte je vážně.

Větší obrázek

Tento incident odhaluje fundamentální napětí v moderním webovém vývoji: stavíme na důvěře, ale tu důvěru v čase téměř nikdy neauditujeme. Závislost, která byla loni naprosto bezpečná, může příští rok servírovat malware – stačí, když domain změní majitele.

U NameOcean se hodně bavíme o bezpečnosti domén – DNSSEC, SSL certifikáty, registrar locks. Ale příběhy jako tenhle nám připomínají, že skutečná bezpečnostní výzva není jen ochrana vlastních domén. Je to být uvědomělý ohledně toho, kterým doménám se rozhodnete věřit, a mít systémy, které vám řeknou, když se ta důvěra může zneužít.

Web běží na důvěře. Ujistěte se, že ta vaše je namířená správně.