Was ist eine Content Security Policy?

Einfach erklärt

Die Content Security Policy, kurz CSP, ist eine Liste, die Ihre Website dem Browser mitgibt: Von welchen Adressen dürfen Skripte, Schriften, Bilder und andere Bestandteile geladen werden? Was nicht auf der Liste steht, lädt und startet der Browser nicht. Das ist wie eine Gästeliste an der Tür: Wer nicht draufsteht, kommt nicht hinein, auch wenn er es bis zur Tür geschafft hat.

Warum das wichtig ist

Eine bekannte Angriffsart ist eingeschleuster Code. Ein Angreifer bringt etwa über ein Formularfeld, einen Kommentar oder eine unsichere Erweiterung ein Skript in Ihre Seite. Das Skript läuft dann im Browser Ihrer Besucher, liest Eingaben mit oder leitet auf fremde Seiten um. Fachleute nennen das Cross-Site Scripting. Eine gute CSP verhindert, dass solcher Code ausgeführt wird, selbst wenn er schon in der Seite steht.

Was Sie tun können

Eine CSP wird für jede Website eigens geschrieben, denn sie muss alles erlauben, was die Seite wirklich braucht: Statistik, Schriften, Karten, Videos, das Cookie-Banner. Deshalb führt man sie in zwei Schritten ein:

1. Zuerst läuft sie im Testbetrieb. Der Browser meldet Verstöße, blockiert aber nichts.
2. Erst wenn keine echten Verstöße mehr auftauchen, wird sie scharf geschaltet.

Bitten Sie die Firma, die Ihre Website betreut, um genau dieses Vorgehen.

Achtung: Eine CSP, die Skripte von überall erlaubt, steht zwar im Header, schützt aber nicht. Gesetzt heißt noch nicht wirksam.

Was eine CSP nicht leistet

Eine CSP behebt keine Lücke. Sie verhindert nur, dass eine bestimmte Art von Lücke ausgenutzt wird. Gegen Fehler auf dem Server, gestohlene Passwörter oder veraltete Software hilft sie nicht.

Anweisungen

Die CSP beschreibt der W3C-Entwurf Content Security Policy Level 3. Sie besteht aus Anweisungen mit erlaubten Quellen:

Content-Security-Policy: default-src 'self'; script-src 'nonce-r4nd0m' 'strict-dynamic'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; report-to csp
Reporting-Endpoints: csp="https://ihre-firma.de/csp-berichte"

• default-src gilt für jede Ressourcenart ohne eigene Anweisung.
• Ein Nonce muss bei jeder Antwort neu und unvorhersehbar erzeugt werden. Ein fester Wert im Template schützt nicht, denn ein Angreifer kann ihn ablesen und mitschicken.
• script-src ist der wichtigste Teil. 'unsafe-inline' erlaubt jedes eingebettete Skript und hebt den Schutz gegen XSS weitgehend auf. Steht daneben ein Nonce oder Hash, ignorieren Browser ab CSP Level 2 das 'unsafe-inline'.
• 'strict-dynamic' überträgt das Vertrauen eines Skripts mit Nonce oder Hash auf die Skripte, die es nachlädt. Allowlisten wie 'self' werden dann ignoriert.
• frame-ancestors, report-uri und sandbox wirken nicht im <meta>-Tag.
• report-uri ist zugunsten von report-to abgekündigt.

Einführung im Testmodus

1. Die geplante Richtlinie als Content-Security-Policy-Report-Only setzen. Der Browser meldet Verstöße, verhindert aber nichts.
2. Berichte auswerten, fehlende Quellen ergänzen, eingebettete Skripte auf Nonces oder Hashes umstellen.
3. Auf den Header Content-Security-Policy umstellen. Beide Header dürfen eine Zeit lang nebeneinander stehen, etwa um eine strengere Fassung zu testen.

Typische Fehler

• script-src mit *, https: oder data:. Skripte von beliebigen Adressen sind erlaubt.
• 'unsafe-inline' ohne Nonce oder Hash. Die Richtlinie begrenzt Herkünfte, lässt eingeschleuste Inline-Skripte aber durch.
• Dauerhaft Report-Only. Meldet, schützt aber nicht.
• base-uri vergessen. Die Anweisung fällt nicht auf default-src zurück. Ohne sie kann ein eingeschleustes <base> relative Skriptpfade auf einen fremden Server umbiegen.
• Große CDNs in der Allowlist. Wer cdn.jsdelivr.net erlaubt, erlaubt jedes Skript, das dort liegt.

Prüfen

curl -sI https://ihre-firma.de/ | grep -i -E '^content-security-policy'

Der CSP Evaluator von Google bewertet eine Richtlinie. Verstöße zeigt die Konsole der Entwicklerwerkzeuge im Browser (F12).