Content-Security-Policy (CSP): Einstieg ohne kaputte Website

Warum das wichtig ist

Bei kleinen Websites läuft ein Angriff oft so ab: Ein veraltetes Plugin hat eine Lücke, ein Bot schreibt darüber Skriptcode in die Datenbank, und ab dann lädt jede Seite Werbung oder eine Weiterleitung auf einen Fake-Shop. Der Fachbegriff dafür ist Cross-Site-Scripting, kurz XSS.

Eine CSP ist das Sicherheitsnetz für diesen Fall. Du sagst dem Browser zum Beispiel: Skripte nur von meiner eigenen Domain und vom Google Tag Manager. Ein eingeschleustes Skript von einer fremden Domain wird dann gar nicht erst geladen. Die Lücke selbst schließt die CSP nicht, das erledigen weiterhin Updates. Sie begrenzt aber den Schaden.

Zur Ehrlichkeit gehört: Eine CSP, die wirklich schützt, ist Arbeit. Gerade WordPress-Seiten mit Page Builder, Tracking und Cookie-Banner laden Code aus vielen Quellen, oft auch direkt im HTML (inline). Jede Quelle muss in die Policy, und Inline-Code verlangt Ausnahmen, die den Schutz schwächen, oder Umbauten. Rechne mit ein paar Stunden und einer Phase, in der du nachbesserst.

So prüfst du es selbst

In den Entwicklertools (F12) unter „Netzwerk“ beim ersten Eintrag nach content-security-policy suchen, oder im Terminal:

curl -sI https://example.de | grep -i content-security

Was checkfrei prüft

checkfrei sucht den Header Content-Security-Policy (oder eine Policy im Meta-Tag). Fehlt sie, gibt es eine Warnung. Eine Policy nur im Modus Report-Only reicht für den grünen Haken noch nicht, sie ist der Weg dorthin. Wie streng deine Policy ist, bewertet checkfrei nicht. Dafür eignet sich der CSP Evaluator von Google. Den Stand deiner Header zeigt der kostenlose Check.

So behebst du es

Geh in vier Schritten vor. Ein möglicher Ausgangspunkt für die Policy steht unter den Schritten, in der echten Konfiguration schreibst du alles in eine Zeile.

Im Beispiel steht bei Styles 'unsafe-inline', ein verbreiteter Kompromiss. Bei script-src solltest du es vermeiden, weil es genau den Code erlaubt, gegen den die CSP schützen soll. Für Inline-Skripte gibt es Nonces oder Hashes, das verlangt aber Eingriffe in Theme oder Anwendung. Dienste wie Google Analytics brauchen zusätzliche Einträge, welche, verrät dir die Konsole.

1. 01Policy im Modus Report-Only setzen. Der Header heißt dann Content-Security-Policy-Report-Only, der Browser blockiert nichts und meldet nur.
2. 02Die Seite gründlich durchklicken, auch Formulare, Checkout und Cookie-Banner. Die Verstöße stehen in der Browser-Konsole (F12).
3. 03Jede legitime Quelle in die Policy aufnehmen. Eine Domain, die du nicht kennst, ist ein Grund, genauer hinzusehen.
4. 04Nach ein bis zwei Wochen ohne neue Meldungen den Header in Content-Security-Policy umbenennen.

Content-Security-Policy-Report-Only:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com;
  style-src 'self' 'unsafe-inline';
  img-src 'self' data: https:;
  frame-src https://www.youtube-nocookie.com;
  frame-ancestors 'self';
  object-src 'none';
  base-uri 'self'

<IfModule mod_headers.c>
  Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'" always;

Typische Fehler

• ·Die Policy direkt scharf schalten. Dann fehlt nach dem Livegang das Kontaktformular oder der Cookie-Banner, und keiner merkt es sofort.
• ·script-src mit 'unsafe-inline' und https: als Quelle. Damit ist der Header da, schützt aber kaum noch etwas.