Content-Security-Policy (CSP) header

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

wobei <policy-directive> aus: <directive> <value> ohne interne Zeichensetzung besteht.

Fetch-Direktiven steuern die Orte, von denen bestimmte Ressourcentypen geladen werden dürfen.

child-src

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

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

connect-src

Beschränkt die URLs, die über Skriptschnittstellen geladen werden können.

default-src

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

Fallback für alle anderen Fetch-Direktiven.

fenced-frame-src Experimentell

Gibt gültige Quellen für eingebettete Browsing-Kontexte an, die in <fencedframe> Elementen geladen werden.

font-src

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

frame-src

Gibt gültige Quellen für eingebettete Browsing-Kontexte an, die in Elementen wie <frame> und <iframe> geladen werden.

img-src

Gibt gültige Quellen für Bilder und Favicons an.

manifest-src

Gibt gültige Quellen für Anwendungsmanifestdateien an.

media-src

Gibt gültige Quellen für das Laden von Medien mit den <audio>, <video> und <track> Elementen an.

object-src

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

prefetch-src Veraltet Nicht standardisiert

Gibt gültige Quellen an, die vorab abgerufen oder vorgerendert werden sollen.

script-src

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

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

script-src-elem

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

script-src-attr

Gibt gültige Quellen für JavaScript Inline-Ereignishandler an.

style-src

Gibt gültige Quellen für Stylesheets an.

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

style-src-elem

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

style-src-attr

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

worker-src

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

Alle Fetch-Direktiven können mit dem einzigen Wert 'none' angegeben werden, was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert werden sollte, oder als eine oder mehrere Quellausdrücke, die gültige Quellen für diesen Ressourcentyp angeben. Einzelheiten siehe Fetch-Direktiven-Syntax.

Fallbacks

Einige Fetch-Direktiven fungieren als Fallbacks für andere, granularere Direktiven. Das bedeutet, wenn die granularere Direktive nicht angegeben ist, wird der Fallback verwendet, um eine Richtlinie für diesen Ressourcentyp bereitzustellen.

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

Beispiel:

• Wenn img-src weggelassen wird, aber default-src enthalten ist, wird die von default-src definierte Richtlinie auf Bilder angewendet.
• Wenn script-src-elem weggelassen wird, aber script-src enthalten ist, wird die von script-src definierte Richtlinie auf <script>-Elemente angewendet.
• Wenn script-src-elem und script-src beide weggelassen werden, aber default-src enthalten ist, wird die von default-src definierte Richtlinie auf <script>-Elemente angewendet.

Dokumentdirektiven 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.

Navigationsrichtlinien regeln, zu welchen Orten ein Benutzer navigieren oder ein Formular absenden kann, zum Beispiel.

form-action

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

frame-ancestors

Spezifiziert zulässige Elternelemente, die eine Seite mithilfe von <frame>, <iframe>, <object> oder <embed> einbetten dürfen.

Berichtsdirektiven steuern die Ziel-URL für CSP-Verletzungsberichte in Content-Security-Policy und Content-Security-Policy-Report-Only.

report-to

Versorgt den Browser mit einem Token, das den Berichtsendpunkt oder eine Gruppe von Endpunkten identifiziert, an die Informationen über CSP-Verletzungen gesendet werden. Die Endpunkte, die das Token repräsentiert, werden über 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. Allerdings sollten Sie, bis report-to weitgehend unterstützt wird, beide Header angeben, wie gezeigt (wobei endpoint_name der Name eines separat bereitgestellten Endpunkts ist):

httpCopy to Clipboard

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

require-trusted-types-for

Erzwingt Trusted Types an den DOM XSS-Injektionsstellen.

trusted-types

Wird verwendet, um eine Positivliste von Trusted Types Richtlinien zu spezifizieren. Trusted Types ermöglicht es Anwendungen, DOM XSS-Injektionsstellen zu sperren, sodass nur nicht fälschbare, typisierte Werte anstelle von Strings 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 durch sichere URLs (die über HTTPS bereitgestellt werden) ersetzt worden. Diese Direktive ist für Websites mit einer großen Anzahl unsicherer Legacy-URLs vorgesehen, 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

Versorgt den Browser mit einer URL, an die CSP-Verletzungsberichte gesendet werden sollten. Diese wird durch die report-to Direktive ersetzt.

Alle Fetch-Direktiven können als eine der folgenden angegeben werden:

• der einzelne Wert 'none', was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert werden soll
• ein oder mehrere Quellausdrücke, die gültige Quellen für diesen Ressourcentyp angeben.

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

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

Dieser Wert besteht aus dem String nonce- gefolgt von einem Nonce-Wert. Der Nonce-Wert kann beliebige Zeichen aus Base64 oder URL-sicherem Base64 verwenden.

Dieser String ist ein Zufallswert, den der Server für jede HTTP-Antwort generiert. Beispiel:

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

Der Server kann dann denselben Wert als Wert des nonce Attributs für alle <script> oder <style> Ressourcen einschließen, die sie aus dem Dokument laden möchten.

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

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

Einzelheiten siehe Nonces im CSP-Leitfaden.

Dieser Wert besteht aus einem String, der einen Hash-Algorithmus identifiziert, gefolgt von -, gefolgt von einem Hash-Wert. Der Hash-Wert kann beliebige Zeichen aus Base64 oder URL-sicherem Base64 verwenden.

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

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 über das src Attribut), dann muss das Element auch das integrity Attribut haben.

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

Einzelheiten siehe Hashes im CSP-Leitfaden.

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

Das Schema, die Portnummer und der Pfad sind optional.

Wenn das Schema weggelassen wird, wird das Schema des Ursprungsdokuments verwendet.

Beim Abgleichen von Schemas sind sichere Upgrades erlaubt. Beispiel:

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

Platzhalter ('*') können für Subdomänen, Hostadressen und Portnummern verwendet werden, was bedeutet, dass alle legalen Werte von jedem gültig sind. Beispiel:

• http://*.example.com erlaubt Ressourcen von allen Subdomänen von example.com, über HTTP oder HTTPS.

Pfade, die mit / enden, stimmen mit jedem Pfad überein, von dem sie ein Präfix sind. Beispiel:

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

Pfade, die nicht mit / enden, werden genau übereinstimmend. 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.

Gesicherte 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 vom selben Ursprung wie das Dokument geladen werden.

Gesicherte Upgrades sind erlaubt. 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, werden JavaScript-Funktionen, die ihre Argumente als JavaScript auswerten, deaktiviert. Dies schließt eval(), das code Argument zu setTimeout() oder den Function()-Konstruktor ein.

Das unsafe-eval Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben und das dynamische Auswerten von Strings als JavaScript zu ermöglichen.

Einzelheiten siehe eval() und ähnliche APIs im CSP-Leitfaden.

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

Das wasm-unsafe-eval Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben. 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 umfasst:

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

Ähnlich, 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 aufzuheben, was das Laden all dieser Formen ermöglicht.

Einzelheiten siehe Inline-JavaScript im CSP-Leitfaden.

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

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

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

Wenn der Hashwert mit dem Hash eines Inline-Ereignishandler-Attributwertes oder eines style-Attributwertes übereinstimmt, wird der Code ausgeführt.

<button onclick="transferAllMyMoney()">Transferiere all mein Geld</button>

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

Einzelheiten siehe Speculation Rules API für mehr Informationen.

Das 'strict-dynamic' Schlüsselwort erweitert das Vertrauen, das einem Skript durch einen Nonce oder einen Hash gegeben wird, auf Skripte, die dieses Skript dynamisch lädt, z. B. durch das Erstellen neuer <script>-Tags mittels Document.createElement() und deren Einfügen in das Dokument mittels Node.appendChild().

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

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

Einzelheiten siehe Das strict-dynamic Schlüsselwort im CSP-Leitfaden.

Wenn dieser Ausdruck in einer Direktive enthalten ist, die Skripte oder Stile steuert, und die Direktive dazu führt, dass der Browser Inline-Skripte, Inline-Stile oder Ereignishandler-Attribute blockiert, enthält der von ihm generierte Verletzungsbericht eine sample Eigenschaft mit den ersten 40 Zeichen der blockierten Ressource.

Worker sind im Allgemeinen nicht durch die Content-Security-Policy des Dokuments (oder des Eltern-Workers) geregelt, der sie erzeugt hat. Um eine Content-Security-Policy für den Worker festzulegen, setzen Sie einen Content-Security-Policy Antwort-Header für die Anforderung, die das Worker-Skript selbst angefordert hat.

Die Ausnahme hiervon 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 des Workers, der ihn erzeugt hat.

Der CSP-Mechanismus ermöglicht es, mehrere Richtlinien für eine Ressource anzugeben, 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 Beispiel unten gezeigt. Achten Sie besonders auf die connect-src Direktive hier. Auch wenn die zweite Policy die Verbindung erlauben würde, enthält die erste Policy connect-src 'none'. Das Hinzufügen zusätzlicher Richtlinien kann nur die Fähigkeiten der geschützten Ressource weiter einschränken, was bedeutet, dass keine Verbindung erlaubt ist und die strengste Policy, 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 so, dass das Laden von Ressourcen (Bilder, Schriftarten, Skripte etc.) nur über HTTPS erlaubt ist. Da die Direktiven unsafe-inline und unsafe-eval nicht gesetzt sind, werden Inline-Skripte blockiert.

Content-Security-Policy: default-src https:

Dieselben Einschränkungen können mit dem HTML <meta> Element angewendet werden.

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

Diese Richtlinie könnte auf einer bestehenden Website verwendet werden, die zu viel Inline-Code verwendet, um sie zu beheben, um sicherzustellen, dass Ressourcen nur über HTTPS geladen und Plugins deaktiviert werden:

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

Dieses Beispiel setzt dieselben 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 des Testens verwendet, um Verstöße zu melden, aber das Ausführen von Code nicht zu blockieren.

Endpunkte (URLs) zum Senden von Berichten werden mit dem Reporting-Endpoints HTTP-Antwort-Header definiert.

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

Ein bestimmter Endpunkt wird dann als Berichtsziele im CSP-Policy mittels 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 auch die report-uri Veraltet Direktive oben angegeben ist, weil report-to noch nicht allgemein von Browsern unterstützt wird.

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

• Content-Security-Policy-Report-Only
• Erfahren Sie mehr über: Content Security Policy
• Content Security in WebExtensions
• Annahme einer strikten Richtlinie
• CSP Evaluator - Evaluieren Sie Ihre Content Security Policy