Content Security Policy verstehen

Kurz gesagt

Was eine CSP tut

Einer der folgenreichsten Fehler von Websites ist Cross-Site-Scripting (XSS): Jemand schafft es, ein eigenes Skript in die Seite zu schreiben, und der Browser jedes Besuchers führt es aus. Die eigentliche Abwehr steckt im Code. Die Content Security Policy (CSP) ist die zweite Linie — sie weist den Browser an, nur bestimmte Skripte auszuführen und alle anderen zu ignorieren.

Die Richtlinie besteht aus Direktiven, jede für eine Art von Inhalt. Die wichtigsten:

Warum viele Richtlinien wenig schützen

• 'unsafe-inline' in script-src erlaubt jedes Skript, das im HTML selbst steht — also auch ein eingeschleustes. Der Schutz gegen XSS ist damit weitgehend aufgehoben.
• Platzhalter und Schemata wie *, https: oder data: erlauben Skripte von jeder Adresse beziehungsweise in jeder Form. Ein Angreifer lädt sein Skript dann einfach von dort.
• Listen erlaubter Adressen wirken strenger, als sie sind: Liegen auf einer erlaubten Adresse Skripte, die sich zweckentfremden lassen, reicht das für eine Umgehung. In einer Google-Studie von 2016 stützten sich drei von vier untersuchten Richtlinien auf Adresslisten, die sich so umgehen ließen.
• 'unsafe-eval' erlaubt, Text zur Laufzeit als Code auszuführen. Das öffnet einen zweiten Weg für eingeschleusten Code.

Die strikte CSP

Statt aufzuzählen, woher Skripte kommen dürfen, markiert eine strikte Richtlinie die erlaubten Skripte selbst. Der Server erzeugt für jede Antwort eine neue Zufallszahl, die Nonce, schreibt sie in die Richtlinie und an jedes eigene script-Element. Ein eingeschleustes Skript kennt die Zahl nicht und wird nicht ausgeführt.

Content-Security-Policy: script-src 'nonce-t7Kf2Qm9XbR4pZ1wLs8nVg==' 'strict-dynamic'; object-src 'none'; base-uri 'none'

• Die Nonce muss bei jeder Antwort neu sein, zufällig und lang genug; die Spezifikation nennt mindestens 128 Bit. Eine Nonce, die sich wiederholt, schützt nicht.
• 'strict-dynamic' erlaubt Skripten, die schon vertrauenswürdig sind, weitere Skripte nachzuladen. Dafür ignoriert der Browser Adresslisten und 'self' in script-src. Ohne Nonce oder Hash blockiert 'strict-dynamic' dagegen fast alle Skripte. Der Preis: Erzeugt ein vertrauenswürdiges Skript neue Skripte aus Daten, die ein Angreifer beeinflussen kann, lässt die Richtlinie auch diese durch. Die Spezifikation rät deshalb, 'strict-dynamic' zu meiden, wo es ohne geht; web.dev empfiehlt es als Teil der strikten CSP, weil es die Einführung erleichtert.
• Steht neben einer Nonce oder einem Hash auch 'unsafe-inline', ignorieren heutige Browser es. So lässt sich für sehr alte Browser ein Rückfall eintragen, ohne den Schutz zu schwächen.
• Für Seiten, die sich nicht bei jedem Aufruf ändern, gibt es statt der Nonce die Prüfsumme (Hash) eines Skripts.

Ein Beispiel: dieselbe Lücke, drei Richtlinien

Ein Kommentarfeld gibt Text ungeprüft aus. Jemand schreibt statt eines Kommentars ein script-Element hinein. Was passiert unter drei verschiedenen Richtlinien?

In allen drei Fällen bleibt die eigentliche Lücke bestehen: Das Kommentarfeld gibt ungeprüften Text aus. Die Richtlinie entscheidet nur, ob daraus ein ausgeführter Angriff wird.

Was du vor einer CSP brauchst

• Einen Überblick über alle Skripte, Stile, Schriften, eingebetteten Dienste und Verbindungen der Seite.
• Für eine Nonce einen Server oder eine Anwendung, die bei jeder Antwort eine neue Zufallszahl erzeugen kann. Für statische Seiten stattdessen Hashes.
• Die Richtlinie als Header, nicht als meta-Element: Im HTML-Kopf eingetragen, fehlen frame-ancestors, Berichte und der Beobachtungsmodus.
• Den Beobachtungsmodus Content-Security-Policy-Report-Only für den Anfang. Wie die Einführung Schritt für Schritt gelingt, steht in Content Security Policy schrittweise einführen.

Was dieser Artikel nicht sagt

• Eine CSP behebt keine Lücke. Sie verhindert, dass eingeschleustes Skript ausgeführt wird; die Lücke im Code bleibt und muss geschlossen werden.
• Sie schützt nicht vor allem. Eingeschleuster Text ohne Skript, täuschend echte Formulare oder Lücken auf dem Server liegen außerhalb dessen, was sie regelt.
• Sendet eine Seite zwei Richtlinien, müssen beide erfüllt sein; eine zweite kann die Regeln also nur verschärfen, nie lockern. Das überrascht oft, wenn ein vorgeschalteter Dienst eine eigene Richtlinie hinzufügt.
• Die Beispiele zeigen Grundformen. Welche Richtlinie zu einer Seite passt, hängt davon ab, was sie lädt.

Quellen

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