CSP-Header-Generator

Erstelle einen Content-Security-Policy-Header für Skripte, Styles, Bilder, APIs, Frames und mehr. Nutze eine Vorlage, prüfe Quellen und kopiere das Ergebnis.

Mit Vorlage starten

Wähle eine Ausgangsbasis und passe danach jede Direktive an die tatsächlich verwendeten Ressourcen deiner Website an.

Header & Berichte

Setze die Richtlinie sofort durch oder konfiguriere vor der Einführung moderne Verstoßberichte.

Erzeugt report-to und den erforderlichen Reporting-Endpoints-Response-Header. HTTPS ist erforderlich.

Verknüpft die report-to-Direktive mit dem benannten Reporting-Endpoints-Eintrag.

Ressourcen-Direktiven

Gib durch Leerzeichen getrennte Quellausdrücke wie 'self', https: oder https://cdn.example.com ein.

Dokumentschutz

Beschränke Plug-ins, Basis-URLs, Formularziele und Websites, die diese Seite einbetten dürfen.

Generierte Security-Header

Kopiere diese Response-Header in deine Server- oder Hosting-Konfiguration.
Content-Security-Policy: default-src 'none'; script-src 'self'; style-src 'self'; img-src 'self' data:; font-src 'self'; connect-src 'self'; media-src 'self'; frame-src 'none'; worker-src 'self'; object-src 'none'; base-uri 'none'; form-action 'self'; frame-ancestors 'none'; upgrade-insecure-requests

Keine üblichen Schwachstellen erkannt

Der Generator hat keine offensichtlichen riskanten Einstellungen gefunden. Teste die Richtlinie vor dem Einsatz mit deiner vollständigen Anwendung.


Weitere Entwickler-Tools


Einen Content-Security-Policy-Header erstellen

Mit diesem CSP-Header-Generator legst du fest, welche Skripte, Styles, Bilder, Schriften, API-Verbindungen, Frames und anderen Ressourcen ein Browser laden darf. Wähle eine passende Vorlage, passe die Quellausdrücke an und kopiere einen vollständigen Content-Security-Policy- oder Content-Security-Policy-Report-Only-Response-Header. Alle Eingaben bleiben in deinem Browser.

Was bewirkt eine Content Security Policy?

Eine Content Security Policy beschränkt die Origins, von denen eine Seite Inhalte laden oder ausführen darf. Eine sorgfältig getestete CSP ergänzt den Schutz vor Cross-Site-Scripting, manipulierten Drittanbieter-Ressourcen, unerwünschtem Framing und weiteren Injection-Risiken. Sie ist eine zusätzliche Schutzebene und ersetzt weder sichere Ausgabekodierung noch Eingabevalidierung.

Welche CSP-Vorlage sollte ich wählen?

Wähle Standardmäßig blockieren für eine restriktive Ausgangsbasis, die wichtige Ressourcenarten einzeln aufführt. Selbst gehostet eignet sich für Websites, die fast alle Inhalte von der eigenen Origin laden. Web-App erlaubt zusätzlich typische HTTPS-APIs, WebSockets, Frames, Data-URLs und Blob-Worker. Jede Vorlage ist nur ein Startpunkt. Entferne alle Freigaben, die deine Anwendung nicht benötigt.

Wie füge ich ein CDN, eine API oder einen WebSocket-Endpunkt hinzu?

Trage durch Leerzeichen getrennte Quellausdrücke in die passende Direktive ein. Ergänze zum Beispiel https://cdn.example.com in script-src, https://api.example.com in connect-src oder wss://socket.example.com für einen WebSocket-Server. Vermeide breite Schemafreigaben wie https:, wenn ein bestimmter vertrauenswürdiger Host ausreicht.

Sollte ich zuerst den CSP-Berichtsmodus verwenden?

Der Berichtsmodus hilft bei der Einführung einer Richtlinie auf einer bestehenden Website, weil er Verstöße meldet, ohne Ressourcen zu blockieren. Hinterlege einen HTTPS-Berichts-Endpunkt. Der Generator erzeugt dann die report-to-Direktive und den erforderlichen Reporting-Endpoints-Response-Header. Optional ergänzt er die veraltete report-uri-Direktive als Kompatibilitäts-Fallback für ältere Browser. Prüfe echten Datenverkehr und schränke die Quellen weiter ein, bevor du zum durchsetzenden Header wechselst. Der Berichtsmodus schafft Transparenz, bietet allein aber keinen Schutz.

Warum warnt der Generator vor unsafe-inline und unsafe-eval?

'unsafe-inline' erlaubt Inline-Skripte oder Inline-Styles. 'unsafe-eval' erlaubt JavaScript-APIs, die Strings als Code ausführen. Beide Freigaben können wichtige CSP-Schutzmechanismen schwächen. Nutze für Skripte besser einen pro Response neu erzeugten, nicht vorhersagbaren Nonce oder einen Inhalts-Hash und teste die Umstellung gründlich.

Was schützen object-src, base-uri und frame-ancestors?

object-src 'none' blockiert ältere Plug-in-Inhalte, base-uri beschränkt URLs im <base>-Element und frame-ancestors legt fest, welche Websites die Seite einbetten dürfen. Diese Direktiven verwenden nicht alle default-src als Fallback. Eine ausdrückliche Angabe schließt deshalb Lücken, die eine sehr kurze Richtlinie offenlassen kann.

Wie setze und teste ich den erzeugten CSP-Header?

Füge die generierte Zeile als HTTP-Response-Header in deinen Webserver, dein Framework, deinen Reverse Proxy oder deine Hosting-Plattform ein. Für verwandte Serverkonfigurationen hilft der Nginx-Redirect-Generator. Teste jede Seite und jeden wichtigen Ablauf, prüfe CSP-Verstöße in der Entwicklerkonsole und kontrolliere insbesondere Anmeldung, Zahlungen, Medien, Analytics und eingebettete Inhalte, bevor du die Richtlinie produktiv durchsetzt.

Kann eine CSP jede XSS-Schwachstelle verhindern?

Nein. Eine CSP ist eine zusätzliche Schutzschicht, die die Folgen vieler Injection-Fehler begrenzen kann. Die Anwendung braucht weiterhin sichere Templates, kontextgerechte Ausgabekodierung, vertrauenswürdige Abhängigkeiten und sorgfältige Validierung. Für angrenzende Aufgaben kannst du den JWT-Analyzer & -Decoder oder den Regex-Tester nutzen, ohne ein einzelnes Tool mit einem vollständigen Sicherheitsaudit gleichzusetzen.

Tool-Navigation

Schnell zu einem beliebigen Tool wechseln