Beide Fälle teilen ein Problem, für das die meisten Sicherheitsteams keine Kontrolle besitzen: Der schädliche Code lag nie auf dem eigenen Server, und er kam lange nach dem letzten Deployment hinzu.
Statische Analyse, Dependency-Scanning und Software Composition Analysis prüfen, was eine Organisation baut und ausliefert. Ein Drittanbieter-Script ist nichts davon. Es wird vom Browser des Besuchers geladen, von einem Server, den die Organisation weder betreibt noch kontrolliert, und zwar bei jedem einzelnen Seitenaufruf.
Das macht solche Einbindungen für klassische Tests besonders schwer greifbar, weil die Antwort je nach Region, User-Agent, Referrer, Tageszeit und Sitzung variieren kann. Ein Crawler, der die Datei einmal aus einem Rechenzentrums-IP-Bereich abruft, bekommt eine saubere Version; die Kundin im Mobilfunknetz eines anderen Landes möglicherweise etwas Bösartiges.
Dabei besitzt das fremde Script dieselben Rechte wie der eigene Code: Es kann das DOM auslesen, Formularfelder Zeichen für Zeichen beim Tippen mitlesen, auf Cookies und Local Storage zugreifen und Anfragen an beliebige Ziele senden. Clientseitige Angriffe vom Typ Magecart brauchen gar keinen Server-Einbruch – es genügt, dass ein einmal freigegebenes Script-Tag sein Verhalten ändert.
Es gibt jedoch einen Beobachter, der bei jedem dieser Seitenaufrufe zuverlässig anwesend ist: der Browser, der den Code ausgeführt hat. Content Security Policy wird meist als Schutz gegen Cross-Site-Scripting diskutiert, und dafür taugt sie gut. Ihre zweite Funktion ist für Teams, die noch gar nicht wissen, welchen Code sie ausführen, allerdings nützlicher: Eine CSP kann festlegen, welcher Code auf der eigenen Website laufen darf, nicht autorisierten Code blockieren und melden, wenn das geschieht. Diese Meldungen stammen aus echten Sitzungen, echten Regionen und von echten Geräten realer Nutzer. Eine Schadroutine, die nur für eingeloggte Besucher in einem einzigen Land zündet, wird trotzdem gemeldet – weil der ausführende Browser selbst die Meldung verschickt.
Laut Report URI förderten solche Meldungen im September 2026 eine Gruppe kompromittierter E-Commerce-Seiten zutage, auf denen eine Social-Engineering-Kampagne der „ClickFix"-Familie lief. Nach einer Kompromittierung von Administrationszugängen waren Base64-kodierte Loader in CMS-Inhalte eingeschleust worden. Über einen Redirector führte die Kette zu einer gefälschten „Bestätigen Sie, dass Sie ein Mensch sind"-Überlagerung, die einen PowerShell-Befehl in die Zwischenablage des Opfers legte und als geplante Aufgabe persistierte. Die vom Angreifer kontrollierten Hostnamen tauchten in den Meldungen der Opfer-Browser auf, während mehrere dieser Domains von gängigen Reputationsdiensten noch als unbedenklich eingestuft wurden. Kein Scanner hatte die Seiten markiert, denn serverseitig war alles in Ordnung.
Dem häufigen Einwand, eine CSP zerschieße die Website, begegnet der Report-Only-Modus: Content-Security-Policy-Report-Only erzwingt nichts, blockiert nichts und ändert kein Verhalten – es meldet nur, was eine Policy blockiert hätte. Der erste Rollout wird damit zur risikofreien Messung; die resultierende Liste ist bei den meisten Organisationen deutlich länger als erwartet.
Wer Kartenzahlungen abwickelt, hat ohnehin keine Wahl mehr: Die Anforderungen 6.4.3 und 11.6.1 aus PCI DSS v4.0.1 sind seit dem 31. März 2025 verpflichtend. Sie verlangen, dass jedes Script auf einer Zahlungsseite autorisiert ist, seine Integrität sichergestellt wird, ein schriftliches Inventar mit geschäftlicher Begründung existiert und ein Mechanismus unautorisierte Änderungen an Inhalten und HTTP-Headern der Zahlungsseite erkennt und meldet. Ein QSA wird Inventar, Alarmierungsmechanismus und Nachweiskette einfordern.
Ein zehnjähriger täglicher Crawl der eine Million meistbesuchten Websites zeigt ein Wachstum der CSP-Verbreitung von mehr als 12.000 Prozent über das Jahrzehnt.