CSP-Header-Validator

Fügen Sie den Wert eines Content-Security-Policy-Headers ein, um dessen Direktiven und Quellwerte in einem Durchgang zu validieren. Erkennt riskante Einstellungen wie unsafe-inline, ein fehlendes default-src als Fallback sowie Tippfehler in Direktivennamen und zeigt in einer visuellen Übersicht die erlaubten Quellen jeder Direktive.

Zuletzt aktualisiert: 2026-09-20

Den Inhalt eines CSP-Kopfzeilenwerts prüfen

Eine Content-Security-Policy ist eine einzige lange, durch Semikola getrennte Zeichenkette, und sie bloß mit dem Auge zu verfolgen lässt das Bedenkliche leicht übersehen. Dieses Werkzeug nimmt den eingefügten Wert, zerlegt ihn in Direktiven und Quellen, bringt gefährliche Einstellungen, fehlende Angaben und Schreibfehler ans Licht und legt dar, was jede Direktive tatsächlich zulässt.

**Eine falsch geschriebene Direktive ist von allem der tückischste Fall.** Browser übergehen Direktiven, die sie nicht kennen, stillschweigend, sodass `scipt-src` statt `script-src` **keinerlei Fehler auslöst, während jener Teil der Richtlinie fortwährend gar nichts tut.** Ebenso leicht zu übersehen ist das Fehlen von `default-src`: Ohne sie bleibt jede nicht ausdrücklich genannte Direktive unbeschränkt und in der Abwehr klafft eine Lücke. Und `unsafe-inline` in script-src aufzunehmen **hebt das Blockieren eingebetteter Skripte, den Hauptgrund für die Einführung von CSP, nahezu vollständig auf.**

So gehen Sie vor

Fügen Sie den Wert der CSP-Kopfzeile ein Geben Sie eine Zeichenkette der Form `default-src 'self'; script-src ...` unverändert ein.
Probieren Sie zuerst die Beispiele Ein gutes und ein schlechtes Beispiel liegen bereit, sodass Sie die Unterschiede im Urteil vorab sehen können.
Lesen Sie die genannten Punkte **`unsafe-inline`, ein fehlendes `default-src` und Schreibfehler werden allesamt benannt.**
Sehen Sie die je Direktive erlaubten Quellen durch Auf einen Blick erkennen Sie, von wo geladen werden darf.

Tipps für die Nutzung

CSP wird normalerweise als HTTP-Antwort-Header ausgeliefert, kann aber auch über ein <meta http-equiv="Content-Security-Policy">-Tag gesetzt werden (Direktiven wie report-uri haben dort allerdings keine Wirkung).
Bevor Sie CSP produktiv ausrollen, probieren Sie zunächst den Header Content-Security-Policy-Report-Only aus — er sammelt nur Verstoßberichte, sodass Sie die Auswirkungen auf bestehende Funktionen einschätzen können, ohne etwas zu beschädigen.
Platzhalter (*) und 'unsafe-inline' erleichtern die Entwicklung, untergraben aber einen Großteil des XSS-Schutzes von CSP. Verschärfen Sie eine lockere Richtlinie immer, bevor Sie sie produktiv einsetzen.
Dieselbe Direktive zweimal zu wiederholen führt nicht zu einer Zusammenführung der Werte — nur das erste Vorkommen greift. Um Quellen hinzuzufügen oder zu überschreiben, halten Sie alles in einer einzigen Direktive.
Die DevTools-Konsole Ihres Browsers zeigt blockierte Ressourcen als rote „Refused to load...“-Meldung an, weshalb sie beim Debuggen einer zu strengen CSP der erste Anlaufpunkt ist.

Wofür Sie es nutzen können

Beim erstmaligen Einführen einer CSP

Sie können bestätigen, dass die geschriebene Richtlinie das Gemeinte tut, lange bevor sie in die Nähe des Wirkbetriebs gelangt.

Beim Sichten einer bestehenden Richtlinie

**Eine im Lauf der Zeit angewachsene Richtlinie behält gern Freigaben für Domänen, die niemand mehr nutzt.**

Beim Umstellen vom Berichtsmodus auf Durchsetzung

Ein unter `Content-Security-Policy-Report-Only` erprobter Wert lässt sich prüfen, bevor er durchgesetzt wird.

Als Hilfe bei einer Quelltextdurchsicht

Fügen Sie die geänderte Richtlinie ein und bestätigen Sie, dass sie nicht schwächer geworden ist.

Begriffe zu CSP

Direktive: Ein Eintrag wie `script-src` oder `img-src`, der **angibt, von wo eine bestimmte Art von Ressource geladen werden darf.**
Default-src: Der Rückfallwert für jede nicht einzeln genannte Direktive. **Lässt man sie weg, bleibt jede nicht ausdrücklich genannte Art unbeschränkt.**
'self': Ein Quellausdruck, der allein das Laden aus demselben Ursprung zulässt.
'unsafe-inline': Ein Quellausdruck, der unmittelbar ins HTML geschriebene Skripte und Stile zulässt. **Er gibt die Abwehr gegen XSS nahezu gänzlich preis, weshalb ein Ersatz durch nonce oder Hash angeraten ist.**
Nonce: Ein Verfahren, das einen einmalig verwendeten Zufallswert sowohl in das Skript-Element als auch in die Richtlinie schreibt, damit beide einander entsprechen. Es ist der sichere Weg, eingebetteten Code zuzulassen.
Frame-ancestors: Eine Direktive, die benennt, wer Ihre Seite in einen Rahmen einbetten darf. **Sie ist die Nachfolgerin von X-Frame-Options.**

Häufige Fragen

CSP teilt dem Browser genau mit, welche Quellen Skripte, Bilder, Stile und andere Ressourcen der Seite liefern dürfen. Alles, was nicht auf der Positivliste steht — einschließlich Inline-Skripte — wird am Laden oder Ausführen gehindert, was das Risiko drastisch senkt, dass ein XSS-Angriff ein vom Angreifer kontrolliertes Skript ausführt.

Ja — sowohl Nonce-Quellen ('nonce-') als auch Hash-Quellen ('sha256-') funktionieren. Indem Sie einem Script-Tag ein Nonce-Attribut hinzufügen, das mit dem Wert im Antwort-Header übereinstimmt, können Sie genau dieses Tag erlauben und gleichzeitig jedes andere, nicht autorisierte Inline-Skript weiterhin blockieren.

CSP hat eine Ressource blockiert, weil ihr Ursprung nicht auf der Positivliste stand. Die Browser-Konsole zeigt eine Meldung wie „Refused to load...because it violates the following Content Security Policy directive“, die den genauen Ursprung nennt — fügen Sie diesen Ursprung zur Positivliste der entsprechenden Direktive hinzu, um das Problem zu beheben.

In der Regel nicht. default-src dient nur als Fallback für Direktiven, die Sie nicht explizit gesetzt haben. Risikoreiche Direktiven wie script-src und object-src sollten jeweils explizit und streng konfiguriert werden, da sie eine deutlich größere Angriffsfläche darstellen als die meisten anderen Direktiven.

Beide legen fest, wohin der Browser Verstoßberichte senden soll, aber report-uri ist die ältere Direktive, die direkt auf eine Berichts-URL verweist. report-to basiert auf der neueren Reporting API und verweist stattdessen auf eine benannte Gruppe, die in einem separaten Report-To-Header definiert ist. Da die Browser-Unterstützung für beide unterschiedlich ist, werden aus Kompatibilitätsgründen häufig beide gemeinsam angegeben.

Übrigens – Warum es CSP überhaupt gibt: Escaping allein reichte nie aus, um XSS zu stoppen

Content Security Policy geht auf eine Idee zurück, die Robert Hansen um 2004 in den Raum stellte und die der Mozilla-Ingenieur Brandon Sterne ab etwa 2008 zu einer formalen Spezifikation ausarbeitete, was 2012 zur ersten W3C Candidate Recommendation (Level 1) führte. Cross-Site-Scripting (XSS) galt damals als eine der drängendsten Web-Schwachstellen, und es wurde klar, dass sich allein auf die Sorgfalt der Entwickler zu verlassen – „jede Ausgabe korrekt escapen“ – keine robuste Verteidigung war. CSP wurde als Mechanismus für gestaffelte Verteidigung entworfen, der es dem Browser selbst erlaubt, Beschränkungen darüber durchzusetzen, woher Skripte stammen dürfen.

CSP Level 2 führte Nonce- und Hash-basierte Freigaben für Inline-Skripte ein, sodass Websites bestimmten Inline-Code erlauben konnten, ohne auf 'unsafe-inline' zurückzugreifen. Level 3 fügte anschließend 'strict-dynamic' hinzu, das Skripten, die von einem bereits vertrauenswürdigen Skript dynamisch nachgeladen werden, automatisch vertraut und so den Pflegeaufwand host-basierter Positivlisten bei großen Websites drastisch senkt.

Google setzt in seinen eigenen groß angelegten Diensten kontinuierlich strikte, Nonce-basierte CSP ein und hat aus dieser Arbeit Forschungsergebnisse veröffentlicht, wonach host-basierte Positivlisten häufig umgangen werden können, während Nonce- oder Hash-basierte Richtlinien in der Praxis deutlich wirksamer sind. Dieser Befund wird heute vielfach als CSP-Best-Practice zitiert und unterstreicht, dass die eigentliche Designentscheidung nicht nur lautet, „welche Werte verboten werden“, sondern von vornherein, „auf welcher Whitelisting-Strategie überhaupt aufgebaut wird“.

Alle Wissenstexte ansehen