So behebst du einen fehlenden Content-Security-Policy (CSP)-Header | Scanthra

Scanthra · 7 Min Lesezeit · Aktualisiert Mai 2026

Was ist der Content-Security-Policy-Header?

CSP ist ein Response-Header, der dem Browser genau sagt, welche Quellen für Skripte, Styles, Bilder und Frames er laden darf. Wenn etwas auf der Seite versucht, ein Skript von einer Domain zu laden, die nicht auf deiner Erlaubnisliste steht, lehnt der Browser es ab. Es ist wie eine Gästeliste für den Türsteher.

Ohne CSP läuft jeder eingeschleuste <script>-Tag — von einem gehackten Plugin, einem Tippfehler in einem Drittanbieter-Widget, einem gespeicherten XSS in einem Kommentar — mit vollem Zugriff auf die Cookies, Formulardaten und Sessions deiner Besucher. Mit einer strikten CSP wird derselbe Angriff still blockiert und protokolliert.

Warum das für ein kleines Unternehmen wichtig ist

Zwei reale Beispiele, die wir wöchentlich in Scanthra-Berichten sehen:

• Card-Skimming bei Checkouts — eine kompromittierte JavaScript-Bibliothek in einem WooCommerce-Shop liest Kartennummern aus und leitet sie weiter. Mit CSP wird die Exfiltrationsanfrage an eine Angreifer-Domain blockiert.
• Defacement und Phishing-Overlays — ein eingeschleustes Skript ersetzt dein Kontaktformular durch eines, das E-Mails an den Angreifer schickt. CSP würde das unbekannte Skript erst gar nicht laden.

CSP wird außerdem explizit von OWASP (Anwendungssicherheits-Standard) empfohlen, von den meisten Cyber-Versicherungsfragebögen erwartet und ist — für EU-Unternehmen — ein sinnvoller Teil der „geeigneten technischen Maßnahmen", die DSGVO (GDPR) Artikel 32 und die NIS2 (EU-Cybersicherheits-Richtlinie) verlangen.

Der sichere Rollout: zuerst der Report-only-Modus

Der größte Grund, warum kleine Websites CSP meiden, ist die Angst, das Layout zu beschädigen. Die Lösung: Setze zuerst Content-Security-Policy-Report-Only ein. Der Browser prüft die Policy und meldet Verstöße, erzwingt sie aber nicht. Beobachte eine Woche lang die Logs, behebe was blockiert wird, dann wechsle zum durchsetzenden Header.

Eine Starter-Policy, die für die meisten Websites funktioniert

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://www.google-analytics.com;
  style-src  'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src   'self' https://fonts.gstatic.com;
  img-src    'self' data: https:;
  connect-src 'self' https://www.google-analytics.com;
  frame-ancestors 'none';
  base-uri 'self';
  form-action 'self';
  upgrade-insecure-requests

Diese Policy geht davon aus, dass du alles von deiner eigenen Domain plus Google Analytics + Google Fonts auslieferst. Fast jede WordPress-, Shopify- oder statische Website passt hier mit kleinen Anpassungen hinein. Ersetze oder entferne die GA/Fonts-Zeilen, wenn du diese nicht verwendest.

So setzt du die Policy in nginx ein

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests" always;

So setzt du die Policy in Apache ein

Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://www.googletagmanager.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; frame-ancestors 'none'; base-uri 'self'; form-action 'self'; upgrade-insecure-requests"

So setzt du die Policy in Cloudflare ein

Gehe in deinem Cloudflare-Dashboard zu Rules → Transform Rules → HTTP Response Header Modification. Füge einen Header namens Content-Security-Policy-Report-Only mit der obigen Policy als Wert hinzu. Das ist die schnellste Option, wenn du keinen Shell-Zugriff auf deinen Server hast.

So setzt du die Policy in WordPress ein

Installiere ein Header-Plugin wie Headers Security Advanced & HSTS WP oder setze die Header über dein Hosting-Panel. Vermeide es, CSP in der functions.php eines Themes zu setzen — viele Themes laden WP-Admin- oder Block-Editor-Assets dynamisch, was den Editor-Betrieb beeinträchtigt.

Häufige Stolpersteine

• Inline-Skripte. Wenn dein CMS (Content-Management-System) Inline-<script>-Tags einfügt, wirst du Verstöße sehen. Die Lösung ist entweder Nonces (am besten) oder als vorübergehende Maßnahme script-src 'self' 'unsafe-inline' — plane aber, 'unsafe-inline' innerhalb eines Sprints zu entfernen.
• Google Tag Manager. GTM lädt zur Laufzeit andere Skripte von Drittanbieter-Hosts. Erkläre diese Hosts entweder vorab in deiner Policy oder nutze GTMs eigene Custom Templates mit einer Nonce-Strategie.
• Eingebettete YouTube- / Vimeo-Videos. Füge frame-src https://www.youtube.com https://player.vimeo.com hinzu.
• Reporting-Endpunkt. Füge report-uri /csp-report oder report-to hinzu, damit du Verstöße serverseitig erfasst. Einige Hosts (Cloudflare, Sentry) bieten kostenlose CSP-Report-Endpunkte an.

Von Report-only zur Durchsetzung

Nach einer Woche im Report-only-Modus ohne neue Verstöße im echten Traffic benenne den Header von Content-Security-Policy-Report-Only in Content-Security-Policy um. Die Policy wird jetzt durchgesetzt. Behalte den Reporting-Endpunkt bei — du erkennst neue Verstöße sofort, wenn ein Plugin-Update ein unerwartetes Skript einführt.

So erkennt Scanthra das Problem

Unser Modul Security Headers sendet ein einzelnes GET an deine Startseite und liest die Response-Header. Wenn Content-Security-Policy fehlt, schwach ist oder unsafe-eval enthält, erhältst du einen Befund mit Schweregrad, verständlicher Beschreibung und einem kopierfertigen Fix — im gleichen Format wie in diesem Artikel.