Inhaltssicherheitsrichtlinie Schreiben einer funktionierenden CSP-Header

Die meisten Entwickler wissen, dass sie einen Inhaltssicherheitsheader zu ihren Anwendungen hinzufügen sollten. Wenige haben jedoch eine, die tatsächlich etwas nützliches tut. Entweder ist sie zu liberal und verliert damit ihren Zweck, oder sie bricht die Hälfte der Seite und wird aus Frustration entfernt.

Dieser Leitfaden erklärt, was die CSP tut, welche Richtlinien wichtig sind und wie man einen Header schreibt, der echte Angriffe blockiert, ohne die App zu stören.

Was die CSP tatsächlich tut

Eine Inhaltssicherheitsrichtlinie teilt dem Browser mit, wo Ressourcen geladen werden dürfen. Skripte aus diesem Domain. Styles aus dem CDN. Bilder aus überall. Keine inline-Skripte.

Wenn ein Browser einen CSP-Header erhält, überprüft er diese Regeln, bevor er etwas ausführt. Wenn ein Cross-Site-Scripting (XSS)-Angriff ein schädliches Skript in deine HTML-Datei einfügt, blockiert die CSP es auf Browser-Ebene – selbst wenn das Skript deine Eingabe-Validierung umgangen hat.

Das ist der Kernwert: Die CSP ist deine zweite Sicherheitslinie, wenn Eingabevalidierung fehlschlägt.

Die wichtigen Richtlinien

Die CSP verfügt über Dutzende Richtlinien, aber die meisten Produktionsheader benötigen nur sechs:

frame-ancestors ersetzt die ältere X-Frame-Options Header und ist wertvoll, selbst bevor du eine vollständige CSP-Abdeckung hast.

Warum unsafe-inline Die Funktion zerstört

Wenn du 'unsafe-inline' Zu script-srchinzufügst, sagst du dem Browser: Führe jedes Skript aus, das du findest, unabhängig von der Quelle. Dazu gehören auch Skripte, die durch XSS-Angriffe injiziert wurden.

'unsafe-eval' ist schlimmer – es erlaubt eval(), Function()und setTimeout("string"), die häufige Angriffsvektoren sind, selbst in sonst sauberen Codebasen.

Eine Richtlinie mit diesen Dokumenten dokumentiert deine Quellen, ohne echte Injection-Schutz zu bieten. Der Angreifer interessiert sich nicht, wo deine legitimen Skripte geladen werden, wenn sie ihre eigenen inline-Skripte injizieren können.

Die richtige Methode: Nonces und Hashes

Wenn du legitime inline-Skripte hast, hast du zwei Optionen, die deine Richtlinie nicht aufgeben:

Nonces erzeugen einen eindeutigen Token pro Seitenaufruf. Der Server fügt es dem CSP-Header und der inline-Skript-Attribute hinzu. Nur Skripte mit einem übereinstimmenden Nonce werden ausgeführt. nonce Hashes

<!-- CSP header -->
Content-Security-Policy: script-src 'nonce-abc123xyz'

<!-- Inline script with matching nonce -->
<script nonce="abc123xyz">
  window.analyticsId = '...';
</script>

berechnen einen SHA-256-Fingerprint des genauen Skriptinhalts. Füge diesen Hash hinzu und der Browser führt dieses spezifische Skript aus – aber nichts anderes. script-src Nonces funktionieren besser für dynamische Seiten, bei denen der Inhalt pro Anfrage variiert. Hashes eignen sich für statische Skripte, die zwischen Bereitstellungen nie ändern.

Content-Security-Policy: script-src 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc='

Mit Report-Only-Modus deployen

Das Hinzufügen von CSP zu einer bestehenden Website ohne Test ist die Art, wie man sie in der Produktion kaputt macht. Beginne stattdessen mit dem Report-Only-Header:

Der Browser wendet die Regeln an und meldet Verstöße – er blockiert nichts noch. Diese Verstoßprotokolle zeigen dir genau, was du dem Header hinzufügen musst, bevor du den Modus in die Produktion wechselst.

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'nonce-{random}'; report-uri /csp-violations

Die meisten CSP-Implementierungen, die Websites kaputt machen, haben diesen Schritt übersprungen.

Ein echter CSP für eine typische SaaS-Anwendung

Hier ist ein für eine Anwendung mit CDN, Google Analytics und Stripe geeigneter Header. Jede Richtlinie ist kommentiert:

mit einem kryptografisch zufälligen Wert, der pro Anfrage generiert wird – z. B. in PHP oder

Content-Security-Policy:
  # Tight default: only load from your own origin
  default-src 'self';

  # Scripts: your origin, GA tag manager via nonce, Stripe.js
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{SERVER_NONCE}';

  # Styles: your origin and Google Fonts CSS
  style-src 'self' https://fonts.googleapis.com;

  # Fonts: your origin and Google Fonts CDN
  font-src 'self' https://fonts.gstatic.com;

  # Images: your origin, CDN subdomain, and base64 data URIs
  img-src 'self' https://cdn.yourdomain.com data:;

  # Fetch/XHR: your API, GA collection endpoint, Stripe API
  connect-src 'self' https://www.google-analytics.com https://api.stripe.com;

  # Stripe renders its fields in an iframe
  frame-src https://js.stripe.com;

  # Nobody should be framing your app
  frame-ancestors 'none';

  # Block <object> and <embed> entirely
  object-src 'none';

  # Force HTTP requests to upgrade to HTTPS
  upgrade-insecure-requests;

Express (Node.js) {SERVER_NONCE} in Node. base64_encode(random_bytes(16)) Häufige CSP-Fehler crypto.randomBytes(16).toString('base64') Zu breite Wildcards.

erlaubt Skripte aus jeder Quelle. Du könntest dir den Skript-Header als völlig nutzlos vorstellen.

Unterdomänen vergessen. script-src * deckt nur deine genaue Quelle ab.

ist eine andere Quelle und benötigt eine explizite Eintragung unter 'self' Report-Only-Modus überspringen https://api.yourdomain.com Clickjacking-Schutz ist unabhängig vom XSS-Schutz. Füge ihn separat aus der übrigen Richtlinienmenge hinzu. connect-src.

CSP in mehreren Orten setzen. frame-ancestors. Wenn dein CDN und deine App jeweils einen CSP-Header setzen, wird das Verhalten unvorhersehbar. Setze es an einer Schicht – meistens auf deinem Ursprungsserver oder Reverse Proxy.

ohne Handler. Verstöße generieren POST-Anfragen an deinen Endpunkt bei jedem betroffenen Seitenaufruf. Entweder behandeln oder auf einen Dienst wie Report URI zeigen.

erforderlich ist, wird der Wildcard von dem Browser abgelehnt. Sie müssen die genaue Quelle angeben: report-uri Dein Header ohne Unsicherheit erstellen Die Aufzeichnung aller Domänen, die deine Seite über Skripte, Styles, Schriften, Bilder und API-Aufrufe lädt, wird schnell mühsam. Ein Online

CSP-Header-Generator

erlaubt dir, jede Richtlinie visuell zu konfigurieren und ein produktionsschweres Header-Output zu erhalten, den du direkt in deine Serverkonfiguration einfügen kannst. Nutze ihn als Ausgangspunkt, dann überprüfe deine tatsächlichen Netzwerkaufrufe in DevTools, um etwas zu entdecken, das der Generator verpasst hat. Ein zu lockeres CSP ist Dekoration. Ein zu strenges CSP bricht die Benutzer. Beginne mit Report-Only-Modus, verfeinere danach, und nutze Nonces, wo inline-Skripte unvermeidbar sind. Deine Richtlinie sollte dem Angreifer das Leben schwer machen – nicht dir.

Inhaltssicherheitsrichtlinie: Ein CSP-Header, der tatsächlich funktioniert 2

Inhaltssicherheitsrichtlinie: Ein CSP-Header, der tatsächlich funktioniert 1

Das könnte Ihnen auch gefallen

Neu

Vergleich von JSON-Objekten: Wie man Unterschiede in API-Antworten erkennen kann

Mehr lesen "

Veröffentlicht am 30. Apr. 2026

Neu

String-Fallkonvertierung: snake_case, camelCase, und warum es in APIs wichtig ist

Mehr lesen "

Veröffentlicht am 29. Apr. 2026

Neu

HTTP-Cookies: Wie sie richtig erstellt und parsiert werden

Mehr lesen "

Veröffentlicht am 28. Apr. 2026

Neu

CSS Grid im Praxisbeispiel: Nützliche Layouts ohne Framework

Mehr lesen "

Veröffentlicht am 27. Apr. 2026