CSP

CSP (Content Security Policy) ist ein HTTP-Antwort-Header, der Browsern mitteilt, welchen Inhaltsquellen die Seite vertraut. Definiert Whitelists pro Inhaltstyp: script-src für JavaScript, style-src für CSS, img-src für Bilder, connect-src für fetch/XHR/WebSocket, frame-src für iframes usw.

Beispiel-Header: Content-Security-Policy: default-src 'self'; script-src 'self' https://www.googletagmanager.com; img-src 'self' data: https:.

Der Hauptnutzen von CSP: Tiefenschutz (defence in depth) gegen XSS. Selbst wenn ein Angreifer JavaScript in Ihre Seite einschleust, verhindert eine strikte CSP, dass der Browser es ausführt (weil es aus einer Herkunft geladen wird, die nicht auf der Whitelist steht) oder Daten irgendwohin sendet (weil connect-src die Exfiltration zu Angreifer-Domains blockiert).

Moderne Best Practice: eine nonce-basierte CSP – jede Seitenantwort enthält eine zufällige Nonce in ihrem CSP-Header (z. B. script-src 'nonce-AbC123'), und Inline-Skript-Tags, die zu dieser Nonce passen, dürfen laufen. Das ist strikt, erlaubt aber das sichere Ausliefern dynamischer Inhalte. Statische Analyzer wie Googles CSP Evaluator bewerten Ihre Richtlinie und kennzeichnen Schwachstellen.

Häufige CSP-Fehler, die den Zweck untergraben: die Verwendung von 'unsafe-inline' in script-src (erlaubt erneut genau die Inline-Injektion, die Sie blockieren wollten), das Wildcarding von https: als Skriptquelle (jeder HTTPS-Host kann nun JS an Ihre Herkunft ausliefern) oder das Vertrauen in einen JSONP-fähigen CDN-Host, der es Angreifern erlaubt, eine URL zu basteln, die angreifergesteuertes JavaScript zurückgibt. Die Veröffentlichung „CSP Is Dead, Long Live CSP!“ des Google-Sicherheitsteams von 2016 zeigte, dass 95 % der in freier Wildbahn eingesetzten Richtlinien aus genau diesen Gründen trivial umgehbar waren; 'strict-dynamic' + Nonces war ihr Lösungsvorschlag und ist heute die Standardempfehlung.

CSP meldet Richtlinienverstöße an eine in report-uri (veraltet) oder report-to angegebene URL. Rollen Sie eine neue Richtlinie zuerst im Modus Content-Security-Policy-Report-Only aus – der Browser meldet dann Verstöße, ohne Inhalte zu blockieren, sodass Sie legitime Quellen vor der Durchsetzung korrigieren können. Verwandt: XSS, CORS, SRI (Subresource Integrity). Quelle: W3C CSP Level 3.

Ein durchgemessenes Beispiel: wie strict-dynamic funktioniert

Eine reale strikte Richtlinie sieht so aus: Content-Security-Policy: script-src 'nonce-r4nd0m' 'strict-dynamic' https:; object-src 'none'; base-uri 'none'. Der Server erzeugt pro Antwort eine frische 128-Bit-Nonce (typischerweise 22 base64url-Zeichen), bettet sie in passende <script nonce="r4nd0m">-Tags ein und gibt den Header aus. strict-dynamic überträgt Vertrauen transitiv: Skripte, die vom nonce-versehenen Skript geladen werden, können selbst weitere Skripte ohne explizite Whitelist laden, eingeschleuste nonce-lose Skripte im Seitenquelltext werden jedoch blockiert. Googles CSP Evaluator bewertet Richtlinien auf einer Skala von 0 bis 10; eine strict-dynamic-Richtlinie ohne 'unsafe-inline' und ohne Host-Wildcards erreicht 9+, während eine typische Altrichtlinie mit Wildcard-CDN-Quellen 1–3 erreicht. Dieselbe Google-Studie, die 1,6 Millionen Richtlinien über die Alexa Top Million abdeckte, fand, dass das Hinzufügen von strict-dynamic den per XSS umgehbaren Anteil von 95 % auf unter 5 % senkte.

Wie CSP mit Browserfunktionen interagiert

CSP blockiert mehr als nur die Skriptausführung. connect-src beschränkt fetch, XHR, WebSocket, EventSource und die Beacon-API – nützlich, um Datenexfiltration selbst nach einem erfolgreichen XSS zu stoppen. frame-ancestors ersetzt den älteren Header X-Frame-Options für den Clickjacking-Schutz. upgrade-insecure-requests schreibt HTTP-Subressourcen-URLs automatisch auf HTTPS um. require-trusted-types-for 'script' aktiviert für die Seite die Trusted-Types-API, die alle DOM-Sinks (innerHTML, eval usw.) zwingt, nur speziell typisierte Objekte zu akzeptieren, und so DOM-basiertes XSS an der Quelle blockiert. Moderne Browser senden Verstoßmeldungen als JSON an den report-to-Endpunkt, gebündelt über die Reporting-API. Quelle: Googles „CSP Is Dead, Long Live CSP!“ ACM CCS 2016 paper.