Content-Security-Policy (CSP)

Content-Security-Policy: <policy-directive>; <policy-directive>

wobei <policy-directive> aus folgendem besteht: <directive> <value> ohne innere Interpunktion.

Fetch-Direktiven steuern die Orte, von denen bestimmte Ressourcentypen geladen werden können.

child-src

Definiert die gültigen Quellen für Web Worker und verschachtelte Browsing-Kontexte, die mit Elementen wie <frame> und <iframe> geladen werden.

Ersatz für frame-src und worker-src.

connect-src

Beschränkt die URLs, die über Skript-Schnittstellen geladen werden können.

default-src

Dient als Ersatz für die anderen Fetch-Direktiven.

Ersatz für alle anderen Fetch-Direktiven.

fenced-frame-src Experimentell

Spezifiziert gültige Quellen für verschachtelte Browsing-Kontexte, die in <fencedframe> Elemente geladen werden.

font-src

Spezifiziert gültige Quellen für Schriften, die mit @font-face geladen werden.

frame-src

Spezifiziert gültige Quellen für verschachtelte Browsing-Kontexte, die in Elemente wie <frame> und <iframe> geladen werden.

img-src

Spezifiziert gültige Quellen für Bilder und Favicons.

manifest-src

Spezifiziert gültige Quellen für Anwendungs-Manifestdateien.

media-src

Spezifiziert gültige Quellen zum Laden von Medien über die <audio>, <video> und <track> Elemente.

object-src

Spezifiziert gültige Quellen für die <object> und <embed> Elemente.

prefetch-src Veraltet Nicht standardisiert

Spezifiziert gültige Quellen, die vorgeladen oder vorgerendert werden sollen.

script-src

Spezifiziert gültige Quellen für JavaScript- und WebAssembly-Ressourcen.

Ersatz für script-src-elem und script-src-attr.

script-src-elem

Spezifiziert gültige Quellen für JavaScript <script> Elemente.

script-src-attr

Spezifiziert gültige Quellen für JavaScript Inline-Event-Handler.

style-src

Spezifiziert gültige Quellen für Stylesheets.

Ersatz für style-src-elem und style-src-attr.

style-src-elem

Spezifiziert gültige Quellen für Stylesheets <style> Elemente und <link> Elemente mit rel="stylesheet".

style-src-attr

Spezifiziert gültige Quellen für Inline-Stile, die auf einzelne DOM-Elemente angewendet werden.

worker-src

Spezifiziert gültige Quellen für Worker, SharedWorker oder ServiceWorker Skripte.

Alle Fetch-Direktiven können den Einzelwert 'none' angeben, was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert werden soll, oder als eine oder mehrere Quellen-Ausdrucks-Werte, die gültige Quellen für diesen Ressourcentyp angeben. Siehe Fetch-Direktive-Syntax für mehr Details.

Ersatze

Einige Fetch-Direktiven funktionieren als Ersatze für andere, detailliertere Direktiven. Dies bedeutet, dass, wenn die detailliertere Direktive nicht spezifiziert wird, der Ersatz zur Bereitstellung einer Richtlinie für diesen Ressourcentyp verwendet wird.

• default-src ist ein Ersatz für alle anderen Fetch-Direktiven.
• script-src ist ein Ersatz für script-src-attr und script-src-elem.
• style-src ist ein Ersatz für style-src-attr und style-src-elem.
• child-src ist ein Ersatz für frame-src und worker-src.

Beispielsweise:

• Wenn img-src weggelassen, aber default-src eingeschlossen wird, dann wird die durch default-src definierte Richtlinie für Bilder angewendet.
• Wenn script-src-elem weggelassen, aber script-src eingeschlossen wird, dann wird die durch script-src definierte Richtlinie auf <script> Elemente angewendet.
• Wenn script-src-elem und script-src beide weggelassen werden, aber default-src eingeschlossen ist, dann wird die durch default-src definierte Richtlinie auf <script> Elemente angewendet.

Dokument-Direktiven regeln die Eigenschaften eines Dokuments oder einer Worker Umgebung, auf die eine Richtlinie angewendet wird.

base-uri

Beschränkt die URLs, die im <base> Element eines Dokuments verwendet werden können.

sandbox

Aktiviert eine Sandbox für die angeforderte Ressource, ähnlich dem <iframe> sandbox Attribut.

Navigations-Direktiven regeln, zu welchen Orten ein Benutzer navigieren oder ein Formular einsenden kann, zum Beispiel.

form-action

Beschränkt die URLs, die als Ziel einer Formularübermittlung aus einem gegebenen Kontext verwendet werden können.

frame-ancestors

Spezifiziert gültige Eltern, die eine Seite mit <frame>, <iframe>, <object> oder <embed> einbetten können.

Reporting-Direktiven steuern die Ziel-URL für CSP-Verstoßberichte in Content-Security-Policy und Content-Security-Policy-Report-Only.

report-to

Liefert dem Browser ein Token, das den Berichts-Endpunkt oder die Berichts-Endpunktgruppe identifiziert, an die Informationen über CSP-Verstöße gesendet werden sollen. Die Endpunkte, die das Token repräsentiert, werden durch andere HTTP-Header bereitgestellt, wie Reporting-Endpoints und Report-To Veraltet .

Warnung: Diese Direktive soll report-uri ersetzen; in Browsern, die report-to unterstützen, wird die report-uri Direktive ignoriert. Bis report-to jedoch breit unterstützt wird, sollten Sie beide Header wie gezeigt angeben (wobei endpoint_name der Name eines separat bereitgestellten Endpunkts ist):

http

Content-Security-Policy: …; report-uri https://endpoint.example.com; report-to endpoint_name

require-trusted-types-for Experimentell

Erzwingt Trusted Types an den DOM XSS-Injektionsstellen.

trusted-types Experimentell

Wird verwendet, um eine Positivliste von Trusted Types Richtlinien anzugeben. Trusted Types ermöglichen es Anwendungen, DOM XSS-Injektionsstellen so zu sperren, dass nur nicht manipulierbare, typisierte Werte anstelle von Zeichenfolgen akzeptiert werden.

upgrade-insecure-requests

Weist Benutzeragenten an, alle unsicheren URLs einer Website (die über HTTP bereitgestellt werden) so zu behandeln, als wären sie mit sicheren URLs (die über HTTPS bereitgestellt werden) ersetzt worden. Diese Direktive ist für Websites mit einer großen Anzahl unsicherer alter URLs gedacht, die umgeschrieben werden müssen.

block-all-mixed-content Veraltet

Verhindert das Laden von Assets über HTTP, wenn die Seite über HTTPS geladen wird.

report-uri Veraltet

Bietet dem Browser eine URL, an die CSP-Verstoßberichte gesendet werden sollen. Dies wurde durch die report-to Direktive ersetzt.

Alle Fetch-Direktiven können wie folgt angegeben werden:

• den Einzelwert 'none', was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert werden soll
• ein oder mehrere Quellen-Ausdrucks-Werte, die gültige Quellen für diesen Ressourcentyp angeben.

Jeder Quellen-Ausdruck nimmt eine der unten aufgeführten Formen an. Beachten Sie, dass nicht alle Formen für alle Fetch-Direktiven anwendbar sind: siehe die Dokumentation für jede Fetch-Direktive, um herauszufinden, welche Formen anwendbar sind.

Die <host-source> und <scheme-source> Formate müssen unverpackt sein, und alle anderen Formate müssen in einfache Anführungszeichen eingeschlossen sein.

Dieser Wert besteht aus dem String nonce-, gefolgt von einem Base64-kodierten String. Dieser String ist ein zufälliger Wert, den der Server für jede HTTP-Antwort generiert. Zum Beispiel:

'nonce-416d1177-4d12-4e3b-b7c9-f6c409789fb8'

Der Server kann dann denselben Wert als Wert des nonce Attributes von <script> oder <style> Ressourcen aufnehmen, die sie aus dem Dokument laden möchten.

Der Browser vergleicht den Wert aus der CSP-Direktive mit dem Wert im Elementattribut und lädt die Ressource nur, wenn sie übereinstimmen.

Wenn eine Direktive ein Nonce und unsafe-inline enthält, ignoriert der Browser unsafe-inline.

Siehe Nonces im CSP-Leitfaden für weitere Informationen zur Verwendung.

Dieser Wert besteht aus einem String, der einen Hash-Algorithmus identifiziert, gefolgt von -, gefolgt von einem Base64-kodierten String, der den Hash-Wert darstellt.

• Der Hash-Algorithmus-Identifier muss einer der folgenden sein: sha256, sha384 oder sha512.
• Der Hash-Wert ist der Base64-kodierte Hash einer <script> oder <style> Ressource, berechnet mit einer der folgenden Hash-Funktionen: SHA-256, SHA-384 oder SHA-512.

Zum Beispiel:

'sha256-cd9827ad...'

Wenn der Browser das Dokument empfängt, hashiert er den Inhalt aller <script> und <style> Elemente, vergleicht das Ergebnis mit allen Hashes in der CSP-Direktive und lädt die Ressource nur, wenn es eine Übereinstimmung gibt.

Wenn das Element eine externe Ressource lädt (zum Beispiel mit dem src Attribut), muss das Element auch das integrity Attribut gesetzt haben.

Wenn eine Direktive einen Hash und unsafe-inline enthält, ignoriert der Browser unsafe-inline.

Siehe Hashes im CSP-Leitfaden für weitere Informationen zur Verwendung.

Die URL oder IP-Adresse eines Host, der eine gültige Quelle für die Ressource darstellt.

Das Schema, die Portnummer und der Pfad sind optional.

Wenn das Schema weggelassen wird, wird das Schema des Ursprungs des Dokuments verwendet.

Beim Abgleichen von Schemata sind sichere Upgrades erlaubt. Zum Beispiel:

• http://example.com erlaubt auch Ressourcen von https://example.com
• ws://example.org erlaubt auch Ressourcen von wss://example.org.

Wildcards ('*') können für Subdomains, Host-Adressen und Portnummern verwendet werden, was bedeutet, dass alle legalen Werte von jedem gültig sind. Zum Beispiel:

• http://*.example.com erlaubt Ressourcen von beliebigen Subdomains von example.com, über HTTP oder HTTPS.

Pfade, die mit / enden, stimmen mit allen Pfaden überein, deren Präfix sie sind. Zum Beispiel:

• example.com/api/ erlaubt Ressourcen von example.com/api/users/new.

Pfade, die nicht mit / enden, werden genau verglichen. Zum Beispiel:

• https://example.com/file.js erlaubt Ressourcen von https://example.com/file.js aber nicht https://example.com/file.js/file2.js.

Ein Schema, wie https:. Der Doppelpunkt ist erforderlich.

Sichere Upgrades sind erlaubt, also:

• http: erlaubt auch Ressourcen, die über HTTPS geladen werden
• ws: erlaubt auch Ressourcen, die über WSS geladen werden.

Ressourcen des angegebenen Typs dürfen nur aus dem gleichen Ursprung wie das Dokument geladen werden.

Sichere Upgrades sind erlaubt. Zum Beispiel:

• Wenn das Dokument von http://example.com bereitgestellt wird, erlaubt eine CSP von 'self' auch Ressourcen von https://example.com.
• Wenn das Dokument von ws://example.org bereitgestellt wird, erlaubt eine CSP von 'self' auch Ressourcen von wss://example.org.

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, sind JavaScript-Funktionen, die ihre Argumente als JavaScript auswerten, deaktiviert. Dies schließt eval(), das code Argument von setTimeout() oder den Function() Konstruktor ein.

Das unsafe-eval Schlüsselwort kann verwendet werden, um diesen Schutz rückgängig zu machen und die dynamische Auswertung von Strings als JavaScript zu erlauben.

Siehe eval() und ähnliche APIs im CSP-Leitfaden für weitere Informationen zur Verwendung.

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, darf eine Seite WebAssembly nicht mit Funktionen wie WebAssembly.compileStreaming() kompilieren.

Das wasm-unsafe-eval Schlüsselwort kann verwendet werden, um diesen Schutz rückgängig zu machen. Dies ist eine viel sicherere Alternative zu 'unsafe-eval', da es keine allgemeine Auswertung von JavaScript ermöglicht.

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, darf Inline-JavaScript nicht ausgeführt werden. Dies schließt ein:

• Inline-<script>-Tags
• Inline-Event-Handler-Attribute
• javascript: URLs.

Ebenso, wenn eine CSP default-src oder eine style-src Direktive enthält, wird Inline-CSS nicht geladen, einschließlich:

• Inline-<style>-Tags
• style Attribute.

Das unsafe-inline Schlüsselwort kann verwendet werden, um diesen Schutz rückgängig zu machen und alle diese Formulare zu laden.

Siehe Inline-JavaScript im CSP-Leitfaden für weitere Informationen zur Verwendung.

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, dürfen Inline-Event-Handler-Attribute wie onclick und Inline-style-Attribute nicht ausgeführt werden.

Der 'unsafe-hashes' Ausdruck erlaubt dem Browser die Nutzung von Hash-Ausdrücken für Inline-Event-Handler und style-Attribute. Zum Beispiel könnte eine CSP eine Direktive enthalten wie:

script-src 'unsafe-hashes' 'sha256-cd9827ad...'

Wenn der Hash-Wert mit dem Hash eines Inline-Event-Handler-Attributwerts oder eines style-Attributwerts übereinstimmt, wird der Code ausgeführt.

<button onclick="transferAllMyMoney()">Transfer all my money</button>

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, darf Inline-JavaScript nicht ausgeführt werden. Die 'inline-speculation-rules' erlaubt dem Browser, Inline-<script>-Elemente zu laden, die ein type Attribut von speculationrules haben.

Siehe die Speculation Rules API für weitere Informationen.

Das 'strict-dynamic' Schlüsselwort erweitert das Vertrauen, das auf ein Skript durch einen Nonce oder einen Hash übertragen wird, auf Skripte, die dieses Skript dynamisch lädt, zum Beispiel durch Erstellen neuer <script>-Tags mit Document.createElement() und anschließendes Einfügen in das Dokument mit Node.appendChild().

Wenn dieses Schlüsselwort in einer Direktive vorhanden ist, werden die folgenden Quellausdruckswerte alle ignoriert:

• <host-source>
• <scheme-source>
• 'self'
• 'unsafe-inline'

Siehe Das strict-dynamic Schlüsselwort im CSP-Leitfaden für weitere Informationen zur Verwendung.

Wenn dieser Ausdruck in einer Direktive enthalten ist, die Skripte oder Stile kontrolliert, und die Direktive dazu führt, dass der Browser Inline-Skripte, Inline-Stile oder Event-Handler-Attribute blockiert, dann enthält der Verstoßbericht, den der Browser generiert, eine sample Eigenschaft mit den ersten 40 Zeichen der blockierten Ressource.

Worker werden im Allgemeinen nicht durch die Content-Security-Policy des Dokuments (oder des übergeordneten Workers) geregelt, das sie erstellt hat. Um eine Content-Security-Policy für den Worker zu spezifizieren, setzen Sie einen Content-Security-Policy Antwort-Header für die Anfrage, die das Worker-Skript selbst angefordert hat.

Die Ausnahme ist, wenn der Ursprung des Worker-Skripts ein global eindeutiger Bezeichner ist (zum Beispiel, wenn seine URL ein Schema von "data" oder "blob" hat). In diesem Fall erbt der Worker die Content-Security-Policy des Dokuments oder Workers, der ihn erstellt hat.

Der CSP-Mechanismus erlaubt mehrere Richtlinien, die für eine Ressource spezifiziert werden können, einschließlich über den Content-Security-Policy Header, den Content-Security-Policy-Report-Only Header und ein <meta> Element.

Sie können den Content-Security-Policy Header mehr als einmal verwenden, wie im folgenden Beispiel. Achten Sie besonders auf die connect-src Direktive hier. Selbst wenn die zweite Richtlinie die Verbindung zulassen würde, enthält die erste Richtlinie connect-src 'none'. Das Hinzufügen zusätzlicher Richtlinien kann nur weiter die Fähigkeiten der geschützten Ressource einschränken, was bedeutet, dass keine Verbindung erlaubt ist und, als die strengste Richtlinie, connect-src 'none' durchgesetzt wird.

Content-Security-Policy: default-src 'self' http://example.com;
                          connect-src 'none';
Content-Security-Policy: connect-src http://example.com/;
                          script-src http://example.com/

Dieser HTTP-Header setzt die Standardrichtlinie, um nur das Laden von Ressourcen (Bilder, Schriftarten, Skripte usw.) über HTTPS zu erlauben. Da die Direktiven unsafe-inline und unsafe-eval nicht gesetzt sind, werden Inline-Skripte blockiert.

Content-Security-Policy: default-src https:

Die gleichen Einschränkungen können unter Verwendung des HTML <meta> Elements angewendet werden.

<meta http-equiv="Content-Security-Policy" content="default-src https:" />

Diese Richtlinie könnte auf einer bereits bestehenden Seite verwendet werden, die zu viel Inline-Code verwendet, um sie zu beheben. Sie stellt sicher, dass Ressourcen nur über HTTPS geladen werden und deaktiviert Plugins:

Content-Security-Policy: default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'

Dieses Beispiel setzt die gleichen Einschränkungen wie das vorherige Beispiel, verwendet jedoch den Content-Security-Policy-Report-Only Header und die report-to Direktive. Dieser Ansatz wird während der Tests verwendet, um Verstöße zu melden, aber den Code nicht daran zu hindern, ausgeführt zu werden.

Endpunkte (URLs), an die Berichte gesendet werden sollen, werden mit dem Reporting-Endpoints HTTP-Antwort-Header definiert.

Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"

Ein bestimmter Endpunkt wird dann als Berichtsziel in der CSP Richtlinie unter Verwendung der report-to Direktive ausgewählt.

Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-url/; report-to csp-endpoint

Beachten Sie, dass die report-uri Veraltet Direktive oben ebenfalls angegeben ist, da report-to noch nicht umfassend von Browsern unterstützt wird.

Siehe Content Security Policy (CSP) Implementierung für weitere Beispiele.

• Content-Security-Policy-Report-Only
• Lernen über: Content Security Policy
• Content Security in WebExtensions
• Übernahme einer strikten Richtlinie
• CSP Evaluator - Bewerten Sie Ihre Content Security Policy