In juli 2025 registreerde iemand een domein dat vroeger deel uitmaakte van een contentleveringsnetwerk. Het CDN was jaren eerder opgeheven en het domein waarvandaan activa werden bediend, mocht verlopen. Wat het niet had verloren, waren zijn bellers. Duizenden websites, codeopslagplaatsen en documentatiepagina’s bevatten nog steeds hardgecodeerde verwijzingen naar hostnamen eronder.
De nieuwe eigenaar beschikt over wildcard-DNS voor het hele domein, en elke hostnaam daaronder wordt nu omgezet naar de infrastructuur die die persoon beheert. Tegenwoordig serveert de top een media-downloaderpagina met veel advertenties, wat onopvallend is. Het opmerkelijke is dat de beslissing over wat die duizenden pagina’s vervolgens laden, aan een vreemde toebehoort, en dat niemand erbij betrokken is, omdat er van buitenaf niets kapot is gegaan.
Dit patroon is niet hypothetisch, en ook niet ongehoord. In juni 2024 veranderde het polyfill.io-domein (een JavaScript-shim ingebed in meer dan 110.000 sites) van eigenaar en begon het voorwaardelijke omleidingen aan mobiele bezoekers aan te bieden. De sites waarop het werd uitgevoerd, waren niet gehackt, ze hadden eenvoudigweg een
Beide gevallen delen een probleem waar de meeste beveiligingsteams geen controle over hebben: de kwaadaardige code stond nooit op hun server en arriveerde lang nadat de laatste implementatie had plaatsgevonden.
Server-side tooling zoekt op de verkeerde plaats
Statische analyse, afhankelijkheidsscanning en analyse van de softwaresamenstelling onderzoeken allemaal wat een organisatie bouwt en levert, maar een script van derden is niets van dat alles. Het wordt opgehaald door de browser van de bezoeker, van een server waar de organisatie niet op draait en waar geen controle over is, live bij elke paginaweergave.
Dat maakt het uniek vijandig tegenover conventioneel testen, omdat de reactie kan variëren per geografie, user-agent, verwijzer, tijdstip van de dag en sessie. Een crawler die het bestand één keer uit het IP-bereik van een datacenter haalt, krijgt een schone versie te zien; de shopper op een mobiel netwerk in een ander land krijgt iets sinisters.
Ondertussen heeft het script van derden zelf dezelfde rechten als uw eigen code. Het kan de DOM lezen, formuliervelden karakter voor karakter lezen terwijl ze worden getypt, cookies en lokale opslag lezen en uitgaande verzoeken doen naar waar het maar wil. Aanvallen aan de clientzijde van het Magecart-type vereisen helemaal geen serverinbraak; er is één goedgekeurde scripttag nodig om zich anders te gaan gedragen.
De browser ziet alles
Er is één waarnemer die betrouwbaar aanwezig is bij elk van deze paginaweergaven: de browser die de code heeft uitgevoerd. Content Security Policy wordt meestal besproken als verdediging tegen cross-site scripting, en het is een goede, maar de tweede functie is nuttiger voor een beveiligingsteam dat nog niet weet welke code het gebruikt. Een CSP kan bepalen welke code op uw website mag worden uitgevoerd, code blokkeren die niet mag worden uitgevoerd en u laten weten wanneer dat gebeurt.
Deze waarschuwingen komen van echte sessies, in echte geografische gebieden, van uw echte gebruikers op hun echte apparaten. Een kwaadaardige payload die alleen wordt geactiveerd voor ingelogde gebruikers in één land, wordt nog steeds gerapporteerd, omdat de browser die deze uitvoerde degene is die de waarschuwing verzendt.
Dit is geen theoretisch voordeel. In september 2026 brachten deze door Report URI verzamelde waarschuwingen een cluster van gecompromitteerde e-commercesites aan het licht die een social-engineeringcampagne van de “ClickFix”-familie voerden. Na een administratieve inbreuk waren met Base64 gecodeerde laders in de CMS-inhoud geplaatst, die via een redirector werden gekoppeld aan een neppe ‘verifieer dat je een mens bent’-overlay die een PowerShell-opdracht op het klembord van het slachtoffer plaatste en deze als een geplande taak vasthield. De door de aanvaller gecontroleerde hostnamen verschenen in waarschuwingen van de browsers van de slachtoffers, terwijl verschillende van die domeinen nog steeds als schoon werden beoordeeld door reguliere reputatiediensten. Geen enkele scanner had de pagina’s gemarkeerd, omdat ze op de server in orde waren.
U kunt beginnen met CSP zonder iets te blokkeren
Het veelgehoorde bezwaar is dat een Content Security Policy de site kapot zal maken, maar in de modus ‘Alleen rapporteren’ kan dat niet. Content-Security-Policy-Report-Alleen dwingt niets af, blokkeert niets en verandert geen gedrag, het rapporteert alleen wat een beleid is zou hebben geblokkeerd.
Hierdoor wordt de eerste implementatie een veilige meetoefening en kunt u alle benodigde gegevens verzamelen over welke code er op uw site wordt uitgevoerd. Voor de meeste organisaties is die lijst veel langer dan ze hadden verwacht.
Compliance heeft dit tot een verplichting gemaakt
Voor iedereen die kaartbetalingen op zijn site afhandelt, is dit argument al beslecht. PCI DSS v4.0.1-vereisten 6.4.3 en 11.6.1 zijn niet langer de beste praktijken en zijn verplicht geworden op 31 maart 2025. Samen vereisen ze dat elk script op een betaalpagina is geautoriseerd, dat de integriteit ervan is verzekerd, dat er een geschreven inventaris met zakelijke rechtvaardiging bestaat, en dat er een mechanisme is dat ongeoorloofde wijziging van de inhoud van de betaalpagina en HTTP-headers detecteert en waarschuwt.
Een QSA kan en zal vragen naar de inventaris, het waarschuwingsmechanisme en het bewijsspoor dat zij heeft voortgebracht. Rapport-URI kan u alle drie geven.
Hoe een werkende implementatie eruit ziet
- Implementeer en verzamel de eerste gegevens voor een week.
- Bouw uw inventaris op op basis van wat er is gerapporteerd.
- Houd wijzigingen in de loop van de tijd bij en keur deze wijzigingen goed of af.
Uit een tien jaar durende dagelijkse crawl van de top één miljoen sites blijkt dat de acceptatie van CSP in de afgelopen tien jaar met meer dan 12.000% is toegenomen, omdat organisaties zich de voordelen ervan realiseren. Deze groei weerspiegelt een bredere verschuiving in waar organisaties inzicht nodig hebben: niet alleen in wat ze implementeren, maar ook in welke code de browsers van hun gebruikers daadwerkelijk uitvoeren.
Waar rapport-URI past
Report URI is een beveiligingsplatform aan de clientzijde dat antwoord geeft op de vragen die een beveiligingsteam anders niet kan beantwoorden over de eigen site: welke derde partijen voeren code uit op uw pagina’s? Wat is er veranderd sinds gisteren? Welke nemen gegevens op of communiceren met infrastructuur waarvan bekend is dat deze vijandig is? De scripts die aan echte gebruikers worden aangeboden, worden gehasht en gearchiveerd, zodat wijzigingen achteraf kunnen worden geïdentificeerd en onderzocht. Hostnamen worden gecontroleerd aan de hand van bedreigingsinformatie en het beleid wordt gecontroleerd op afwijkingen, waardoor de kloof wordt gedicht tussen wat u heeft goedgekeurd en wat er daadwerkelijk op uw site wordt uitgevoerd.
Implementatie voegt geen JavaScript toe aan uw pagina en geen agent, module of SDK aan de stapel.
De eerste stap is eenvoudig: voeg een HTTP-antwoordheader toe en lees welke gegevens de komende 48 uur terugkomen. De lijst met dingen die code uitvoeren in de browsers van uw klanten is zelden de lijst die iemand had verwacht!
Start een gratis proefperiode van 30 dagen – geen creditcard vereist en geen codewijzigingen op de site.
