Was ist CSP und wie schützt es Websites?
Autor: Redaktion Domeny.ForSale Veröffentlicht
Kurz gesagt: CSP, also Content Security Policy, ist ein Sicherheitsmechanismus des Browsers. Damit lässt sich festlegen, woher eine Seite Ressourcen laden und welchen Code sie ausführen darf. CSP hilft, die Folgen von XSS einzudämmen, also des Einschleusens fremder Skripte in eine Seite. Eine entsprechende Direktive schützt außerdem davor, dass die Website in unerwünschte Frames eingebettet wird. Die Richtlinie sollte vorzugsweise über einen HTTP-Antwortheader übermittelt und zunächst getestet werden, ohne Ressourcen zu blockieren.
Wie funktioniert CSP und wovor schützt es?
Ein Browser lädt normalerweise die im Seitencode angegebenen Ressourcen: Skripte, Stylesheets, Bilder oder Schriftarten. CSP ergänzt diesen Ablauf um ein Regelwerk. Entspricht eine Ressource oder die Art der Codeausführung nicht der Richtlinie, blockiert der Browser sie und protokolliert den Verstoß in den Entwicklertools.
Der wichtigste Einsatzbereich von CSP ist die Eindämmung von XSS-Angriffen (Cross-Site Scripting). Dabei sorgt ein Angreifer dafür, dass sein Skript im Kontext einer fremden Website ausgeführt wird. Beispielsweise kann eine Schwachstelle in einem Kommentarformular das Einfügen von JavaScript-Code anstelle von gewöhnlichem Text ermöglichen. Eine ausreichend restriktive CSP kann die Ausführung dieses Codes verhindern, selbst wenn die Anwendung ihn fälschlicherweise in die Seite einfügt.
CSP hilft auch gegen Clickjacking: Dabei wird eine Seite in einen Frame eingebettet und mit einer irreführenden Ebene überlagert, um Nutzer zum Anklicken ihrer Elemente zu verleiten. Dafür ist die Direktive frame-ancestors zuständig. Regeln für Skripte allein bieten diesen Schutz nicht.
CSP behebt jedoch keine Sicherheitslücken in der Anwendung. Korrektes Kodieren von Ausgabedaten, die sichere Verarbeitung von Nutzerinhalten und Softwareupdates bleiben notwendig. Die Richtlinie bietet eine zusätzliche Schutzschicht und ersetzt diese Maßnahmen nicht.
Wo wird die CSP-Richtlinie festgelegt?
Empfohlen wird der HTTP-Antwortheader namens Content-Security-Policy. Er kann von der Anwendung, dem Webserver, einem Reverse Proxy oder einem CDN hinzugefügt werden. Der Header sollte zusammen mit dem HTML-Dokument, für das er gelten soll, beim Browser ankommen.
Einige Regeln lassen sich auch über ein meta-Tag mit dem Attribut http-equiv="Content-Security-Policy" übermitteln. Diese Lösung hat Einschränkungen: Die Richtlinie wirkt erst, nachdem das Tag eingelesen wurde. Weder der reine Berichtsmodus ohne Blockierung noch die Direktive frame-ancestors werden unterstützt. Wenn du die HTTP-Antwort konfigurieren kannst, verwende den Header.
Prüfe außerdem, ob CSP bereits von einer anderen Infrastrukturschicht hinzugefügt wird. Mehrere Richtlinien werden gleichzeitig durchgesetzt – ein weiterer Header ersetzt den vorherigen nicht automatisch. Er kann die Funktion der Seite daher zusätzlich einschränken.
Die wichtigsten Direktiven und ein Header-Beispiel
Eine Direktive ist eine einzelne Regel innerhalb der Richtlinie. Die Direktiven werden durch Semikolons getrennt. Auf ihren Namen folgen die erlaubten Quellen oder spezielle Werte.
| Direktive | Was sie steuert |
|---|---|
default-src | Standardquellen für viele Ressourcentypen, sofern keine eigene Regel für sie vorliegt |
script-src | Skriptquellen und Bedingungen für die Ausführung von JavaScript |
style-src | Quellen von Stylesheets und Regeln für eingebettete Stile |
img-src | Bildquellen |
connect-src | Verbindungen, die unter anderem über fetch und WebSocket aufgebaut werden |
object-src | Eingebettete Objekte, die über Elemente wie object eingebunden werden |
base-uri | Im Element base zulässige Adressen |
frame-ancestors | Seiten, die das Dokument in einen Frame einbetten dürfen |
Für eine einfache Website, die ausschließlich eigene Dateien verwendet, kann Folgendes als Ausgangspunkt dienen:
Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'
Der Wert 'self' steht für denselben Ursprung: Schema, Hostname und Port müssen übereinstimmen. 'none' lässt keine Quelle zu. Das obige Beispiel verbietet das Einbetten der Seite in Frames und blockiert unter anderem direkt in HTML geschriebene Skripte sowie Ereignisattribute wie onclick.
Dies ist keine universell passende Konfiguration. Nutzt die Seite einen externen Zahlungsdienst, Analysedienste oder externe Schriftarten, müssen die benötigten Quellen ermittelt und zu den passenden Direktiven hinzugefügt werden. default-src ersetzt nicht alle Regeln – beispielsweise muss frame-ancestors separat angegeben werden.
Wie führt man CSP ein, ohne die Seite versehentlich zu blockieren?
Am sichersten ist es, zunächst die tatsächlichen Abhängigkeiten der Website zu ermitteln und erst danach die Blockierung einzuschalten.
- Erfasse Ressourcen und Integrationen. Berücksichtige nicht nur die Startseite, sondern auch Anmeldung, Formulare, Zahlungen und den Nutzerbereich.
- Setze den Header
Content-Security-Policy-Report-Only. Der Browser prüft die vorgeschlagene Richtlinie und meldet Verstöße, blockiert die betreffenden Vorgänge aber nicht. Für das automatische Sammeln von Berichten müssen der Berichtsmechanismus und eine Empfangsstelle zusätzlich konfiguriert werden. - Teste vollständige Nutzerabläufe. Prüfe die Konsole und den Netzwerkbereich des Browsers. Unterscheide benötigte Ressourcen von überflüssigen Integrationen und Anfragen, die von Browsererweiterungen stammen.
- Passe Regeln und Code an. Stelle die getestete Richtlinie nach den Tests auf
Content-Security-Policyum und überwache nach der Einführung auftretende Fehler.
Beseitige Warnungen nicht, indem du unüberlegt *, 'unsafe-inline' oder 'unsafe-eval' hinzufügst. Solche Ausnahmen können den Schutz erheblich schwächen. Für notwendige eingebettete Skripte kannst du eine Nonce verwenden – einen unvorhersehbaren Wert, der für jede Antwort neu erzeugt wird – oder einen Hash, also einen Prüfwert des Inhalts eines bestimmten Skripts. Die Nonce muss im Header und im Skriptelement übereinstimmen. Ein fest in die Konfiguration eingetragener Wert erfüllt diesen Zweck nicht.
Beginne in einer Testumgebung mit einer Richtlinie im Berichtsmodus und durchlaufe den gesamten Ablauf vom Aufruf der Seite bis zum Absenden eines Formulars oder zum Abschluss eines Kaufs. So erkennst du, welche Berechtigungen tatsächlich benötigt werden, bevor CSP Ressourcen für die Nutzer blockiert.
Siehe auch: Was ist MCP?
