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.

Tipps

  • 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.

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“.

→ Verwandte Wissenstexte lesen

→ Alle Wissenstexte ansehen

Weitere Tools in dieser Kategorie