Skip to main content

CSP Header Generator

Build Content-Security-Policy headers with a visual form, presets and per-directive configuration.

Geprüft von · Zuletzt geprüft

Presets:

Verwendung des CSP-Header-Generators

  1. Wähle eine Voreinstellung - "Streng" sperrt alles auf 'self' plus erforderliche Nonces, "Moderat" fügt https:-Quellen und gängige Analytics-Domains hinzu, "Report-Only" gibt einen Content-Security-Policy-Report-Only-Header aus, der Verstöße protokolliert, ohne sie zu blockieren.
  2. Passe Pro-Direktiven-Quellen an - jede Direktive (default-src, script-src, style-src, img-src, connect-src, frame-src, font-src, media-src, worker-src) hat eine Liste von Quellen, die du hinzufügen oder entfernen kannst. Gängige Werte ('self', 'none', https:, data:, spezifische Ursprünge) erscheinen als Ein-Klick-Hinzufügungen.
  3. Füge Nonces oder Hashes hinzu - für Inline-Skripte oder -Stile, die du nicht refaktorieren kannst, füge einen Nonce-Platzhalter ('nonce-{RANDOM}') oder einen Hash ('sha256-HASH') hinzu und denke daran, einen frischen Nonce pro Antwort serverseitig zu generieren.
  4. Aktiviere strict-dynamic - eingeschaltet, erlaubt es Skripten, die von vertrauenswürdigen Skripten geladen werden, auch ohne jeden CDN-Ursprung einzeln aufzulisten auszuführen. Das ist der moderne CSP-Level-3-Ansatz.
  5. Kopiere den Header - die Ausgabe ist ein einzeiliger Content-Security-Policy-Wert. Füge ihn in deine Webserver-Konfiguration ein (Nginx add_header, Apache Header set, Cloudflare Workers, Netlify _headers oder ein Meta-Tag als letztes Mittel).

Was CSP tatsächlich tut

Content Security Policy ist ein HTTP-Antwort-Header, der in W3C CSP Level 3 (Working Draft, mit Level 2 im Empfehlungsstatus) spezifiziert ist. Wenn der Browser eine Seite mit einem Content-Security-Policy-Header empfängt, erzwingt er eine Whitelist bei der Ressourcenlade-Zeit: Skriptquellen, Stilquellen, Bildquellen, Frame-Vorfahren, Verbindungsendpunkte und mehr. Verstöße lösen ein SecurityPolicyViolationEvent im DOM der Seite aus und senden optional einen Verstoßbericht an die URL, die in report-uri (Level 2) oder report-to (Level 3) angegeben ist.

Der Sicherheitswert ist XSS-Minderung. Eine gut konfigurierte CSP macht Inline-Skripte (<script>alert(1)</script>) nicht ausführbar und blockiert Skriptladungen von von Angreifern kontrollierten Domains, sodass selbst wenn eine Markup-Injektionsvulnerabilität vorhanden ist, der Angreifer kein JavaScript ausführen kann. Die MDN-CSP-Dokumentation und die W3C-Spezifikation unter w3.org/TR/CSP3/ dokumentieren die Direktivengrammatik im Detail; der Trick besteht darin, eine Richtlinie zu schreiben, die nicht vertrauenswürdige Inhalte sperrt, ohne deine eigene Anwendung zu brechen.

Reale CSP-Deployment-Szenarien

  • Eine Marketing-Website gegen XSS aus nutzergenerierten Inhalten (Kommentare, Testimonial-Widgets) härten - CSP ist die letzte Verteidigungslinie, wenn die Eingabesanitisierung versagt.
  • Compliance-Anforderungen erfüllen (PCI DSS 4.0 schreibt seit März 2025 explizit CSP für Zahlungsseiten vor; SOC-2-Checklisten schließen es routinemäßig ein).
  • Gegen Supply-Chain-Angriffe auf Drittanbieter-Skripte schützen - mit einem strikten script-src kann ein kompromittiertes NPM-Paket, das von einem CDN bereitgestellt wird, keine Daten an eine Angreifer-Domain exfiltrieren.
  • Ad-Injektionen durch ISPs oder Browser-Erweiterungen blockieren, die Skripte in die Seiten, die sie bereitstellen, injizieren.
  • iFrame-Einbetten (frame-ancestors) sperren, um Clickjacking-Angriffe auf deiner Website und ihren Subdomains zu verhindern.

CSP-Fallstricke, die Websites brechen

  • Inline-Skripte ohne Nonces - Legacy-Vorlagen haben oft <script>...</script>-Blöcke, die unter striktem script-src 'self' brechen. Füge pro Antwort einen Nonce hinzu oder refaktoriere zu externen Skripten.
  • Inline-Event-Handler - onclick="tuEtwas()" in HTML ist standardmäßig blockiert. Wechsle zu addEventListener in einer separaten Datei.
  • Drittanbieter-Skripte, die mehr Skripte laden - Google Tag Manager, Hotjar, Intercom und ähnliche laden zur Laufzeit zusätzliche Skripte. Ohne strict-dynamic müssen alle sekundären Ursprünge aufgelistet werden, was brüchig ist.
  • Google AdSense und Analytics - AdSense benötigt pagead2.googlesyndication.com, googleads.g.doubleclick.net und mehrere Bild-Domains in script-src, frame-src, connect-src und img-src. GA4 benötigt *.google-analytics.com in script-src und connect-src. Google veröffentlicht die Liste in seiner Ad-Manager- und Analytics-Dokumentation.
  • Service Worker - in CSP Level 3 durch worker-src gesteuert, zuvor durch script-src. Nichtübereinstimmungen zwischen den beiden Levels verursachen stille Fehler.
  • Report-Only-Richtlinien, die nie erzwungen werden - Teams deployen Content-Security-Policy-Report-Only zum Sammeln von Daten, vergessen dann, auf erzwungenes Content-Security-Policy zu migrieren. Berichte ohne Erzwingung bieten Telemetrie, aber keinen tatsächlichen Schutz.
  • Meta-Tag-CSP vs. Header-CSP - <meta http-equiv="Content-Security-Policy"> funktioniert für einige Direktiven, aber nicht für frame-ancestors, report-uri oder sandbox. Server-Header werden immer bevorzugt.

CSP Level 3 und moderne Best Practices

Der W3C-CSP-Level-3-Entwurf führt mehrere Funktionen über Level 2 hinaus ein. strict-dynamic weist den Browser an, dass ein von einem vertrauenswürdigen Skript geladenes Skript auch vertrauenswürdig ist, ohne jeden CDN aufzulisten. unsafe-hashes erlaubt spezifische Inline-Event-Handler basierend auf SHA-Hash. report-to ersetzt report-uri durch eine flexiblere Reporting-API. Googles CSP-Evaluator unter csp-evaluator.withgoogle.com bewertet Richtlinien gegen bekannte Bypass-Muster. Forschungen von Google zeigten, dass whitelist-basierte CSPs aufgrund von JSONP-Endpunkten auf vertrauenswürdigen Domains in 2016 eine Bypass-Rate von etwa 94 % hatten; strict-dynamic mit Nonces ist die empfohlene moderne Alternative.

Alternativen und ergänzende Verteidigungen

CSP ist kein vollständiger XSS-Schutz. Kombiniere es mit Output-Encoding, X-Content-Type-Options: nosniff, Referrer-Policy und Permissions-Policy für mehrschichtige Verteidigung. frame-ancestors in CSP ersetzt das Legacy-X-Frame-Options. Trusted Types (Level 3) bietet stärkere Inline-Skript-Sicherheit als Nonces. Cloudflare, Netlify und Vercel unterstützen CSP alle über Plattformkonfiguration; für Nginx verwende add_header Content-Security-Policy. Welche Plattform du auch verwendest, deploye zuerst als Report-Only, sammle eine Woche lang Berichte, dann schalte auf Erzwingung um, sobald der Verstoßstrom sauber ist.

Häufig gestellte Fragen

Was ist der Unterschied zwischen CSP Level 2 und Level 3?

Level 2 ist eine W3C-Empfehlung (stabil, vollständig unterstützt). Level 3 ist ein Working Draft, der <code>strict-dynamic</code>, <code>report-to</code>, Trusted Types, <code>unsafe-hashes</code> und <code>worker-src</code> einführt. Moderne Browser (Chrome 52+, Firefox 49+, Safari 15.4+) implementieren die meisten Level-3-Funktionen; ältere Browser ignorieren unbekannte Direktiven problemlos. Du kannst heute sicher Level-3-Funktionen mit Level-2-Fallbacks für Legacy-Clients verwenden.

Sollte ich <code>unsafe-inline</code> verwenden?

Nur als Migrationsschritt, nicht langfristig. <code>unsafe-inline</code> erlaubt die Ausführung jedes Inline-Skripts oder -Stils, was den XSS-Schutz von CSP zunichte macht. Der moderne Ansatz sind Nonces (zufällige Token pro Antwort) oder Hashes (SHA-256 spezifischer Skriptinhalte) für die wenigen Inline-Skripte, die du nicht refaktorieren kannst. Googles CSP-Evaluator kennzeichnet <code>unsafe-inline</code> in der Produktion als kritische Schwäche.

Wie interagiert CSP mit Google AdSense?

AdSense erfordert mehrere Google-Domains über Direktiven hinweg: <code>script-src</code> benötigt <code>pagead2.googlesyndication.com</code>, <code>adservice.google.com</code>; <code>frame-src</code> benötigt <code>googleads.g.doubleclick.net</code>; <code>img-src</code> und <code>connect-src</code> benötigen <code>*.googlesyndication.com</code>. Alternativ verwende <code>strict-dynamic</code> mit einem Nonce auf dem AdSense-Loader, der erlaubt, dass seine kettbelasteten Ressourcen ausgeführt werden, ohne jeden Ursprung aufzulisten.

Was ist <code>strict-dynamic</code> und warum verwenden?

Es erweitert das Vertrauen von Skripten, die mit einem gültigen Nonce oder Hash geladen wurden, auf alle Skripte, die diese Skripte anschließend laden. Ohne es müssen beim Laden von Google Tag Manager alle Vendor-Tags, die er auslöst (Werbung, Analytics, Chat-Widgets), aufgelistet werden. Damit vertraust du dem GTM-Loader über Nonce und seine untergeordneten Skripte werden ohne weitere Richtlinienbearbeitungen ausgeführt. Es ist der Google-empfohlene Ansatz für moderne strenge CSPs und vereinfacht Drittanbieter-Skript-Integration drastisch.

Was ist ein Nonce und wie verwende ich ihn?

Ein Nonce (Number Used Once) ist ein kryptografisch zufälliges Token, das pro HTTP-Antwort frisch generiert wird, sowohl im CSP-Header (<code>script-src "nonce-abc123"</code>) als auch als <code>nonce="abc123"</code>-Attribut auf jedem vertrauenswürdigen Skript- oder Style-Tag enthalten ist. Der Browser führt nur Skripte aus, deren Nonce übereinstimmt. Die Zufallsanforderung bedeutet, dass ein Angreifer, der ein Skript-Tag injiziert, den Nonce nicht erraten kann, sodass ihr Skript nicht ausgeführt wird. Verwende <code>crypto.randomBytes(16).toString("base64")</code> in Node oder <code>secrets.token_urlsafe(16)</code> in Python, um Nonces serverseitig zu generieren.

Warum ersetzt <code>frame-ancestors</code> <code>X-Frame-Options</code>?

Beide steuern das iFrame-Einbetten durch andere Ursprünge (Clickjacking-Schutz). <code>X-Frame-Options</code> hat drei Werte und sein <code>ALLOW-FROM</code> funktionierte nie in Chrome. <code>frame-ancestors</code> in CSP Level 2+ unterstützt mehrere Ursprünge und ist besser spezifiziert. Verwende <code>frame-ancestors</code> für neue Deployments.

Was macht der Report-Only-Modus tatsächlich?

<code>Content-Security-Policy-Report-Only</code> weist den Browser an, Verstöße zu erkennen und Berichte an deinen <code>report-to</code>-Endpunkt zu senden, ohne die verletzende Ressource zu blockieren. Das erlaubt dir, eine strenge Richtlinie in der Produktion einzusetzen, zu beobachten, was im echten Datenverkehr bricht (über die gesammelten Berichte), und die Richtlinie zu verfeinern, bevor du in den erzwungenen Modus wechselst. Der Kompromiss: Report-Only bietet keinen tatsächlichen Schutz - es ist rein diagnostisch.

Wie sammle ich CSP-Verstoßberichte?

Richte einen <code>report-to</code>-Endpunkt (Level 3) oder <code>report-uri</code> (Level-2-Fallback) ein, der POST-Anfragen mit dem Verstoß-JSON akzeptiert. Dienste wie Report URI, Sentry und Cloudflare Browser Insights akzeptieren CSP-Berichte direkt. Erwarte anfänglich ein hohes Volumen; filtere Rauschen von Browser-Erweiterungsinjektionen heraus, bevor du handelst.

Kann ich CSP über ein Meta-Tag setzen?

Teilweise. <code>&lt;meta http-equiv="Content-Security-Policy" content="..."&gt;</code> funktioniert für die meisten Direktiven, aber NICHT für <code>frame-ancestors</code>, <code>report-uri</code>, <code>report-to</code> und <code>sandbox</code>. Das Meta-Tag wird angewendet, nachdem der Browser bereits mit dem Parsen der Seite begonnen hat, sodass einige Ressourcen möglicherweise bereits angefordert wurden. HTTP-Header werden immer bevorzugt; das Meta-Tag ist ein Fallback für statische Hosts, die keine Header setzen können.

Wird CSP meine Website verlangsamen?

Kein messbarer Leistungseinfluss für vernünftige Richtlinien. Der Browser erzwingt CSP bei der Ressourcenanforderungszeit als Teil normaler Prüfungen; kein zusätzlicher Roundtrip oder erhebliche Berechnung. Sehr große Richtlinien (über 20 KB Quelllisten) fügen marginalen Overhead hinzu, bleiben aber vernachlässigbar. Die eigentlichen Kosten sind die Erstellungszeit und die Behandlung von Verstoßberichten.

Was passiert, wenn CSP eine kritische Ressource blockiert?

Die Seite lädt weiterhin, aber die blockierte Ressource wird nicht ausgeführt, sodass jede abhängige Funktion aus der Perspektive des Benutzers still bricht. Die Browser-Konsole zeigt einen Verstoß und ein Bericht wird an deinen Endpunkt gesendet, wenn konfiguriert. Praktisches Muster: Report-Only zuerst, 1-2 Wochen auf Verstöße prüfen, legitime Quellen korrigieren, dann erzwingen.

Überträgt der Generator meine Richtlinie?

Nein. Der Richtlinien-String wird vollständig in deinem Browser über eine reine JavaScript-Funktion erstellt. Es wird keine Anfrage an einen Server gesendet. Das ist wichtig, weil CSP oft interne Ursprünge nennt (Staging-Hostnamen, private CDN-Pfade), die Informationen über deine Infrastruktur preisgeben.

Mehr Security & Privacy

AES-256 Encrypt / Decrypt Online - Free, In-Browser

Encrypt and decrypt text with AES-128, AES-192, or AES-256 in GCM, CBC, or CTR mode. PBKDF2 key derivation, entirely in your browser.

Open tool

Basic Auth Header Generator

Create HTTP Basic Authentication headers from a username and password or API token.

Open tool

Password Entropy Calculator

Estimate password entropy, character pool size and crack-time ranges for online and offline attacks.

Open tool

Password Generator

Generate cryptographically secure random passwords with configurable length, character types and entropy display.

Open tool

Password Strength Checker

Check password strength with entropy calculation, pattern detection and common password matching.

Open tool

PBKDF2 Hash Generator

Derive cryptographic keys from passwords using PBKDF2 with configurable iterations, salt and hash function.

Open tool