Скрытые угрозы в ваших CDN-зависимостях: урок, который стоит усвоить

Каждый сайт — это конструктор. Часть деталей вы создаёте сами, остальные берёте у других. Защите своего кода мы уделяем массу внимания, а вот чужие библиотеки и сервисы проверяем куда реже. История, о которой пойдёт речь, показывает, чем это чревато.

Как домен, который никому не нужен, оказался в чужих руках

Представьте: популярный CDN-сервис много лет раздавал статику тысячам сайтов, а потом закрылся. Компанию купили, операции свернули, домен не продлили. И вот новый владелец регистрирует его и получает контроль над всеми поддоменами, где когда-то хранились ваши assets.

Именно это произошло с netdna-ssl.com — доменом MaxCDN, обслуживавшим WordPress-сайты на WP Engine. Когда MaxCDN поглотила StackPath и прекратила работу, домен истёк. А в июле 2025-го его перехватили.

Теперь у нового владельца полный контроль над DNS во всём пространстве *.wpengine.netdna-ssl.com. Все поддомены с хешами, которые ваш сайт может до сих пор запрашивать? Ими управляет незнакомец, разместивший на сервере Instagram-скачивалку с Google AdSense.

Почему это касается даже вас

Может показаться: ну и что? Всё это уже история, легаси-инфраструктура. Но реальность говорит иначе.

Исследователи нашли примерно 4 000 файлов на GitHub со ссылками на эти домены. Среди них — не заброшенные репозитории, а активные проекты: Mozilla webxr-polyfill, сайты Kong, Nextcloud, Yale Daily News и других организаций. Они по-прежнему тянут assets с этих мёртвых эндпоинтов.

Cloudflare Radar помещает netdna-ssl.com в топ-20 000 глобальных доменов по трафику. Реальные браузеры каждый день резолвят это имя — и не в единичных случаях. Это не археология, а работающая зависимость.

Проблема заряженного оружия

Вот что делает ситуацию по-настоящему тревожной. Сейчас эти URL по сути неработоспособны. Новый владелец настроил Cloudflare с обычным SSL-сертификатом — он покрывает apex-домен и несколько проксируемых поддоменов, но не wildcard для legacy asset-хостов. Когда браузер пытается загрузить скрипт или шрифт с поддомена вроде xyz123.wpengine.netdna-ssl.com, TLS-хендшейк падает.

Короткосрочно это защищает пользователей — браузер блокирует контент, не выполняет его. Но задумайтесь: атакующий уже имеет полный DNS-контроль. У него уже работает монетизация. Серверы уже настроены. Единственное, что отделяет это от катастрофы — одна галочка в Cloudflare Advanced Certificate Manager.

Специалисты называют такое «заряженным ружьём» — уязвимость, которая сейчас не эксплуатируется, но может стать смертоносной от одного движения пальца.

Мы это уже проходили

История кажется знакомой? В июне 2024 года похожее случилось с polyfill.io. Домен, которому доверял весь веб, сменил владельца, и свыше 100 000 сайтов внезапно начали раздавать код от человека с совершенно другими намерениями. Модель доверия сломалась, потому что мы решили: раз домен всегда отдавал безопасный контент, так будет вечно.

Неудобная правда в том, что мы завязываем безопасность на домены, а не на код. Когда домен меняет руки, каждый сайт, который ему доверял, автоматически доверяет новому владельцу — с его целями и мотивами.

Что делать уже сейчас

Проведите аудит зависимостей. Пройдитесь по коду, базам данных, документации — найдите все ссылки на устаревшие и сторонние CDN-домены. Не думайте, что закрытый сервис автоматически означает безопасный домен.

Хостите критичные assets сами. Если шрифт, скрипт или стилевой файл важен для приложения — держите его на своём сервере. Затраты на инфраструктуру несопоставимы с риском подставить браузеры пользователей под чужой код.

Используйте Subresource Integrity (SRI). Когда без стороннего CDN не обойтись, добавьте криптографические хеши в теги <script> и <link>. SRI гарантирует: даже если атакующий получит контроль над доменом, подменённый код сломает проверку целостности.

Мониторьте свою цепочку поставок. Сервисы вроде Report URI и инструменты мониторинга CSP умеют сигнализировать о неожиданных доменах в ваших security-отчётах. Настройте алерты и реагируйте на них.

Главный вывод

Эта история вскрывает фундаментальное противоречие веб-разработки: мы строим на доверии, но редко пересматриваем его. Зависимость, которая была безопасной вчера, может стать источником малвари завтра — стоит только домену сменить владельца.

В разговорах о доменной безопасности мы обычно фокусируемся на DNSSEC, SSL-сертификатах, registrar locks. Но подобные случаи напоминают: настоящий вызов не только в защите собственных доменов, но и в осознанном выборе, каким доменам мы вообще доверяем — и как быстро заметим, когда это доверие окажется подорвано.

Веб построен на доверии. Убедитесь, что ваше — заслуженное.