Content-Security-Policy (CSP) header

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

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

Fetch-Direktiven kontrollieren, von welchen Standorten 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 mittels Skript-Schnittstellen 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>-Elemente 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 Elemente 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 Anwendungsmanifest-Dateien 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 vorgeladen 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-Event-Handler 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 <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 Einzelwert 'none' spezifiziert werden, was anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden sollte, oder als ein oder mehrere Quell-Ausdrücke, die gültige Quellen für diesen Ressourcentyp angeben. Siehe Fetch-Direktive-Syntax für weitere Details.

Fallbacks

Einige Fetch-Direktiven fungieren als Fallbacks für andere, detailliertere Direktiven. Das bedeutet, dass, wenn die detailliertere Direktive nicht spezifiziert ist, der Fallback verwendet wird, 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.

Zum Beispiel:

• Wenn img-src weggelassen wird, aber default-src enthalten ist, dann wird die von default-src definierte Richtlinie auf Bilder angewendet.
• Wenn script-src-elem weggelassen wird, aber script-src enthalten ist, dann 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, dann wird die von default-src definierte Richtlinie auf <script>-Elemente angewendet.

Dokument-Direktiven regeln die Eigenschaften eines Dokuments oder Workers, auf das 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 Standorten ein Nutzer navigieren oder ein Formular senden 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

Gibt gültige Eltern an, die eine Seite mit <frame>, <iframe>, <object>, oder <embed> einbetten dürfen.

Berichterstattungs-Direktiven kontrollieren die Ziel-URL für CSP-Verletzungsberichte in Content-Security-Policy und Content-Security-Policy-Report-Only.

report-to

Stellt dem Browser ein Token zur Verfügung, das den Berichtsendpunkt oder die Gruppe von Endpunkten identifiziert, an die CSP-Verletzungsinformationen gesendet werden sollen. Die Endpunkte, die das Token darstellt, 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. Bis report-to jedoch breit unterstützt wird, sollten Sie beide Header angeben, wie gezeigt (wo 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

Erzwingt Trusted Types an den DOM-XSS-Injektionsstellen.

trusted-types

Wird verwendet, um eine Whitelist von Trusted Types Richtlinien zu spezifizieren. Trusted Types ermöglicht es Anwendungen, DOM-XSS-Injektionsstellen zu sperren, um nur nicht manipulierbare, getypte Werte anstelle von Zeichenfolgen zu akzeptieren.

upgrade-insecure-requests

Weist User-Agents an, alle unsicheren URLs einer Seite (solche, 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 gedacht, die umgeschrieben werden müssen.

block-all-mixed-content Veraltet

Verhindert das Laden von Assets, die HTTP verwenden, wenn die Seite mit HTTPS geladen wird.

report-uri Veraltet

Stellt dem Browser eine URL zur Verfügung, an die CSP-Verletzungsberichte gesendet werden sollen. Dies wurde durch die report-to-Direktive ersetzt.

Alle Fetch-Direktiven können als einer der folgenden Werte spezifiziert werden:

• der Einzelwert 'none', der anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden sollte
• ein oder mehrere Quell-Ausdrücke, die gültige Quellen für diesen Ressourcentyp angeben.

Jeder Quell-Ausdruck 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 zutreffend sind.

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

Dieser Wert besteht aus der Zeichenfolge nonce-, gefolgt von einem Nonce-Wert. Der Nonce-Wert darf alle Zeichen aus Base64 oder URL-sicherem Base64 verwenden.

Diese Zeichenfolge 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 den Wert des nonce-Attributs für alle <script> oder <style>-Ressourcen einfügen, die sie aus dem Dokument laden möchten.

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

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

Siehe Nonces im CSP-Leitfaden für weitere Nutzungshinweise.

Dieser Wert besteht aus einer Zeichenfolge, die einen Hash-Algorithmus identifiziert, gefolgt von -, gefolgt von einem Hash-Wert. Der Hash-Wert darf alle Zeichen aus Base64 oder URL-sicherem Base64 verwenden.

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

Zum Beispiel:

'sha256-cd9827ad...'

Wenn der Browser das Dokument empfängt, hasht er den Inhalt sämtlicher <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 durch das 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 Nutzungshinweise.

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 Ursprungs des Dokuments verwendet.

Beim Vergleich von Schemen 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, Hostadresse und Portnummer verwendet werden und geben an, dass alle rechtmäßigen Werte davon gültig sind. Zum Beispiel:

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

Pfade, die mit / enden, stimmen mit jedem Pfad überein, zu dem sie ein Präfix 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, so dass:

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

Ressourcen des angegebenen Typs dürfen nur aus demselben 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, dann 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 aufzuheben, und ermöglicht die dynamische Auswertung von Zeichenfolgen als JavaScript.

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

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 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 beinhaltet:

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

Ähnlich, wenn eine CSP eine 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 und alle diese Formen zu laden.

Siehe Inline JavaScript im CSP-Leitfaden für weitere Nutzungshinweise.

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

Der 'unsafe-hashes' Ausdruck erlaubt es dem Browser, Hash-Ausdrücke für Inline-Event-Handler und style Attribute zu verwenden. Zum Beispiel könnte eine CSP eine Direktive wie diese enthalten:

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 werden dürfen.

<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. Der 'inline-speculation-rules' erlaubt es 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 durch einen Nonce oder einen Hash verliehene Vertrauen auf Skripte, die dieses Skript dynamisch lädt, zum Beispiel durch Erstellen neuer <script> Tags mit Document.createElement() und deren Einfügen in das Dokument mit Node.appendChild().

Wenn dieses Schlüsselwort in einer Direktive vorhanden ist, werden die folgenden Quell-Ausdrücke alle ignoriert:

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

Siehe Das strict-dynamic Schlüsselwort im CSP-Leitfaden für weitere Nutzungshinweise.

Wenn dieser Ausdruck in einer Direktive enthalten ist, die Skripte oder Styles kontrolliert, und die Direktive dazu führt, dass der Browser irgendwelche Inline-Skripte, Inline-Stile oder Event-Handler Attribute blockiert, dann wird der Verletzungsbericht, den der Browser generiert, eine sample Eigenschaft enthalten, die die ersten 40 Zeichen der blockierten Ressource umfasst.

Worker werden im Allgemeinen nicht von der Inhalts-Sicherheitsrichtlinie des Dokuments (oder des übergeordneten Workers), das sie erstellt hat, geregelt. Um eine Inhalts-Sicherheitsrichtlinie für den Worker anzugeben, 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 übernimmt der Worker die Inhalts-Sicherheitsrichtlinie des Dokuments oder des Workers, der ihn erstellt hat.

Der CSP-Mechanismus ermöglicht es, mehrere Richtlinien für eine Ressource zu spezifizieren, 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 untenstehenden Beispiel. Achten Sie besonders auf die connect-src Direktive hier. Selbst wenn die zweite Richtlinie die Verbindung erlauben würde, enthält die erste Richtlinie connect-src 'none'. Die Hinzufügung zusätzlicher Richtlinien kann nur die Fähigkeiten der geschützten Ressource weiter einschränken, was bedeutet, dass keine Verbindung erlaubt wird, und somit wird als strengste Richtlinie connect-src 'none' erzwungen.

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 das Laden von Ressourcen (Bilder, Schriften, Skripte, etc.) nur über HTTPS zuzulassen. Da die unsafe-inline und unsafe-eval Direktiven nicht gesetzt sind, werden Inline-Skripte blockiert.

Content-Security-Policy: default-src https:

Die gleichen Einschränkungen können mit dem HTML <meta>-Element angewandt 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 diesen zu beheben, um sicherzustellen, dass Ressourcen nur über HTTPS geladen werden und Plugins deaktiviert werden:

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 des Testens verwendet, um Verstöße zu melden, aber nicht zu blockieren, dass Code ausgeführt wird.

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

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

Ein bestimmter Endpunkt wird dann als Berichts-Ziel in der CSP-Richtlinie mit 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 ebenfalls oben angegeben ist, da report-to noch nicht von allen Browsern breit unterstützt wird.

Sehen Sie sich Content Security Policy (CSP) Implementierung für weitere Beispiele an.

• Content-Security-Policy-Report-Only
• Erfahren Sie mehr über: Content Security Policy
• Inhalts-Sicherheit in WebExtensions
• Eine strikte Richtlinie übernehmen
• CSP Evaluator - Bewerten Sie Ihre Content Security Policy