Sicherheitsheader für Websites: Content Security Policy sauber einführen

Content Security Policy ist einer der wenigen Header, die den Schaden nach einem XSS- oder Widget-Vorfall wirklich begrenzen können. Aber sie hilft nur dann, wenn sie zum realen Stack passt. Auf Service-Websites, CMS-Seiten und Web-Apps mit Analytics, Maps, Chat-Widgets und Embeds sollte die Policy aus einer Inventur entstehen — nicht aus einer kopierten Vorlage.

Googles Hilfreich-und-people-first-Richtlinie lässt sich hier überraschend gut übertragen: Ziel ist nicht, ein Kontrollkästchen zu erfüllen. Sicherheit sollte Menschen schützen, ohne Redaktionsabläufe, Performance oder die Seitenstruktur kaputt zu machen.

Warum Content Security Policy mehr ist als ein Sicherheits-Header

CSP sagt dem Browser, welche Quellen er laden oder ausführen darf. Die MDN-Implementierungsseite beschreibt eine strenge Policy als guten Schutz gegen XSS und empfiehlt nonce- oder hash-basierte Direktiven. Wenn Embeds nicht zwingend gebraucht werden, ist `object-src 'none'` ein sinnvoller Ausgangspunkt.

Für Marketing- und Service-Seiten ist der Wert nicht nur technisch. Eine saubere CSP macht Drittanbieter sichtbar. Teams sehen schneller, welche Widgets wirklich nötig sind, wo inline Scripts noch existieren und welche alten Workarounds nur noch aus Gewohnheit mitlaufen.

Das Diagramm zeigt, wie eine Policy den erlaubten Weg verengt.

Nonce oder Hash: welche Variante zu deinem Stack passt

Wenn Markup pro Request zusammengesetzt wird, sind nonce-basierte Policies meist die bequemere Wahl. Ein frisches Nonce pro Antwort kann einzelne Inline-Skripte erlauben, ohne alles Inline freizugeben. Wenn Seiten eher statisch sind und sich Scripts nur beim Deploy ändern, können Hashes praktischer sein, weil die Policy exakt den Script-Inhalt abbildet.

Der Unterschied ist weniger ideologisch als operativ. Nonces sind einfacher, wenn CMS oder Server denselben Wert in Header und Script-Tags einfügen können. Hashes sind einfacher, wenn der Code statisch ist, aber jede Script-Änderung in die Policy wandern muss. In beiden Fällen sollte `unsafe-inline` keine Dauerkonfiguration sein, nur weil der erste Durchgang unbequem ist.

Die richtige Wahl hängt von Templating und Deploy-Takt ab.

Ein Rollout ohne Chaos

• Inventarisiere alle Scripts, Styles, Bilder, Frames, Formulare und API-Verbindungen.

• Starte mit `Content-Security-Policy-Report-Only` und sammle Reports, bevor du etwas hart erzwingst.

• Ziehe `script-src`, `style-src`, `object-src`, `frame-ancestors`, `connect-src` und `form-action` schrittweise enger.

• Teste Analytics, Consent-Tools, Maps, Chat und Zahlungsstrecken nach jeder Änderung.

• Halte den Review-Loop in der Release-Routine kurz, konkret und wiederholbar.

Eine gestufte Einführung ist wichtig, weil CSP-Fehler oft genau dort auftauchen, wo Teams selten hinschauen: in alten Inline-Snippets, eingebetteten Widgets, Checkout-Flows oder CMS-Vorlagen. Die Report-Only-Phase liefert Belege, bevor die Policy live scharf geschaltet wird.

Eine Report-Only-Phase hält den Rollout kontrollierbar.

Typische Fehler

• `unsafe-inline` dauerhaft stehen lassen, weil es gerade bequemer wirkt.

• Jede Domain zu erlauben, die irgendwann einmal für ein Asset benutzt wurde.

• `frame-ancestors` zu vergessen und damit Clickjacking unbeabsichtigt offen zu lassen.

• `connect-src` enger zu ziehen, ohne Formulare oder API-Aufrufe neu zu testen.

Ein weiterer Fehler ist, CSP als reine Entwickleraufgabe zu sehen. Auf CMS-lastigen Seiten beeinflussen Redakteure, Consent-Manager und Release-Prozesse, ob die Policy dauerhaft wartbar bleibt. Die beste Policy ist die, die ein Team wirklich aktuell halten kann.

Quellen und Einordnung

Google Search Central: Creating Helpful, Reliable, People-First Content

MDN: Content Security Policy (implementation guide)

OWASP: Content Security Policy Cheat Sheet

CSP ist Defense in Depth, kein Ersatz für sauberes Encoding, gute Dependency-Hygiene oder Code-Reviews. Gerade deshalb ist sie für moderne Frontends so wertvoll: Sie reduziert die Angriffsfläche genau dort, wo Drittanbieter-Integrationen, CMS-Bausteine und eigene Templates zusammenkommen.

Wenn du Security-Header, CMS und Release-Prozesse gemeinsam prüfen willst, ist das ein Architekturthema, kein schneller Einzeiler.