Content Security Policy (CSP) ohne Site-Bruch

Sie haben gehört, dass Content Security Policy (CSP) unerlässlich ist, um Ihre Website vor Cross-Site-Scripting (XSS) und Data-Injection-Angriffen zu schützen. Doch wenn Sie versuchen, sie hinzuzufügen, bricht Ihre Website zusammen: Bilder verschwinden, Skripte werden nicht mehr ausgeführt, Styles verschwinden. Es fühlt sich an wie ein Kompromiss zwischen Sicherheit und Funktionalität. Das muss nicht sein.

In dieser Anleitung lernen Sie einen praktischen, schrittweisen Ansatz kennen, um CSP einzusetzen, ohne Ihre Website zu beschädigen. Wir behandeln die wichtigsten Direktiven, die Verwendung von Nonces und Hashes und wie Sie sicher testen. Am Ende verfügen Sie über eine funktionierende CSP, die die Sicherheit erhöht, ohne die Benutzererfahrung zu beeinträchtigen.

Was ist CSP und warum bricht es Websites?

Content Security Policy ist ein Browser-Sicherheitsstandard, mit dem Sie einschränken können, welche Ressourcen (Skripte, Styles, Bilder, Schriftarten usw.) auf Ihrer Seite geladen werden dürfen. Sie wird über einen HTTP-Header wie Content-Security-Policy: default-src 'self' übermittelt.

CSP bricht Websites, weil es jede Ressource blockiert, die nicht Ihrer Richtlinie entspricht. Wenn Sie Inline-Skripte, externe Skripte von CDNs oder Inline-Styles haben, werden diese blockiert, es sei denn, Sie erlauben sie explizit. Das Standardverhalten besteht darin, alles zu blockieren, was nicht erlaubt ist, weshalb eine strenge Richtlinie eine Website schnell lahmlegen kann.

Der Schlüssel liegt darin, mit einer permissiven Richtlinie zu beginnen und sie schrittweise zu verschärfen, während Sie auf Verstöße achten.

Wichtige CSP-Direktiven, die Sie kennen sollten

CSP verwendet Direktiven, um verschiedene Ressourcentypen zu steuern. Hier sind die gebräuchlichsten:

• default-src: Fallback für andere Direktiven. Beginnen Sie hier.
• script-src: Steuert JavaScript-Quellen.
• style-src: Steuert CSS-Quellen.
• img-src: Steuert Bildquellen.
• connect-src: Steuert AJAX-, WebSocket- und Fetch-Ziele.
• font-src: Steuert Webfont-Quellen.
• frame-src: Steuert Iframe-Quellen.
• report-uri / report-to: Wohin Verstoßberichte gesendet werden.

Sie können mehrere Direktiven in einem Header festlegen, getrennt durch Semikolons. Zum Beispiel:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https://images.example.com

Jede Direktive akzeptiert eine durch Leerzeichen getrennte Liste von Quellen. Quellen können Schlüsselwörter wie 'self', 'unsafe-inline', 'unsafe-eval' oder URLs oder Nonces/Hashes sein.

Schritt für Schritt: CSP einsetzen, ohne Ihre Website zu beschädigen

Befolgen Sie diese Schritte, um CSP sicher auszurollen.

1. Beginnen Sie mit einer Report-Only-Richtlinie. Verwenden Sie den Header Content-Security-Policy-Report-Only anstelle des erzwingenden Headers. So sehen Sie, was blockiert würde, ohne es tatsächlich zu blockieren.
2. Legen Sie eine permissive Richtlinie fest. Beginnen Sie mit etwas wie default-src 'self' 'unsafe-inline' 'unsafe-eval' https:, um die meisten Dinge zu erlauben. Dies minimiert Brüche.
3. Sammeln Sie Verstoßberichte. Konfigurieren Sie report-uri auf einen Endpunkt, der Verstöße protokolliert. Überprüfen Sie diese Berichte, um blockierte Ressourcen zu identifizieren.
4. Beheben Sie Verstöße. Aktualisieren Sie Ihren Code, um Inline-Skripte/-Styles zu vermeiden, oder fügen Sie Nonces/Hashes hinzu. Verschieben Sie externe Ressourcen auf erlaubte Domains.
5. Verschärfen Sie die Richtlinie schrittweise. Entfernen Sie 'unsafe-inline' und 'unsafe-eval', sobald Sie refaktoriert haben. Schränken Sie erlaubte Domains ein.
6. Wechseln Sie in den Erzwingungsmodus. Sobald Berichte keine unerwarteten Blockierungen mehr zeigen, ändern Sie den Header in Content-Security-Policy (ohne -Report-Only).
7. Überwachen Sie kontinuierlich. Halten Sie den Berichts-Endpunkt aktiv, um neue Probleme zu erkennen.

Dieser inkrementelle Ansatz stellt sicher, dass Sie Ihre Website nicht beschädigen, während Sie die Sicherheit verbessern.

Verwendung von Nonces und Hashes für Inline-Skripte

Inline-Skripte sind eine häufige Ursache für CSP-Brüche. Anstatt 'unsafe-inline' zu erlauben, verwenden Sie einen Nonce (Number used once) oder einen Hash.

Nonce-Ansatz: Generieren Sie einen zufälligen Nonce pro Anfrage, fügen Sie ihn Ihrem CSP-Header hinzu und binden Sie ihn in Ihre Script-Tags ein.

Content-Security-Policy: script-src 'nonce-abc123'

<script nonce="abc123">...</script>

Hash-Ansatz: Berechnen Sie den SHA-Hash Ihres Inline-Skripts und fügen Sie ihn der Richtlinie hinzu.

Content-Security-Policy: script-src 'sha256-xyz...'

Hashes eignen sich am besten für statische Inline-Skripte, die sich nicht oft ändern. Nonces sind besser für dynamische Inhalte.

Für Styles können Sie auch Nonces oder Hashes verwenden, aber beachten Sie, dass style-src mit Nonces keine Inline-Style-Attribute (z. B. style="...") abdeckt. Für diese benötigen Sie 'unsafe-inline' oder müssen auf Klassen umstellen.

Häufige CSP-Direktiven und ihre Auswirkungen

Verwenden Sie diese Tabelle als Kurzreferenz beim Erstellen Ihrer Richtlinie.

Testen und Überwachen Ihrer CSP

Testen Sie vor der Erzwingung gründlich. Nutzen Sie die Entwicklertools des Browsers: Der Console-Tab zeigt CSP-Verstöße als Fehler an. Der Network-Tab zeigt den CSP-Header.

Für automatisierte Tests kommen Tools wie der CSP Evaluator von Google (online) oder das npm-Paket csp_evaluator in Frage. Diese helfen, schwache Richtlinien zu identifizieren.

Richten Sie einen Berichts-Endpunkt ein, um Verstöße in der Produktion zu sammeln. Sie können einen Dienst wie Report URI nutzen oder einen eigenen Endpunkt erstellen, der in eine Datei oder Datenbank protokolliert. Analysieren Sie Berichte regelmäßig, um neue Probleme zu erkennen.

Denken Sie daran: CSP ist keine Wunderwaffe. Es ist eine Verteidigungsschicht. Kombinieren Sie es mit Eingabevalidierung, Ausgabekodierung und anderen Sicherheits-Best Practices.

FAQ

Was ist der Unterschied zwischen Content-Security-Policy und Content-Security-Policy-Report-Only?

Der erzwingende Header (Content-Security-Policy) blockiert Verstöße. Der Report-Only-Header (Content-Security-Policy-Report-Only) meldet Verstöße nur, ohne zu blockieren, sodass Sie eine Richtlinie sicher testen können.

Kann ich CSP mit Inline-Event-Handlern wie onclick verwenden?

Nein, Inline-Event-Handler werden von CSP blockiert, es sei denn, Sie verwenden 'unsafe-inline' (was nicht empfohlen wird) oder refaktorieren auf addEventListener. Für bessere Sicherheit vermeiden Sie Inline-Event-Handler.

Wie erlaube ich Google Analytics mit CSP?

Fügen Sie die Google Analytics-Domains zu Ihren script-src- und connect-src-Direktiven hinzu. Zum Beispiel: script-src 'self' https://www.googletagmanager.com; connect-src 'self' https://www.google-analytics.com. Prüfen Sie die Google-Dokumentation für die neuesten Anforderungen.

Die Bereitstellung von CSP muss kein schmerzhafter Prozess sein. Mit einem schrittweisen Ansatz können Sie Ihre Benutzer vor XSS und anderen Angriffen schützen, ohne Ihre Website zu stören. Beginnen Sie mit dem Report-Only-Modus, beheben Sie Verstöße und verschärfen Sie Ihre Richtlinie im Laufe der Zeit.

Wenn Sie JSON-Konfigurationsdateien für Ihre CSP-Berichte schnell formatieren oder validieren müssen, probieren Sie unseren JSON Formatter, um Ihre JSON-Daten zu verschönern und zu debuggen.