Content Security Policy schrittweise einführen

Kurz gesagt

Worum es geht

Am Ende sendet deine Website eine durchgesetzte Content Security Policy (CSP), die eingeschleuste Skripte stoppt, ohne dass Besucher etwas davon merken. Warum das wirkt und welche Form von Richtlinie am meisten schützt, steht in Content Security Policy verstehen. Diese Anleitung beschreibt den Weg dorthin.

Was du brauchst

• Die Befugnis und den Zugriff, die Header deiner Website zu ändern: in der Serverkonfiguration, im Hosting-Paket, bei einem vorgeschalteten Dienst oder in der Anwendung.
• Für eine strikte Richtlinie eine Anwendung, die bei jeder Antwort eine neue Zufallszahl erzeugen und in die Seite schreiben kann. Für statische Seiten reichen Prüfsummen der Skripte.
• Eine Sicherung der bisherigen Konfiguration, am besten in einer Versionsverwaltung. Das ist dein Rückweg.
• Einige Tage Zeit für die Beobachtung, damit alle Arten von Seiten und Abläufen einmal vorkommen: Anmeldung, Bezahlung, Formulare, seltene Unterseiten.
• Wenn möglich eine Adresse, an die Browser ihre Meldungen schicken können. Ohne sie siehst du Verstöße nur in der Konsole deines eigenen Browsers.

1. Bestand aufnehmen

Schreibe auf, was deine Seite lädt und ausführt. Die Entwicklerwerkzeuge des Browsers zeigen im Netzwerk-Reiter jeden Abruf; der Quelltext der Seite zeigt den Rest.

• Eigene Skriptdateien und Skripte, die direkt im HTML stehen.
• Ereignisattribute wie onclick oder onload und Links, die mit javascript: beginnen — beide gelten als Skript im HTML.
• Fremde Dienste: Statistik, Karten, Videos, Schriften, Chat-Fenster, Bezahldienste.
• Wohin die Seite Daten schickt (Formulare, Abrufe per Skript) und ob sie in fremde Seiten eingebettet werden soll.

2. Eine Richtlinie entwerfen

Wenn deine Anwendung Nonces erzeugen kann, beginne mit einer strikten Richtlinie. Sie ist leichter zu pflegen als eine Liste von Adressen, weil neue Dienste sie nicht aufweichen.

Content-Security-Policy-Report-Only: script-src 'nonce-{NEU JE ANTWORT}' 'strict-dynamic'; object-src 'none'; base-uri 'none'; frame-ancestors 'self'; form-action 'self'; report-to csp
Reporting-Endpoints: csp="https://www.example.org/csp-meldungen"

• Kommt deine Seite ganz ohne Skripte im HTML aus und lädt nur eigene Dateien, kann auch script-src 'self' genügen.
• frame-ancestors, form-action und base-uri fallen nicht auf default-src zurück. Sie gehören immer ausdrücklich hinein.
• Die Meldeadresse muss mit https:// beginnen. Wer zusätzlich ältere Browser erfassen will, ergänzt report-uri. Dieselbe Adresse geht nur, wenn sie beide Formate annimmt, denn die beiden Wege schicken verschieden aufgebaute Meldungen (application/csp-report und application/reports+json). Wo report-to verstanden wird, ignoriert der Browser report-uri.

3. Im Beobachtungsmodus senden

Sende die Richtlinie zuerst unter dem Namen Content-Security-Policy-Report-Only. In diesem Modus blockiert der Browser nichts. Er schreibt Verstöße in die Konsole der Entwicklerwerkzeuge und schickt Meldungen an deine Adresse.

4. Verstöße beheben

• Skripte im HTML bekommen die Nonce. Lagerst du eines in eine eigene Datei aus, braucht auch das script-Element, das die Datei lädt, die Nonce — neben 'strict-dynamic' zählt 'self' nicht.
• Ereignisattribute wie onclick werden durch addEventListener im Skript ersetzt; javascript:-Links durch echte Links oder Schaltflächen.
• Code, der Text zur Laufzeit ausführt, etwa mit eval, wird umgeschrieben. Brauchst du 'unsafe-eval', ist das ein Preis, den du bewusst zahlst.
• Für fremde Dienste prüfst du, ob sie mit Nonce und 'strict-dynamic' funktionieren. Viele verbreitete Dienste tun das.
• Stile sind ein eigenes Thema: Eingeschleuste Stile können Inhalte verfälschen, sind aber meist weniger gefährlich als Skripte. Viele beginnen deshalb mit einer strengen script-src und schärfen die Stile später nach; auch Mozillas Prüfdienst HTTP Observatory zieht für 'unsafe-inline' allein bei den Stilen nichts ab.

5. Durchsetzen

Kommen nur noch Meldungen, die du erklären kannst, benenne den Header um in Content-Security-Policy. Ab jetzt blockiert der Browser. Wer weiter nachschärfen will, sendet daneben die nächste, strengere Fassung im Beobachtungsmodus — beide Header dürfen gleichzeitig stehen.

6. Nachschärfen

Nimm dir danach die Ausnahmen vor, die du am Anfang stehen gelassen hast: 'unsafe-inline' bei den Stilen, großzügige Einträge für Bilder oder Verbindungen. Jede Verschärfung geht denselben Weg: erst beobachten, dann durchsetzen.

Was du siehst

• In der Konsole der Entwicklerwerkzeuge Meldungen, dass ein Skript, Stil oder Abruf gegen die Richtlinie verstößt und beim Durchsetzen blockiert würde, mit der betroffenen Adresse und der Direktive.
• An deiner Meldeadresse Berichte im JSON-Format mit Seite, Direktive und blockierter Quelle.
• Meldungen, die gar nicht von deiner Seite stammen: Browser-Erweiterungen der Besucher schreiben eigene Skripte in fremde Seiten. Du erkennst sie an Quellen wie chrome-extension:// oder moz-extension://.

Wenn etwas nicht passt

• Nach dem Durchsetzen bricht etwas: sofort zurück in den Beobachtungsmodus, Ursache in der Konsole suchen, beheben, erneut durchsetzen.
• Eine Richtlinie, die du nicht gesetzt hast, erscheint zusätzlich: Ein vorgeschalteter Dienst sendet eine eigene. Bei zwei durchgesetzten Richtlinien müssen beide erfüllt sein; erlaubt ist also nur, was beide erlauben.
• Die Nonce ist bei mehreren Aufrufen gleich: Die Seite wurde samt Nonce zwischengespeichert. Dann schützt sie nicht — Seiten mit Nonce dürfen nicht so zwischengespeichert werden, dass verschiedene Antworten dieselbe Nonce tragen.
• Die Richtlinie steht als meta-Element im HTML: frame-ancestors, Berichte und der Beobachtungsmodus funktionieren dort nicht. Setze sie als Header.

So kehrst du zurück

Spiele die gesicherte Konfiguration zurück oder benenne den Header wieder in Content-Security-Policy-Report-Only um. Damit blockiert der Browser nichts mehr, und die Seite verhält sich wie vorher. Prüfe danach mit denselben Schritten wie unten, dass der alte Zustand wirklich ausgeliefert wird.

So prüfst du das Ergebnis

1. Kopiere die Header der Seite neu, wie in Antwort-Header richtig kopieren beschrieben, und werte sie in der Werkstatt aus.
2. Rufe die wichtigsten Abläufe selbst auf — Anmeldung, Formular, Bezahlung — und achte auf Meldungen in der Konsole.
3. Beobachte die Zahl der Meldungen einige Tage. Steigt sie nach einer Änderung an der Seite, ist etwas Neues hinzugekommen.

Was dieser Artikel nicht sagt

• Eine CSP ersetzt nicht das Beheben von Lücken. Sie verhindert, dass eingeschleustes Skript ausgeführt wird.
• Die Anleitung beschreibt den Weg, nicht die fertige Richtlinie für deine Seite. Welche Einträge du brauchst, hängt davon ab, was deine Seite lädt.
• Meldungen enthalten die aufgerufene Adresse und können damit persönliche Angaben tragen, etwa in Suchparametern. Überlege vorher, wie lange du sie aufbewahrst und wer sie sieht.

Quellen

Geprüft am 21. September 2026. Die Einordnung ist eine fachliche Bewertung, keine Rechtsberatung. Einen Fehler gefunden? Die Kontaktdaten stehen im Impressum.