Content Security Policy (CSP) richtig konfigurieren

Was eine Content Security Policy ist und warum sie relevant wird

Eine Content Security Policy ist ein HTTP-Response-Header, der dem Browser mitteilt, welche Ressourcen auf einer Seite geladen werden dürfen. Dazu gehören Skripte, Stylesheets, Bilder, Fonts, Frames, Formularziele und Verbindungen zu externen Servern. Der Browser blockiert alles, was nicht explizit erlaubt ist — einschließlich injizierter Skripte, die ein Angreifer über eine XSS-Lücke eingeschleust hat.

Dass CSP trotz seiner Wirksamkeit so selten eingesetzt wird, hat mehrere Gründe: Die Konfiguration ist komplex, Fehler führen zu kaputten Websites, und viele Entwickler schätzen das Risiko falsch ein. Dabei hat sich die Adoption in den letzten Jahren spürbar bewegt — von 15 % im Jahr 2022 über 19 % in 2024 auf 21,9 % in 2025 (HTTP Archive). Gleichzeitig nutzen bereits 97,3 % aller Websites HTTPS (HTTP Archive), was zeigt, dass die Branche Transport-Security ernst nimmt — Application-Security via CSP aber noch deutlich hinterherhinkt.

Die Diskrepanz zwischen HTTPS-Adoption und CSP-Verbreitung hat einen einfachen Grund: HTTPS lässt sich mit einem einzigen Zertifikat und einer Serverkonfiguration einrichten. CSP dagegen erfordert ein genaues Verständnis aller auf einer Website geladenen Ressourcen und deren Herkunft. Jedes externe Skript, jedes eingebettete Widget und jede API-Verbindung muss explizit erlaubt werden. Dieser Aufwand schreckt viele Websitebetreiber ab — obwohl eine strikte CSP einen Großteil der XSS-Angriffe abwehrt: Laut Google bleiben nur rund 25 % der XSS-Schwachstellen auch unter einer strikten CSP ausnutzbar — die übrigen rund drei Viertel werden zuverlässig blockiert (Google web.dev).

Die wichtigsten CSP-Direktiven im Überblick

Eine CSP besteht aus einer oder mehreren Direktiven, die jeweils einen Ressourcentyp regeln. Jede Direktive definiert, von welchen Quellen der Browser diese Ressource laden darf. Die korrekte Kombination entscheidet darüber, ob Ihre CSP tatsächlich schützt oder nur Sicherheit vortäuscht.

Warum die meisten CSP-Implementierungen scheitern

Die Zahlen sind ernüchternd: 91 % der Websites mit CSP nutzen die Direktive unsafe-inline (HTTP Archive Web Almanac 2024), 78 % setzen unsafe-eval ein (HTTP Archive Web Almanac 2024), und 95 % aller Whitelist-basierten CSPs lassen sich umgehen (Google Research). Nur 2 % aller analysierten Websites haben eine CSP, die als wirksam eingestuft wird (Bitsight). Diese Zahlen zeigen: Nicht das Fehlen einer CSP ist das größte Problem, sondern die fehlerhafte Konfiguration.

Nonce-basierte CSP: Der empfohlene Ansatz

Google Research hat in einer umfassenden Studie gezeigt, dass Whitelist-basierte CSPs in 95 % der Fälle umgehbar sind, weil mindestens eine Domain auf der Whitelist einen ausnutzbaren Endpunkt enthält (Google Research). Die Lösung: Nonce-basierte Policies. Dabei erhält jedes legitime Skript ein zufälliges, einmaliges Token (Nonce), das bei jedem Seitenladen neu generiert wird. Nur Skripte mit dem korrekten Nonce werden ausgeführt — injizierte Skripte kennen das Token nicht und werden blockiert.

Trotz dieser klaren Empfehlung nutzen nur 20 % der Websites mit CSP eine Nonce-basierte Policy (HTTP Archive Web Almanac 2024). Das bedeutet: Selbst unter den Websites, die CSP implementiert haben, verwenden rund 80 % einen veralteten oder unsicheren Ansatz.

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

Neben Nonces bietet CSP Level 3 weitere Mechanismen für eine robuste Policy. Der 'strict-dynamic'-Modus in Kombination mit Nonces stellt sicher, dass auch dynamisch nachgeladene Skripte — etwa durch Bundler oder Module-Loader — korrekt autorisiert werden, ohne dass jedes Skript einzeln einen Nonce benötigt. Die neuere report-to-Direktive ersetzt das ältere report-uri und nutzt die Reporting API des Browsers, um Violations strukturiert an einen Endpunkt zu senden. Das erlaubt eine differenziertere Auswertung: Sie sehen nicht nur, welche Ressource blockiert wurde, sondern auch den Dokumenten-URL, die verletzte Direktive und den blockierten URI in einem maschinenlesbaren JSON-Format.

CSP schrittweise einführen: Von Report-Only zur Durchsetzung

Die größte Angst bei der CSP-Einführung: Wird die Website kaputtgehen? Diese Angst ist berechtigt — eine falsch konfigurierte CSP blockiert legitime Ressourcen und kann Funktionen stören. Deshalb empfiehlt sich ein schrittweiser Rollout, bei dem Sie zunächst nur beobachten und dann verschärfen.

1. Bestandsaufnahme: Ermitteln Sie alle externen Ressourcen, die Ihre Website lädt — Skripte, Stylesheets, Fonts, Bilder, iFrames, API-Verbindungen. Ein Security-Scan liefert hier eine vollständige Übersicht.
2. Report-Only-Modus: Setzen Sie zunächst Content-Security-Policy-Report-Only statt Content-Security-Policy. Der Browser meldet Verstöße, blockiert aber nichts. So sehen Sie, welche Ressourcen betroffen wären.
3. Report-Endpunkt einrichten: Konfigurieren Sie report-uri oder die neuere Reporting-API, damit Verstöße an einen Endpunkt gemeldet werden. So erkennen Sie Probleme frühzeitig.
4. Policy iterativ anpassen: Analysieren Sie die Reports, erweitern Sie die erlaubten Quellen für legitime Ressourcen und entfernen Sie überflüssige Einträge.
5. Durchsetzung aktivieren: Wenn 2–4 Wochen lang keine unerwarteten Violations mehr auftreten, wechseln Sie von Report-Only auf den erzwingenden Header Content-Security-Policy.
6. Dauerhaftes Monitoring: CSP ist keine einmalige Konfiguration. Neue Skripte, geänderte Drittanbieter oder Updates können Ihre Policy brechen. Automatisiertes Header-Monitoring erkennt Änderungen sofort.

CSP für gängige CMS und Frameworks

Die praktische Umsetzung einer CSP hängt stark vom eingesetzten Tech-Stack ab. WordPress, Shopware und statische Websites erfordern unterschiedliche Ansätze. Was alle gemeinsam haben: Der CSP-Header wird idealerweise auf Webserver-Ebene (nginx/Apache) gesetzt, nicht im Anwendungscode — das verhindert, dass ein Angriff auf die Anwendung auch die CSP außer Kraft setzt.

WordPress

WordPress-Websites stehen vor einer besonderen Herausforderung: Der Gutenberg-Editor und viele Plugins nutzen exzessiv Inline-Skripte und eval(). Eine strikte CSP erfordert daher Nonce-Unterstützung durch ein entsprechendes Security-Plugin oder eine Custom-Integration in der functions.php. Alternativ können Sie den CSP-Header in der nginx- oder Apache-Konfiguration setzen und Inline-Skripte schrittweise eliminieren. Überwachen Sie den Erfolg mit regelmäßigen Security-Scans, die prüfen, ob nach Plugin-Updates die CSP weiterhin greift.

Shopware und E-Commerce

E-Commerce-Plattformen laden typischerweise Payment-Provider-Skripte, Tracking-Pixel und Chat-Widgets — jede dieser externen Ressourcen muss in der CSP berücksichtigt werden. Besonders kritisch: Payment-iFrames benötigen korrekte frame-src-Einträge, und die connect-src-Direktive muss API-Aufrufe an Zahlungsanbieter erlauben. Ein zu restriktiver CSP kann den Checkout-Prozess stören — testen Sie Änderungen daher unbedingt in einer Staging-Umgebung und überwachen Sie den Login-Flow und Checkout nach dem Rollout.

Unabhängig vom eingesetzten System gilt: Testen Sie CSP-Änderungen niemals direkt in der Produktivumgebung. Nutzen Sie eine Staging-Instanz und den Report-Only-Modus, um die Auswirkungen auf alle kritischen Funktionen — insbesondere Checkout, Kontaktformulare und eingebettete Inhalte — vor dem Rollout zu validieren. Ein automatisiertes Monitoring erkennt dabei sofort, wenn der Report-Only-Header Violations meldet, die auf Fehlkonfigurationen hindeuten.

Statische Websites und SPAs

Bei statischen Websites und Single Page Applications (SPAs) ist die CSP-Konfiguration vergleichsweise einfach, weil Sie die volle Kontrolle über alle geladenen Ressourcen haben. Setzen Sie den Header direkt in der Webserver-Konfiguration, eliminieren Sie Inline-Skripte zugunsten externer Dateien und nutzen Sie 'strict-dynamic' für dynamisch nachgeladene Module.

CSP und andere Security-Header: Das Zusammenspiel

CSP ist nur ein Baustein eines umfassenden HTTP-Security-Header-Setups. Für maximalen Schutz arbeitet CSP mit weiteren Headern zusammen, die sich gegenseitig ergänzen. Ein isolierter CSP-Header ist besser als keiner, aber erst die Kombination schließt die häufigsten Angriffsvektoren.

• Strict-Transport-Security (HSTS): Erzwingt HTTPS und verhindert Protocol-Downgrade-Angriffe. Ergänzt die CSP-Direktive upgrade-insecure-requests.
• X-Content-Type-Options: Verhindert MIME-Type-Sniffing — ein Angriffsvektor, bei dem der Browser eine Ressource anders interpretiert als beabsichtigt.
• X-Frame-Options: Verhindert Clickjacking durch Einbettung Ihrer Seite in einen Frame. Überlappt mit der CSP-Direktive frame-ancestors, wird aber als Fallback für ältere Browser empfohlen.
• Referrer-Policy: Steuert, welche Informationen in der Referrer-URL an externe Seiten weitergegeben werden.
• Permissions-Policy: Beschränkt den Zugriff auf Browser-APIs wie Kamera, Mikrofon, Geolocation und Payment.

Wenn Sie bereits Ihre SSL-Konfiguration optimiert haben, ist die Ergänzung von Security-Headern der logisch nächste Schritt. Zusammen bilden Transport-Security (HTTPS/HSTS) und Application-Security (CSP, Permissions-Policy) ein mehrschichtiges Sicherheitskonzept, das Angreifern die Arbeit erheblich erschwert.

XSS-Angriffe und ihre wirtschaftlichen Folgen

XSS ist keine theoretische Bedrohung. Injection-Schwachstellen stehen auf Platz 5 der OWASP Top 10:2025 (OWASP) — eine Kategorie, die XSS, SQL-Injection und Command-Injection umfasst. Die durchschnittlichen Kosten eines Datenlecks betragen 4,88 Millionen USD (IBM 2024), wobei Angriffe über Web-Applikationen einen der häufigsten Einstiegsvektoren darstellen.

Für deutsche KMUs sind die Folgen oft existenzbedrohend: Ein erfolgreicher XSS-Angriff kann Kundendaten exfiltrieren, was eine Meldepflicht nach Art. 33 DSGVO auslöst. Dazu kommen mögliche Bußgelder, Reputationsschäden und Umsatzverluste während der Bereinigung. Eine strikt konfigurierte CSP wehrt laut Google den Großteil der XSS-Angriffe ab — nur rund 25 % der XSS-Schwachstellen bleiben damit überhaupt noch ausnutzbar (Google web.dev) — ein enormer Sicherheitsgewinn für vergleichsweise geringen Konfigurationsaufwand.

CSP-Monitoring: Verstöße erkennen, Policy pflegen

Eine CSP ist kein Set-and-Forget-Header. Websites ändern sich laufend: Neue Skripte kommen hinzu, Drittanbieter ändern ihre Domains, CMS-Updates führen neue Inline-Skripte ein. Ohne kontinuierliches Monitoring bemerken Sie Veränderungen erst, wenn Funktionen ausfallen oder Sicherheitslücken entstehen.

Es gibt zwei Monitoring-Ebenen: CSP-Violation-Reports über die report-uri-Direktive liefern Echtzeit-Daten über blockierte Ressourcen. Regelmäßige Header-Prüfungen stellen sicher, dass der CSP-Header überhaupt noch gesetzt ist, die richtigen Direktiven enthält und keine unsicheren Fallbacks wie unsafe-inline hinzugekommen sind.

Der XICTRAQ Security-Scan prüft bei jedem Check Ihre HTTP-Response-Header auf Vollständigkeit und Konfigurationsfehler. Sollte Ihr CSP-Header verschwinden, eine unsafe-inline-Direktive hinzugefügt werden oder eine Direktive fehlen, erhalten Sie sofort eine Benachrichtigung — per E-Mail, Slack, Discord oder Telegram.

CSP-Checkliste für die Praxis

• default-src 'self' als Basis setzen — blockiert alles, was nicht explizit erlaubt ist
• script-src mit Nonce statt Whitelists — 95 % der Whitelist-CSPs sind umgehbar (Google Research)
• unsafe-inline und unsafe-eval vermeiden — unsafe-inline ist in 91 %, unsafe-eval in 78 % aller CSPs präsent und Hauptgrund für Wirkungslosigkeit (HTTP Archive Web Almanac 2024)
• frame-ancestors 'self' setzen — schützt gegen Clickjacking
• form-action 'self' setzen — verhindert, dass Formulardaten an Angreifer-Domains gesendet werden
• base-uri 'self' setzen — blockiert Base-Tag-Injection, einen oft übersehenen Angriffsvektor
• upgrade-insecure-requests hinzufügen — erzwingt HTTPS für alle Subressourcen
• Report-Endpunkt konfigurieren — ohne Violation-Reports fliegen Probleme unter dem Radar
• Regelmäßig testen — nach jedem CMS-Update, Plugin-Wechsel oder Deployment mit automatisiertem Monitoring prüfen

Typische Stolpersteine bei der CSP-Migration

Die häufigsten Probleme bei der CSP-Einführung sind vorhersehbar und vermeidbar. Wer sie kennt, spart sich wochenlange Fehlersuche und Produktionsausfälle.

CSP im Kontext von Compliance und Standards

CSP wird zunehmend zum Compliance-Thema. Die OWASP Top 10:2025 listen Injection-Schwachstellen auf Platz 5 (OWASP), und CSP wird als primäre Gegenmaßnahme gegen XSS empfohlen. Für Unternehmen, die PCI DSS einhalten müssen, ist eine wirksame CSP mittlerweile praktisch Pflicht. Auch der BSI IT-Grundschutz empfiehlt die Konfiguration von Security-Headern als Teil der Webserver-Härtung.

Darüber hinaus kann eine CSP zur DSGVO-Compliance beitragen: Wenn eine CSP verhindert, dass injizierte Skripte Kundendaten exfiltrieren, reduziert das das Risiko einer meldepflichtigen Datenpanne erheblich. In Kombination mit einer soliden Website-Sicherheits-Checkliste und regelmäßigen Sicherheitsaudits bildet CSP die technische Grundlage für nachweisbare Schutzmaßnahmen.

CSP-Header prüfen und Konfiguration absichern

Nur 2 % der Websites haben laut einer aktuellen Analyse eine CSP, die als sicher eingestuft wird (Bitsight). Das liegt nicht daran, dass CSP zu komplex wäre — sondern daran, dass die initiale Konfiguration häufig nicht überprüft und nicht fortlaufend gepflegt wird. Nach einem CMS-Update, einem Plugin-Wechsel oder einer Deployment-Änderung kann eine zuvor sichere CSP plötzlich Lücken aufweisen.

Automatisiertes Monitoring löst dieses Problem. Der XICTRAQ Security-Scan prüft Ihre HTTP-Security-Header regelmäßig und erkennt sofort, wenn eine CSP-Direktive fehlt, eine unsichere Quelle hinzugefügt wurde oder der gesamte Header verschwunden ist. In Kombination mit API-Monitoring und Backup-Heartbeats entsteht eine lückenlose Überwachungskette für Ihre gesamte Infrastruktur.

Häufig gestellte Fragen zur Content Security Policy