CSP-Generator: Content Security Policy ohne Kopfschmerzen

Content Security Policy (CSP) ist eines der wirksamsten Werkzeuge gegen XSS-Angriffe — und gleichzeitig einer der kompliziertesten HTTP-Header, die man konfigurieren kann. Ein Tippfehler im Direktiven-Namen führt zu keiner Fehlermeldung, ein vergessener Eintrag kann entweder eine Sicherheitslücke offenlassen oder die Website komplett zum Schweigen bringen.

Dieser Leitfaden erklärt, wie CSP funktioniert, welche Direktiven entscheidend sind, welche Fehler fast jeder macht, und wie der CSP-Generator diesen Prozess erheblich vereinfacht.

Warum CSP wichtig ist

XSS (Cross-Site Scripting) gehört seit Jahren zu den gefährlichsten Webanwendungslücken. Angreifer schleusen schadhaften JavaScript-Code in Webseiten ein — über Benutzereingaben, URL-Parameter oder fehlerhaft verarbeitete Drittinhalte. Die Folgen können verheerend sein:

Diebstahl von Session-Tokens und Cookies
Ausführung von Aktionen im Namen des Benutzers
Einschleusen von gefälschten Login-Formularen (Phishing im Kontext)
Auslesen sensibler Seiteninhalte

Eingabevalidierung ist die erste Verteidigungslinie. Aber reale Anwendungen sind komplex: Rich-Text-Editoren, Drittanbieter-Integrationen, Legacy-Code. CSP ist die zweite Verteidigungslinie — selbst wenn eine Injektion gelingt, verhindert CSP die Ausführung des schadhaften Skripts.

Die Grundstruktur eines CSP-Headers

CSP wird als HTTP-Response-Header gesendet:

Content-Security-Policy: direktive1 wert1 wert2; direktive2 wert1; ...

Ein Beispiel:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; img-src 'self' data: https:;

Jede Direktive wird durch Semikolon getrennt. Nach dem Direktiven-Namen folgen die erlaubten Quellen, getrennt durch Leerzeichen.

Die wichtigsten CSP-Direktiven

default-src: Der Fallback

Was nicht explizit durch eine spezifischere Direktive geregelt ist, fällt unter default-src:

default-src 'self';

'self' erlaubt Ressourcen ausschließlich vom gleichen Ursprung (identisches Protokoll, Domain und Port).

script-src: Die kritischste Direktive

Steuert, von wo JavaScript geladen werden darf:

script-src 'self' https://cdn.jsdelivr.net https://www.googletagmanager.com;

Häufig verwendete Quell-Werte:

'self' — Nur gleicher Ursprung
'none' — Alle Skripte verboten
'nonce-{zufallswert}' — Nur Inline-Skripte mit passendem Nonce-Attribut
'strict-dynamic' — Vertrauenswürdige Skripte dürfen weitere Skripte dynamisch laden
https://example.com — Explizit angegebener Ursprung

In der Produktion unbedingt vermeiden: 'unsafe-inline' und 'unsafe-eval'. Diese beiden Werte machen den Großteil des XSS-Schutzes zunichte.

style-src: Steuert CSS-Quellen

style-src 'self' https://fonts.googleapis.com;

img-src: Steuert Bildquellen

img-src 'self' data: https:;

data: erlaubt Base64-kodierte Inline-Bilder. https: erlaubt alle externen Bilder über HTTPS.

font-src: Steuert Schriftarten

font-src 'self' https://fonts.gstatic.com;

connect-src: Steuert Ajax und WebSockets

Kontrolliert Verbindungsziele für fetch(), XMLHttpRequest, WebSockets:

connect-src 'self' https://api.example.com wss://ws.example.com;

frame-src: Steuert iframes

frame-src 'none';                    /* Alle iframes verboten */
frame-src https://www.youtube.com;  /* Nur YouTube */

form-action: Steuert Formular-Ziele

form-action 'self';

base-uri: Schränkt das base-Element ein

Verhindert, dass Angreifer ein <base>-Tag einfügen, das relative URLs umleitet:

base-uri 'self';

frame-ancestors: Wer darf die Seite einbetten?

Ersetzt den veralteten X-Frame-Options-Header:

frame-ancestors 'none';     /* Seite kann nicht in iframes eingebettet werden */
frame-ancestors 'self';     /* Nur gleicher Ursprung */

upgrade-insecure-requests: Automatisch auf HTTPS umschalten

upgrade-insecure-requests;

Typische Konfigurationsfehler

Fehler 1: unsafe-inline als Abkürzung

Der häufigste Fehler: Inline-Skripte funktionieren nicht, also wird 'unsafe-inline' hinzugefügt. Das erlaubt wieder alle Inline-Skripte und macht script-src im Wesentlichen wirkungslos gegen XSS.

Die richtige Lösung: Nonces. Der Server generiert pro Request einen zufälligen Wert, der sowohl im CSP-Header als auch als nonce-Attribut am Script-Tag erscheint:

<script nonce="gHk9mP3xR7sW">
  // Dieses Skript wird erlaubt, weil der Nonce übereinstimmt
</script>

CSP-Header:

script-src 'self' 'nonce-gHk9mP3xR7sW';

Da der Nonce bei jedem Request anders ist, kann ein Angreifer ihn nicht vorhersagen und das Nonce-System nicht missbrauchen.

Fehler 2: Drittanbieter-Skripte vergessen

Google Analytics, Stripe, Intercom, Hotjar und andere Dienste laden Skripte von ihren CDNs — diese Ursprünge müssen in script-src aufgenommen werden:

script-src 'self'
  https://www.googletagmanager.com
  https://www.google-analytics.com
  https://js.stripe.com;

Vor dem Rollout: In der Browser-Konsole (Tab "Netzwerk" und "Konsole") prüfen, ob Ressourcen blockiert werden.

Fehler 3: Vergessen, dass connect-src und img-src ebenfalls angepasst werden müssen

Google Analytics benötigt nicht nur einen Eintrag in script-src, sondern auch:

img-src     'self' https://www.google-analytics.com data:;
connect-src 'self' https://www.google-analytics.com;

Fehler 4: Direkt in die Produktion deployen ohne vorheriges Testen

CSP ohne Test in die Produktion zu bringen ist riskant. Ein fehlender Ursprung kann dazu führen, dass JavaScript nicht lädt, Stile fehlen oder API-Anfragen scheitern.

Der Report-Only-Modus: Sicheres Testen

Verwenden Sie Content-Security-Policy-Report-Only für sicheres Testen in der Produktion:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; report-uri /csp-reports

Dieser Header:

Blockiert keine Ressourcen (die Website funktioniert normal)
Meldet alle Verstöße an den angegebenen Endpunkt
Ermöglicht das Testen unter echtem Produktions-Traffic

Der Verstoßbericht kommt als JSON:

{
  "csp-report": {
    "document-uri": "https://example.com/seite",
    "violated-directive": "script-src-elem",
    "blocked-uri": "https://externer-dienst.com/skript.js",
    "original-policy": "default-src 'self'; script-src 'self'"
  }
}

Anhand dieser Berichte erweitern Sie die Whitelist schrittweise, bis keine falschen Meldungen mehr erscheinen — dann schalten Sie auf den echten Content-Security-Policy-Header um.

Praktische Konfigurationsbeispiele

Einfache statische Website

Content-Security-Policy:
  default-src 'self';
  img-src 'self' data:;
  style-src 'self';
  font-src 'self';
  form-action 'self';
  base-uri 'self';
  frame-ancestors 'none';

Marketing-Website mit Google Analytics

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' https://www.google-analytics.com data:;
  connect-src 'self' https://www.google-analytics.com;
  form-action 'self';
  base-uri 'self';

SaaS-Anwendung mit Stripe

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://js.stripe.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  connect-src 'self' https://api.stripe.com https://api.ihredomain.de;
  frame-src https://js.stripe.com;
  form-action 'self';
  base-uri 'self';
  upgrade-insecure-requests;

SPA mit Nonce-basiertem Ansatz

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{server_generierter_nonce}' 'strict-dynamic';
  style-src 'self' 'nonce-{server_generierter_nonce}';
  img-src 'self' data: blob:;
  connect-src 'self' https://api.ihredomain.de;
  font-src 'self';
  form-action 'self';
  base-uri 'self';
  upgrade-insecure-requests;

CSP per Meta-Tag setzen

Wenn kein Zugriff auf Server-Header möglich ist (z.B. reines statisches Hosting):

<head>
  <!-- Möglichst frühzeitig im head-Element -->
  <meta http-equiv="Content-Security-Policy"
        content="default-src 'self'; script-src 'self'; style-src 'self'">
</head>

Einschränkungen des Meta-Tags:

frame-ancestors und report-uri werden nicht unterstützt
Greift etwas später als HTTP-Header (nach Beginn des HTML-Parsings)

HTTP-Header sind grundsätzlich vorzuziehen.

Empfohlener Einführungsworkflow

Mit Report-Only starten — Kein Blocking, nur Datensammlung
Verstöße in der Produktion beobachten — Mehrere Tage echten Traffic analysieren
Whitelist verfeinern — Legitime Quellen hinzufügen, echte Verstöße identifizieren
Auf echten CSP-Header umstellen — Wenn die Whitelist vollständig ist
Dauerhaft überwachen — Neue Features können neue Verstöße verursachen

Warum ein Generator verwenden?

CSP-Header manuell zu schreiben birgt mehrere Risiken:

Tippfehler in Direktiven-Namen erzeugen keine Fehlermeldung
Die genaue Syntax (wann brauchen Werte Anführungszeichen?) ist fehleranfällig
Mehrere Drittanbieter-Dienste in einer Whitelist zu verwalten wird schnell unübersichtlich
Wechsel zwischen Report-Only und erzwingender Version ist fehleranfällig

Der CSP-Generator löst diese Probleme:

Intuitive Benutzeroberfläche für jede Direktive
Automatisch korrekte Syntax (Anführungszeichen, Semikolons, Leerzeichen)
Vordefinierte Profile für gängige Dienste (Google Analytics, Stripe usw.)
Fertige Header-Strings zum direkten Kopieren in die Server-Konfiguration

Fazit

CSP ist eine wesentliche Sicherheitsschicht für moderne Webanwendungen. Die wichtigsten Punkte im Überblick:

'unsafe-inline' und 'unsafe-eval' in der Produktion vermeiden — Nonces sind die richtige Alternative
Mit dem Report-Only-Modus testen, bevor man CSP erzwingt
Drittanbieter-Skripte erfordern Einträge in script-src, connect-src und oft auch img-src
base-uri 'self' und form-action 'self' schützen vor weiteren Angriffsvektoren
frame-ancestors 'none' ersetzt X-Frame-Options
CSP-Verstöße dauerhaft überwachen

Öffnen Sie den CSP-Generator, konfigurieren Sie Ihre Direktiven in der Benutzeroberfläche und kopieren Sie den fertigen Header — das ist schneller und sicherer als manuelles Schreiben.