CSP-Generator (Content Security Policy)

So erstellen Sie eine Richtlinie

1. Wählen Sie unter Mit einer Vorlage starten einen Ausgangspunkt: Strikt (Nonce + strict-dynamic), Abgeschottete statische Website, Typische Website oder Typisch + Google Analytics / Ads. Beim Öffnen ist die Vorlage „Typische Website“ geladen.
2. Passen Sie die Direktiven an. Jedes Feld nimmt durch Leerzeichen getrennte Quellen auf; ein leeres Feld lässt die Direktive weg.
3. Mit Schnell hinzufügen hängen Sie ein Schlüsselwort an die gewählte Direktive an: 'self', 'none', 'unsafe-inline', 'strict-dynamic', https:, data: … Nonce hinzufügen fügt eine zufällige 128-Bit-Nonce ein.
4. Um ein bestimmtes Inline-Script ohne 'unsafe-inline' zu erlauben, fügen Sie es (oder das umgebende HTML) unter Hash für ein Inline-Script oder einen Inline-Style ein und klicken auf SHA-256 berechnen und hinzufügen.
5. Aktivieren Sie upgrade-insecure-requests, wenn einige alte URLs noch http:// verwenden, und tragen Sie bei Bedarf eine URL des Report-Endpunkts ein.
6. Kopieren Sie den HTTP-Header, den Report-Only-Header oder das HTML--Tag. Die Prüfung dieser Richtlinie aktualisiert sich während der Eingabe.

Um eine vorhandene Richtlinie zu prüfen, fügen Sie sie unter Bestehende Richtlinie prüfen ein und klicken auf Richtlinie prüfen; In den Editor laden überträgt sie in die Felder. Alles läuft lokal in Ihrem Browser.

Was eine Content Security Policy leistet

Eine CSP teilt dem Browser mit, von welchen Ursprüngen eine Seite Scripts, Styles, Bilder, Schriften, Frames und Verbindungen laden darf. Ihre Hauptaufgabe ist es, Cross-Site-Scripting (XSS) einzudämmen: Selbst wenn ein Angreifer Markup in Ihre Seite einschleust, verhindert eine gute Richtlinie, dass das eingeschleuste Script ausgeführt wird. Außerdem legt sie fest, wer Ihre Seite in einen Frame laden darf (frame-ancestors), wohin Formulare senden dürfen (form-action) und worauf <base> zeigen darf (base-uri).

Fetch-Direktiven wie img-src oder font-src greifen auf default-src zurück, wenn sie fehlen. base-uri, form-action und frame-ancestors haben keinen solchen Fallback – deshalb fordert die Prüfung sie ausdrücklich an.

Nonces, Hashes und strict-dynamic

Hosts freizugeben (script-src https://cdn.example.com) wirkt sicher, lässt sich aber oft umgehen: Große Domains hosten JSONP-Endpunkte und alte Bibliotheken, die ein Angreifer wiederverwenden kann. Die von den Sicherheitsteams der Browserhersteller empfohlene Methode ist eine strikte CSP: Jedes legitime <script> trägt eine Nonce, die der Server für jede Antwort neu erzeugt, oder wird über seinen Hash erlaubt, und 'strict-dynamic' erlaubt diesen vertrauenswürdigen Scripts, weitere benötigte Scripts nachzuladen. In dieser Konstellation sind https: und 'unsafe-inline' nur Fallbacks für sehr alte Browser; moderne Browser ignorieren sie.

Eine Nonce wirkt nur, wenn sie sich bei jeder Antwort ändert und nicht vorhersagbar ist. Die über Nonce hinzufügen eingefügte Nonce ist ein Beispiel: Ihr Server oder Framework muss seine eigene erzeugen. Ein Hash deckt exakt die Bytes des Inline-Codes ab – wird das Script umformatiert, brauchen Sie einen neuen Hash.

Header, Report-Only und Meta-Tag

Senden Sie die Richtlinie wann immer möglich als HTTP-Antwort-Header. Setzen Sie sie zunächst als Content-Security-Policy-Report-Only ein: Browser melden Verstöße (in der Konsole und, falls angegeben, an Ihren Endpunkt), ohne etwas zu blockieren. So können Sie Ihre Seiten korrigieren, bevor Sie die Richtlinie scharf schalten. Die Report-Einstellungen fügen report-uri für ältere Browser sowie report-to mit einem Reporting-Endpoints-Header hinzu.

Die Variante mit <meta http-equiv> ist praktisch bei statischem Hosting, doch Browser ignorieren darin frame-ancestors, report-uri, report-to und sandbox, und ein Report-Only-Meta-Tag gibt es nicht. Das Tool entfernt diese Direktiven aus dem Tag und weist darauf hin.