През юли 2025 г. някой регистрира домейн, който преди е принадлежал на мрежа за доставяне на съдържание (CDN). Дейността на CDN бе прекратена години по-рано, а домейнът, от който са се разпространявали ресурси, бе оставен да изтече. Това, което не бе загубено, са неговите потребители. Хиляди уебсайтове, хранилища за код и страници с документация все още съдържат твърдо кодирани препратки към имена на хостове под този домейн.

Новият собственик притежава маскиращи (wildcard) DNS записи за целия домейн и всяко име на хост под него вече се пренасочва към инфраструктура, контролирана от това лице. Днес основният домейн показва страница за изтегляне на медийно съдържание с множество реклами, което не е необичайно. Забележителното е, че решението какво да се зареди след това в тези хиляди страници вече принадлежи на непознат, а никой от засегнатите не е уведомен, тъй като отвън нищо не се е счупило.

Този модел не е хипотетичен и не е нечуван. През юни 2024 г. домейнът polyfill.io (JavaScript скрипт, вграден в повече от 110 000 сайта) промени собствеността си и започна да подава условни пренасочвания към мобилни посетители. Сайтовете, които го използват, не бяха хакнати, те просто са изнесли съдържание чрез <script> таг години по-рано и никога не са преразгледали това решение.

И двата случая споделят проблем, за който повечето екипи по сигурност нямат механизъм за контрол: злонамереният код никога не е бил на техния сървър и е пристигнал дълго след последното внедряване.

Инструментите от страната на сървъра търсят на погрешното място

Статичният анализ, сканирането на зависимости и анализът на софтуерния състав изследват това, което дадена организация изгражда и внедрява, но скриптът от трета страна не е нито едно от тези неща. Той се изтегля от браузъра на посетителя от сървър, който организацията не управлява и върху който няма контрол, на живо при всяко преглеждане на страница.

Това го прави изключително враждебен към конвенционалното тестване, тъй като отговорът може да варира според географията, потребителския агент, реферера, часа от денонощието и сесията. Crawler, изтеглящ файла веднъж от IP диапазон на център за данни, получава чиста версия; купувачът през мобилна мрежа в друга държава получава нещо много по-злонамерено.

Междувременно самият скрипт от трета страна притежава същите привилегии като вашия собствен код. Той може да чете DOM, да чете полетата на формуляри символ по символ при въвеждане, да чете бисквитки и локално хранилище, както и да прави външни заявки към всяко място, което поиска. Атаките от страната на клиента от типа Magecart въобще не изискват пробив в сървъра, те изискват един одобрен скриптов таг да започне да се държи по различен начин.

Браузърът вижда всичко

Има един наблюдател, който надеждно присъства при всяко едно от тези преглеждания на страници: браузърът, който е изпълнил кода. Политиката за сигурност на съдържанието (Content Security Policy - CSP) обикновено се обсъжда като защита срещу междинни атаки с междусайтови скриптове (XSS) и е добра такава, но нейната втора функция е по-полезна за екип по сигурност, който все още не знае какъв код изпълнява. CSP може да контролира кой код има право да се изпълнява на вашия уебсайт, да блокира код, който не е оторизиран, и да ви уведоми, когато това се случи.

Тези предупреждения идват от реални сесии, в реални географски ширини, от вашите реални потребители на техните реални устройства. Зловреден код, който се задейства само за влезли потребители в една държава, все пак се докладва, защото браузърът, който го е изпълнил, е този, който изпраща предупреждението.

Това не е теоретична полза. През септември 2026 г. тези предупреждения, събрани от Report URI, разкриха група от компрометирани сайтове за електронна търговия, провеждащи кампания за социално инженерство от семейството „ClickFix“. Зареждащи модули с Base64 кодиране са били поставени в CMS съдържанието след административно компрометиране, свързани през пренасочващ модул към фалшив слой „потвърдете, че сте човек“, който поставя PowerShell команда в клипборда на жертвата и я запазва като планирана задача. Контролираните от атакуващия имена на хостове се появиха в сигнали от браузърите на жертвите, докато няколко от тези домейни все още бяха оценени като чисти от основните услуги за репутация. Никой скенер не беше отбелязал страниците, защото на сървъра те бяха наред.

Можете да започнете с CSP, без да блокирате нищо

Честото възражение е, че политиката за сигурност на съдържанието ще развали сайта, но в режим само за докладване (report-only) тя не може да направи това. Content-Security-Policy-Report-Only не налага нищо, не блокира нищо и не променя поведението, а само докладва какво дадена политика би блокирала.

Това превръща първоначалното внедряване в безопасно измервателно упражнение и ви позволява да съберете всички необходими данни за това какъв код се изпълнява на вашия сайт. За повечето организации този списък е много по-дълъг, отколкото са очаквали.

Съответствието превърна това в задължение

За всеки, който обработва плащания с карти на сайта си, този аргумент вече е решен. Изисквания 6.4.3 и 11.6.1 на PCI DSS v4.0.1 престанаха да бъдат добра практика и станаха задължителни на 31 март 2025 г. Заедно те изискват всеки скрипт на страница за плащане да бъде разрешен, неговата цялост да е гарантирана, да съществува писмен опит с бизнес обосновка и механизъм да открива и предупреждава при неоторизирана промяна на съдържанието на страницата за плащане и HTTP заглавките.

Квалифициран оценител на сигурността (QSA) може и ще поиска описа на скриптовете, механизма за уведомяване и доказателствената следа, която той е произвел. Report URI може да ви предостави и трите.

Как изглежда едно работещо внедряване

  1. Внедрете и събирайте първоначални данни в продължение на една седмица.
  2. Създайте вашия опис от това, което е било докладвано.
  3. След следете промените във времето и одобрявайте или отхвърляйте тези промени.

Десетгодишно ежедневно обхождане на първите един милион сайта показва, че приемането на CSP нараства с над 12 000% през десетилетието, тъй като организациите осъзнават ползите, които тя предоставя. Този растеж отразява по-широка промяна в това къде организациите се нуждаят от видимост: не само в това какво внедряват, но и в това какъв код всъщност изпълняват браузърите на техните потребители.

Къде се вписва Report URI

Report URI е платформа за сигурност от страната на клиента, която отговаря на въпросите, на които екипът по сигурността не може да отговори по друг начин за собствения си сайт: кои трети страни изпълняват код на вашите страници? Кои се промениха от вчера? Кои вземат данни или комуникират с инфраструктура, за която е известно, че е враждебна? Скриптовете, обслужващи реални потребители, се хешират и архивират, така че промените могат да бъдат идентифицирани и разследвани след факта. Имената на хостовете се проверяват спрямо информация за заплахите, а политиките се следят за отклонения, затваряйки празнината между това, което сте одобрили, и това, което действително се изпълнява на вашия сайт.

Внедряването не добавя JavaScript към вашата страница и няма агент, модул или SDK към стекa.

Първата стъпка е лесна – добавете HTTP заглавка за отговор и прочетете какви данни се връщат през следващите 48 часа. Списъкът с неща, изпълняващи код в браузърите на вашите клиенти, рядко е списъкът, който някой е очаквал!