CSP- und Sicherheitsheader-Generator

Fügen Sie eine CSP ein oder erstellen Sie eine, prüfen Sie die Richtlinie und erzeugen Sie Header-Snippets für HTTP, Nginx oder Apache. Die Analyse läuft im Browser; nichts wird hochgeladen.

Läuft lokal in deinem Browser
Richtlinien-Editor

Fügen Sie eine vorhandene CSP zur Prüfung ein oder verwenden Sie den Generator rechts. Das Werkzeug analysiert ausschließlich den eingegebenen Text.

Richtlinien-Befunde
Fügen Sie eine CSP ein oder erstellen Sie eine und wählen Sie anschließend Richtlinie analysieren.
Schneller Richtlinien-Builder

Geben Sie Quellausdrücke ohne den Namen der Direktive ein. Lassen Sie ein Feld leer, um die Direktive wegzulassen.

Zusätzliche Response-Header

Verwenden Sie HSTS erst, wenn HTTPS für alle relevanten Subdomains korrekt eingerichtet ist. Gleichen Sie die erzeugten Werte mit den Anforderungen Ihrer Anwendung ab.

HTTP-Header
Build a CSP, then generate header snippets.
Nginx
Build a CSP, then generate header snippets.
Apache
Build a CSP, then generate header snippets.

Start restrictive, then observe and refine

Eine CSP muss zu den tatsächlich benötigten Ressourcen Ihrer Anwendung passen. Führen Sie sie vorsichtig ein, testen Sie zunächst report-only und kopieren Sie keine Richtlinie zwischen Websites, ohne Skripte, Frames, APIs und Drittanbieter-Assets zu prüfen.

Eine Content-Security-Policy erstellen, prüfen und exportieren

Diese Seite macht aus einer Content-Security-Policy drei verwertbare Dinge: eine Prüfung des eingegebenen Texts Direktive für Direktive, eine im Builder zusammengesetzte fertige Richtlinie und Header-Snippets zum Einfügen für Nginx oder Apache. Die Seite liest die Richtlinie als Text; sie ruft Ihre Website nicht auf.

Alles läuft im Tab, und keine Eingabe wird an VoriTools gesendet, sodass Sie auch eine noch nicht veröffentlichte Richtlinie prüfen können.

  1. Fügen Sie eine vorhandene Richtlinie in den Editor ein, oder füllen Sie die Builder-Felder rechts aus. Jedes Feld nimmt nur Quellausdrücke auf (zum Beispiel 'self' data: für img-src), und ein leeres Feld lässt die Direktive weg.
  2. Klicken Sie auf Richtlinie analysieren. Die Ergebnisliste zeigt zuerst strukturelle Probleme (eine doppelt angegebene Direktive, 'none' neben anderen Quellen) und danach Hinweise je Direktive für default-src, script-src, object-src, base-uri, frame-ancestors, form-action und upgrade-insecure-requests.
  3. Klicken Sie auf Startrichtlinie laden, um ein funktionierendes Beispiel zu sehen, und passen Sie die Werte an. Mit CSP erstellen wird die zusammengesetzte Richtlinie zurück in den Editor geschrieben und sofort analysiert.
  4. Aktivieren Sie die gewünschten Zusatz-Header (X-Content-Type-Options, Referrer-Policy, Permissions-Policy und HSTS, sofern HTTPS vollständig ausgerollt ist) und klicken Sie auf Server-Snippets erzeugen.
  5. Kopieren Sie die Richtlinie über CSP kopieren und jedes der drei Formate (HTTP, Nginx oder Apache) über die jeweilige Kopieren-Schaltfläche.

Wie die Analyse eine Richtlinie liest und was die Snippets abdecken

Wie die Analyse eine Richtlinie liest

Der Text wird an Semikola getrennt, und jede Direktive wird als Name mit anschließender Quellenliste gelesen. Bei Direktivennamen spielt die Großschreibung keine Rolle; alles andere wird so verglichen, wie es geschrieben steht. Zuerst kommen zwei strukturelle Prüfungen, weil der Browser sie selbst entscheidet und dabei selten so, wie es beim Schreiben der Richtlinie erwartet wird: Steht eine Direktive zweimal in der Richtlinie, gilt der erste Wert, spätere Wiederholungen werden ignoriert. Steht 'none' neben anderen Quellen, wird 'none' ignoriert statt durchgesetzt.

Die Prüfung ist eine Heuristik, kein Validator. Sie markiert, was Richtlinien in der Praxis am häufigsten schwächt (fehlendes default-src, 'unsafe-inline' oder 'unsafe-eval' in script-src, eine Wildcard- oder data:-Quelle für Skripte sowie fehlendes object-src, base-uri, frame-ancestors oder form-action), doch eine vollständige Richtlinie kann für Ihre Anwendung trotzdem falsch sein, und eine hier beanstandete kann korrekt sein.

Was die erzeugten Snippets enthalten

Alle drei Ausgaben tragen dieselben Header: den von Ihnen geschriebenen Content-Security-Policy-Wert plus die vier optionalen Header, die Sie angekreuzt haben. Die HTTP-Ansicht zeigt Name: Wert-Zeilen; die Nginx-Ansicht hüllt jeden Header in add_header ... always;, damit er auch auf Fehlerantworten gesendet wird; die Apache-Ansicht nutzt Header always set ... . Anführungszeichen und Backslashes innerhalb der Richtlinie werden für die Ziel-Syntax maskiert.

Die optionalen Header sind feste Vorgaben: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy: camera=(), geolocation=(), microphone=() und Strict-Transport-Security: max-age=63072000; includeSubDomains. Prüfen Sie jeden Wert gegen Ihre Anforderungen; HSTS bindet den Browser für die angegebene max-age an HTTPS, nehmen Sie ihn also nur auf, wenn alle betroffenen Subdomains bereit sind.

Was im Browser geprüft werden muss

Eine CSP wirkt in echten Antworten, nicht in diesem Editor. Eine hier streng wirkende Direktive kann ein Bezahlskript, eine Schriftart oder einen Inline-Stil brechen, den die Anwendung braucht, und die Browserkonsole nennt genau die blockierte Quelle. Rollen Sie eine neue Richtlinie zuerst mit Content-Security-Policy-Report-Only in einer Testumgebung aus, setzen Sie sie dann durch und beobachten Sie die Berichte weiter.

Die Snippets sind Ausgangspunkte für Ihre Serverkonfiguration, kein Ersatz dafür. Ob ein Header beim Client ankommt, hängt vom Webserver, von vorgeschalteten CDNs oder Proxys und vom Antwortpfad ab; kontrollieren Sie die echten Antwort-Header nach dem Deployment im Netzwerk-Panel des Browsers oder mit einem Kommandozeilen-Client.

Zuletzt verwendet: