Een opvallend webincident begon met iets dat niet stuk ging: een domein dat ooit bij een content delivery network (CDN) hoorde, werd opnieuw geregistreerd. De duizenden websites, code-repositories en documentatiepagina’s die dat oude domein nog aanroepen, zagen van buiten geen storing. Maar achter de schermen kreeg iemand anders controle over wat er onder die hostnamen geladen werd.
Dit is een terugkerend patroon. Niet omdat organisaties “gehackt” zijn op hun eigen servers, maar omdat client-side code—vaak via een script-tag van een derde—later alsnog anders kan gaan werken. Met CSP detectie scripts kun je die kloof tussen wat je denkt te draaien en wat browsers daadwerkelijk uitvoeren dichten, zonder meteen alles te blokkeren.
Waarom een verlaten CDN domein gevaarlijk blijft
In een recente casus werd een CDN-gerelateerd domein na het verlopen van de oorspronkelijke dienstverlening opnieuw geregistreerd. Wat bleef staan, waren de hard-coded verwijzingen in bestaande sites. Zolang een pagina dat domein aanroept, kan de nieuwe eigenaar elk subdomein laten resolven naar infrastructuur die zij beheren.
De apex van het domein leek onschuldig—bijvoorbeeld een pagina met een downloader—maar de echte impact zat in wat er onderliggende hostnamen deden. Daardoor kwam de beslissingsmacht over wat duizenden pagina’s “vervolgens” laden bij een onbekende partij te liggen, terwijl niemand werd geïnformeerd omdat er aan de serverkant niets mis leek.
Hetzelfde probleem: polyfills en andere embedded scripts
Een soortgelijk scenario speelde eerder rond polyfill.io, een JavaScript shim die in meer dan 110.000 sites was ingebouwd. Toen het domein van eigenaar veranderde, ging het gedrag voor bepaalde bezoekers afwijken—bijvoorbeeld met conditional redirects voor mobiele bezoekers.
Belangrijk daarbij: de websites zelf waren niet per se gecompromitteerd. Ze hadden simpelweg jaren eerder besloten om een script-tag van die dienst te gebruiken en daarna niet meer opnieuw bekeken of er risico’s waren ontstaan.
Waarom traditionele security checks vaak de verkeerde plek bekijken
Veel securityprocessen richten zich op wat organisaties bouwen en publiceren. Denk aan static analysis, dependency scanning en software composition analysis. Dat zijn nuttige tools, maar ze “zien” third-party scripts niet op dezelfde manier als eigen code.
Een derde script wordt namelijk niet door jouw server geleverd. Het wordt door de browser opgehaald—live, bij elke page view—van een server die jij niet draait en vaak ook niet beheerst. Daarbij kan de uitkomst variëren op basis van factoren als locatie, user agent, referrer, tijdstip of sessie.
Een crawler die één keer vanaf een datacenter IP-randje laadt, kan een schone versie zien. Voor een echte gebruiker via een mobiel netwerk in een ander land kan het script wél een andere payload serveren. Daardoor kan server-side observatie een vals gevoel van veiligheid geven.
Waarom het browsermodel de echte waarheid is
Als code eenmaal in de browser draait, krijgt die code dezelfde rechten als eerste-party JavaScript. Dat betekent dat zo’n script bijvoorbeeld de DOM kan lezen, formuliervelden karakter voor karakter kan benaderen, cookies en local storage kan gebruiken en outbound requests kan doen naar willekeurige infrastructuur.
Aanvallen in de stijl van Magecart vereisen daarom geen server breach. Eén “goedgekeurde” script-tag die later kwaadaardig gedrag gaat vertonen, kan al voldoende zijn.
CSP detectie scripts: beleid dat niet blokkeert, maar onthult
Content Security Policy (CSP) wordt vaak genoemd als verdediging tegen cross-site scripting. Maar er zit minstens zo’n praktische tweede functie achter die securityteams direct helpt: met CSP kun je ook meten welke code werkelijk draait.
Als je CSP slim inzet—bijvoorbeeld via een rapportage-modus—kun je zien wanneer de browser code probeert te laden of uit te voeren die niet volgens je beleid is toegestaan. En dat gebeurt in de echte context van je gebruikers: echte geografieën, echte apparaten en sessies die jouw monitoring anders nooit bereikt.
Report-only gebruiken om eerst een nulmeting te maken
De grootste drempel is vaak: “CSP breekt de site.” Die zorg kun je aanpakken door eerst te werken met Content-Security-Policy-Report-Only.
In die modus wordt er niets afgedwongen. CSP blokkeert niet, verandert geen gedrag en staat dus geen site-uitval in de weg. Je verzamelt alleen rapporten van wat je beleid zou hebben tegengehouden.
Dat maakt de eerste implementatie een veilige meetoefening. Je krijgt een lijst van werkelijke scripts en hostnames die in browsers actief zijn. Voor veel organisaties is dat lijstje verrassend langer dan verwacht.
Voorbeeld: waarnemingen uit echte gebruikersrapporten
Het nut van deze benadering is concreet aangetoond met rapportage-telemetrie uit de praktijk. In september 2026 werden via rapportage door Report URI signalen gezien van een cluster gecompromitteerde e-commerce omgevingen die een sociale-engineering campagne uitvoerden.
De keten begon met basisinformatie die na een administratieve compromis in CMS-content werd geplaatst. Vervolgens werd er via een redirector een nep “verify you are human”-laag getoond. Daarna werd een PowerShell-commando op het systeem van de bezoeker geplaatst, waarna persistentie werd gerealiseerd door een geplande taak. In dashboards zagen onderzoekers dat attacker-controlled hostnames optraden in browsermeldingen, terwijl enkele domeinen bij gangbare reputatiediensten nog als “schoon” konden verschijnen.
Cruciaal: scanner-achtige checks konden de pagina’s missen, omdat de pagina’s aan de serverkant ogenschijnlijk normaal waren. De afwijking zat in het gedrag dat pas in de browser duidelijk werd.
Waarom compliance CSP detectie scripts versnelt
Voor organisaties die kaartbetalingen verwerken, is het argument “we kijken later wel” snel gedaan. In de context van PCI DSS v4.0.1 zijn eisen vanaf 31 maart 2025 niet langer alleen best practice.
Volgens de aangehaalde vereisten draait het om het inventariseren en onderbouwen van scripts op payment pages, het waarborgen van integriteit en het hebben van detectie en alerting bij ongeautoriseerde wijzigingen aan content en HTTP-headers. Een QSA kan een inventaris, bewijs voor de detectie en de audit trail opvragen.
Met CSP-rapportage kun je die “wat draaide er precies” vraag beantwoorden. Omdat rapporten op basis van echte sessies ontstaan, is het bewijs vaak concreter dan alleen server logs.
Zo ziet een werkende uitrol eruit
Een pragmatische manier om CSP detectie scripts te gebruiken, bestaat uit een gefaseerde aanpak:
- Deploy en verzamel data: start met een periode van bijvoorbeeld een week om baseline-gegevens op te halen.
- Bouw een inventaris: maak op basis van de rapporten een lijst van wat er bij gebruikers daadwerkelijk draait.
- Monitor wijzigingen: volg vervolgens veranderingen over de tijd en beoordeel of een wijziging geaccepteerd moet worden.
Een lange horizon helpt. In de praktijk laat intensief crawl-werk zien dat CSP-adoptie over een periode van tien jaar sterk groeide. Dat hangt samen met een bredere verschuiving: niet alleen zicht op wat je deployt, maar ook op wat bezoekers-browsers executeren.
Waar Report URI in past (en wat het oplevert)
Report URI wordt in dit verband neergezet als een client-side security platform dat vragen beantwoordt waar je met standaard server tools niet eenvoudig aan komt. Bijvoorbeeld:
- Welke derde partijen voeren code uit op je pagina’s?
- Wat is er veranderd ten opzichte van eerder?
- Welke scripts communiceren met infrastructuur die als verdacht bekendstaat?
Daarnaast wordt genoemd dat scripts die door echte gebruikers zijn geserveerd worden hashed en gearchiveerd. Daardoor kun je wijzigingen achteraf identificeren en onderzoeken. Ook worden hostnames gecontroleerd tegen threat intelligence en wordt er gemonitord op policy drift, zodat je beleid en werkelijke uitvoering dichter bij elkaar blijven.
Volgens de beschrijving voegt zo’n inzet geen extra JavaScript aan de pagina toe en ook geen agent, module of SDK aan je stack.
Start klein: de eerste stap is een header
De laagdrempelige start die hier wordt geschetst is relatief eenvoudig. Voeg een CSP-gerelateerde HTTP response header toe en bekijk wat er de komende 48 uur aan rapporten binnenkomt.
Verwachting: de lijst met hostnames en scripts die in echte browsers draaien, blijkt vaak anders dan wat teams “op papier” hadden verwacht. Juist die discrepantie is waar CSP detectie scripts waardevol wordt.
Conclusie: voorkom verrassingen buiten je eigen server
Incidenten zoals een hergeregistreerd CDN-domein of veranderend gedrag van embedded services laten één kernpunt zien: veel risico ontstaat niet op je eigen server, maar in wat je bezoekers browserlaadt. Omdat third-party code dezelfde bevoegdheden kan hebben als je eigen scripts, is alleen vertrouwen op deployment- en dependency-checks onvoldoende.
Met CSP detectie scripts, zeker gestart via report-only, maak je zichtbaar welke code er werkelijk draait in de wereld van je gebruikers. Daarmee krijg je bewijs, bouw je een bruikbare inventaris en kun je sneller ingrijpen wanneer beleid en realiteit uit elkaar groeien.
Bron: https://thehackernews.com/2026/09/an-abandoned-cdn-domain-was-re.html
