Was ist ein CSP-Header-Builder?
Content Security Policy (CSP) ist ein Browser-Sicherheitsstandard, der hilft, Cross-Site-Scripting (XSS), Clickjacking und andere Code-Injection-Angriffe zu verhindern, indem er definiert, welche Inhaltsquellen auf einer Webseite geladen werden dürfen. Ein CSP-Header-Builder bietet eine visuelle Benutzeroberfläche, um gültige CSP-Header-Strings zu erstellen, ohne die Direktive-Syntax auswendig zu lernen. Sie schalten Direktiven ein oder aus, wählen zulässige Quellwerte wie 'self', 'unsafe-inline' oder bestimmte Domänen aus, und das Tool generiert die richtige Kopfzeichenfolge in Echtzeit. Es warnt Sie auch vor widersprüchlichen oder unsicheren Konfigurationen, z. B. Der Kombination von 'unsafe-inline' mit 'strict-dynamic' oder der Verwendung von 'unsafe-eval', die gefährliche JavaScript-Ausführungen wieder aktiviert.
So verwenden Sie den CSP-Header-Builder
- 1Ermöglichen Sie die Richtlinien, die Sie benötigen, indem Sie sie umstellen. Beginnen Sie mit 'default-src' als Baseline-Fallback-Politik.
- 2Klicken Sie für jede aktivierte Direktive auf die Quellwerte, die Sie zulassen möchten (z. B. 'self', HTTPs:, data:). Ausgewählte Werte sind blau hervorgehoben.
- 3Hinzufügen benutzerdefinierter Domänen, indem Sie sie in das Eingabefeld eingeben und Enter drücken oder auf Hinzufügen klicken (z. B. HTTPs://cdn.example.com).)
- 4Überprüfen Sie alle gelben Warnungen, die erscheinen - sie zeigen widersprüchliche oder unsichere Richtlinienkombinationen an.
- 5Kopieren Sie den generierten CSP-Headerstring oder HTML-Meta-Tag mit den Kopierschaltflächen.
- 6Geben Sie optional einen Test URL ein, um zu überprüfen, ob er von Ihrer aktuellen Richtlinie zugelassen oder blockiert wird.
Häufige Anwendungsfälle
Härtung der Web Application Security
Erstellen Sie eine strikte CSP-Richtlinie für Ihre Produktionswebsite, um Inline-Skripte zu blockieren, die Herkunft von Ressourcen einzuschränken und XSS-Angriffe zu verhindern. Beginnen Sie mit einem restriktiven standardmäßigen src 'none' und erlauben Sie selektiv nur die Quellen, die Ihre Anwendung benötigt.
Migration zu CSP inkrementell
Wenn Sie CSP zu einer bestehenden Anwendung hinzufügen, experimentieren Sie mit verschiedenen Direktive-Kombinationen, ermitteln Sie, welche Quellen Ihre App benötigt, und verschärfen Sie die Richtlinie schrittweise, ohne die Funktionalität zu beeinträchtigen.
Debugging CSP Verstöße
Wenn Ihre Browserkonsole CSP-Verletzungsfehler anzeigt, verwenden Sie die Testfunktion URL, um zu überprüfen, ob eine bestimmte Ressource URL gemäß Ihrer aktuellen Richtlinie zulässig ist, und passen Sie die Richtlinien entsprechend an.
Meta-Tags für statische Sites generieren
Für statische Websites, die auf Plattformen gehostet werden, auf denen Sie keine HTTP-Header festlegen können, kopieren Sie das generierte HTML-Meta-Tag, um die CSP-Richtlinie direkt in den Kopfbereich Ihres HTML-Dokuments einzubetten.
Häufig gestellte Fragen
Was ist der Unterschied zwischen CSP als HTTP-Header und einem Meta-Tag?
Beide Methoden liefern dem Browser die gleiche Richtlinie. Der HTTP-Header (Content-Security-Policy) wird vom Server eingestellt und unterstützt alle Direktiven. Das HTML-Meta-Tag (meta HTTP-equiv Content-Security-Policy) ist in die Seite eingebettet und funktioniert für die meisten Direktiven, unterstützt jedoch keine Frame-Vorgänger, Report-uri oder Sandbox. Der HTTP-Header wird im Allgemeinen bevorzugt, da er angewendet wird, bevor die HTML-Seite analysiert wird.
Was macht 'strict-dynamic' und warum ignoriert es 'unsafe-inline'?
'strict-dynamic' weist den Browser an, Skripten zu vertrauen, die von bereits vertrauenswürdigen Skripten (über Nonce oder Hash) geladen werden, auch von neuen Ursprüngen. Wenn 'strict-dynamic' vorhanden ist, ignoriert der Browser 'unsafe-inline' und hostbasierte Allowlists für script-src. Dies ist durch Design - es ermöglicht einen nonce-basierten Ansatz, bei dem nur explizit nicht ced Skripte ausgeführt werden, und sie können dynamisch zusätzliche Skripte laden.
Sollte ich immer default-src setzen?
Ja, default-src fungiert als Ausweichgrund für jede Direktive, die Sie don't explicitly set. If you define script-src but not style-src, the browser uses default-src for styles. Setting default-src to 'none' or 'self 'erstellt eine sichere Basislinie, die Sie dann nach Bedarf pro Direktive entspannen.
Warum ist 'unsafe-eval' gefährlich?
'unsafe-eval' ermöglicht die Verwendung von eval(), new Function(), setTimeout mit Strings und anderen dynamischen Codeausführungen APIs. Dies sind gängige XSS-Angriffsvektoren, da ein Angreifer beliebiges JavaScript ausführen kann, wenn er einen String in Ihre Anwendung einfügen kann. Vermeiden Sie 'unsafe-eval', es sei denn, dies wird von Ihrem Framework oder Ihren Bibliotheken unbedingt verlangt.
Validiert dieses Tool den CSP-Header gegen die offizielle Spezifikation?
Dieses Tool generiert syntaktisch korrekte CSP-Header und warnt vor häufigen widersprüchlichen oder unsicheren Kombinationen. Es führt jedoch keine umfassende W3C-Spezifikationsvalidierung durch. Testen Sie Ihre CSP in einer Staging-Umgebung mit der Entwicklerkonsole des Browsers, um Verstöße zu erkennen.