Content-Security-Policy (CSP) header

Syntax

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

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

Direktiven

Abrufdirektiven

Abrufdirektiven kontrollieren die Standorte, von denen bestimmte Ressourcentypen geladen werden dürfen.

child-src

Definiert die gültigen Quellen für Web Workers und verschachtelte Browsing-Kontexte, die über Elemente wie <frame> und <iframe> geladen werden.

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

connect-src

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

default-src

Dient als Fallback für die anderen Abrufdirektiven.

Fallback für alle anderen Abrufdirektiven.

fenced-frame-src Experimentell

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

font-src

Gibt gültige Quellen für Schriftarten an, die mit @font-face geladen worden sind.

frame-src

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

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 geladen oder vorgeladen 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 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 Abrufdirektiven können den einzelnen Wert 'none' annehmen, was darauf hinweist, dass der spezifische Ressourcentyp vollständig blockiert werden sollte, oder als ein oder mehrere Quellausdrücke, die gültige Quellen für diesen Ressourcentyp angeben. Weitere Details finden Sie unter Abrufdirektiven-Syntax.

Fallbacks

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

• default-src ist ein Fallback für alle anderen Abrufdirektiven.
• 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, 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 sowohl script-src-elem als auch script-src weggelassen werden, aber default-src enthalten ist, wird die von default-src definierte Richtlinie auf <script>-Elemente angewendet.

Dokumentdirektiven

Dokumentdirektiven steuern die Eigenschaften eines Dokuments oder 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.

Navigationsdirektiven

Navigationsdirektiven bestimmen, zu welchen Standorten ein Benutzer navigieren oder ein Formular übermitteln kann.

form-action

Beschränkt die URLs, die als Ziel für Formulareinreichungen aus einem bestimmten Kontext verwendet werden können.

frame-ancestors

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

Berichtsdirektiven

Berichtsdirektiven 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 Informationen zu CSP-Verletzungen 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. Allerdings sollten Sie, bis report-to umfassend unterstützt wird, 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

Weitere Direktiven

require-trusted-types-for

Erzwingt Trusted Types an DOM-XSS-Injektionsstellen.

trusted-types

Wird verwendet, um eine Whitelist von Trusted Types-Richtlinien zu spezifizieren. 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 durch sichere URLs (die über HTTPS bereitgestellt werden) ersetzt worden. Diese Direktive ist für Websites gedacht, die eine große Anzahl unsicherer, älterer URLs haben, die umgeschrieben werden müssen.

Veraltete Direktiven

block-all-mixed-content Veraltet

Verhindert das Laden von Assets über HTTP, wenn die Seite über 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.

Abrufdirektiven-Syntax

Alle Abrufdirektiven können als einer der folgenden Werte angegeben werden:

• der einzelne Wert 'none', der anzeigt, 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 Abrufdirektiven anwendbar sind: In der Dokumentation jeder Abrufdirektive erfahren Sie, welche Formen darauf anwendbar sind.

Die Formate <host-source> und <scheme-source> dürfen nicht in Anführungszeichen gesetzt werden, und alle anderen Formate müssen in einfache Anführungszeichen eingeschlossen sein.

'nonce-<nonce_value>'

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

Dieser String ist ein zufälliger Wert, 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 jeder <script>- oder <style>-Ressource einschließen, 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 einen Nonce und unsafe-inline enthält, ignoriert der Browser unsafe-inline.

Weitere Informationen zur Nutzung finden Sie unter Nonces im CSP-Leitfaden.

'<hash_algorithm>-<hash_value>'

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

• Der Hash-Algorithmus-Identifikator muss einer der folgenden sein: sha256, sha384 oder sha512.
• Der Hash-Wert ist der base64-kodierte Hash einer <script>- oder <style>-Ressource, berechnet mittels einer 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 den Hashes in der CSP-Direktive und lädt die Ressource nur, wenn es eine Übereinstimmung gibt.

Wenn das Element eine externe Ressource lädt (z. B. 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.

Weitere Informationen zur Nutzung finden Sie unter Hashes im CSP-Leitfaden.

<host-source>

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 Abgleichen von Schemen 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 Subdomains, Hostadressen und Portnummern verwendet werden, was darauf hinweist, dass alle legalen Werte von jedem gültig sind. Beispiel:

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

Pfad-Endungen mit / stimmen mit jedem Pfad überein, dessen Präfix sie sind. Beispiel:

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

Pfad-Endungen ohne / werden genau abgeglichen. Beispiel:

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

<scheme-source>

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.

'self'

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

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

'trusted-types-eval'

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

Das Schlüsselwort trusted-types-eval kann verwendet werden, um diesen Schutz aufzuheben, aber nur, wenn Trusted Types erzwungen werden und anstelle von Zeichenketten an diese Funktionen übergeben werden. Dies ermöglicht die dynamische Auswertung von Zeichenketten als JavaScript, aber nur, nachdem die Eingaben durch eine Transformationsfunktion geführt wurden, bevor sie injiziert werden, was die Möglichkeit hat, die Eingabe zu bereinigen, um potenziell gefährliches Markup zu entfernen.

Das trusted-types-eval-Muss anstelle von 'unsafe-eval' verwendet werden, wenn diese Methoden mit vertrauenswürdigen Typen verwendet werden. Dies stellt sicher, dass der Zugriff auf die Methoden in Browsern blockiert wird, die keine vertrauenswürdigen Typen unterstützen.

Weitere Informationen finden Sie unter eval() und ähnliche APIs im CSP-Leitfaden.

'unsafe-eval'

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

Das Schlüsselwort unsafe-eval kann verwendet werden, um diesen Schutz aufzuheben, sodass die dynamische Auswertung von Zeichenketten als JavaScript möglich ist.

Weitere Informationen finden Sie unter eval() und ähnliche APIs im CSP-Leitfaden.

'wasm-unsafe-eval'

Standardmäßig ist das Kompilieren von WebAssembly auf einer Seite nicht erlaubt, wenn eine CSP eine default-src- oder eine script-src-Direktive enthält, durch Funktionen wie WebAssembly.compileStreaming().

Das Schlüsselwort wasm-unsafe-eval 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.

'unsafe-inline'

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

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

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

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

Das Schlüsselwort unsafe-inline kann verwendet werden, um diesen Schutz aufzuheben und das Laden dieser Formen zu ermöglichen.

Weitere Informationen finden Sie unter Inline-JavaScript im CSP-Leitfaden.

'unsafe-hashes'

Standardmäßig sind Inline-Ereignis-Handler-Attribute wie onclick und Inline-style-Attribute nicht erlaubt, wenn eine CSP eine default-src- oder script-src-Direktive enthält.

Der Ausdruck 'unsafe-hashes' erlaubt dem Browser, Hash-Ausdrücke für Inline-Ereignis-Handler und style-Attribute zu verwenden. Ein Beispiel für einen CSP-Direktive-Ausdruck könnte so aussehen:

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

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

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

'inline-speculation-rules'

Standardmäßig ist Inline-JavaScript nicht erlaubt, wenn eine CSP eine default-src- oder script-src-Direktive enthält. 'inline-speculation-rules' erlaubt dem Browser das Laden von Inline-<script>-Elementen mit einem type-Attribut von speculationrules.

Weitere Informationen finden Sie in der Speculation Rules API.

'strict-dynamic'

Das Schlüsselwort 'strict-dynamic' erweitert das Vertrauen, das ein Nonce oder ein Hash auf ein Skript verleiht, auf Skripte, die dieses Skript dynamisch lädt, zum Beispiel durch das Erstellen neuer <script>-Tags mit Document.createElement() und dem anschließenden 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'

Weitere Informationen finden Sie unter Das strict-dynamic-Schlüsselwort im CSP-Leitfaden.

'report-sample'

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

CSP in Arbeitern

Workers unterliegen im Allgemeinen nicht der Inhalts-Sicherheitsrichtlinie des Dokuments (oder des übergeordneten Arbeiters), das sie erstellt hat. Um eine Inhalts-Sicherheitsrichtlinie für den Arbeiter festzulegen, setzen Sie einen Content-Security-Policy-Antwortheader für die Anforderung, die das Arbeiterskript selbst angefordert hat.

Die Ausnahme bildet der Fall, wenn der Ursprung des Arbeiterskripts ein global eindeutiger Identifikator ist (zum Beispiel, wenn seine URL ein Schema von Daten oder Blob hat). In diesem Fall erbt der Arbeiter die Inhalts-Sicherheitsrichtlinie des Dokuments oder Arbeiters, das ihn erstellt hat.

Mehrere Inhalts-Sicherheitsrichtlinien

Der CSP-Mechanismus erlaubt 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 folgenden Beispiel. Achten Sie besonders auf die connect-src-Direktive hier. Auch wenn die zweite Richtlinie die Verbindung erlauben würde, enthält die erste Richtlinie connect-src 'none'. Das Hinzufügen zusätzlicher Richtlinien kann die Fähigkeiten der geschützten Ressource nur weiter einschränken, was bedeutet, dass keine Verbindung erlaubt wird, und 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/

Beispiele

Unsicherer Inline-Code deaktivieren und nur HTTPS-Ressourcen zulassen

Dieser HTTP-Header setzt die Standardrichtlinie so, dass nur das Laden von Ressourcen (Bilder, Schriftarten, Skripte usw.) ü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:" />

Inline-Code und HTTPS-Ressourcen zulassen, aber Plugins deaktivieren

Diese Richtlinie könnte auf einer vorhandenen Website verwendet werden, die zu viel Inline-Code verwendet, um ihn 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'

Verstöße melden, aber nicht erzwingen, während des Testens

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, ohne Code blockieren zu lassen.

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

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

Ein bestimmter Endpunkt wird dann als Berichtsziel 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 auch oben angegeben ist, da report-to noch nicht breit von Browsern unterstützt wird.

Weitere Beispiele finden Sie unter Content Security Policy (CSP)-Implementierung.

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Content-Security-Policy-Report-Only
• Lernen Sie mehr: Content Security Policy
• Inhalts-Sicherheit in WebExtensions
• Annahme einer strengen Richtlinie
• CSP Evaluator - Bewerten Sie Ihre Content Security Policy