Content-Security-Policy (CSP) header

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

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

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

child-src

Definiert die gültigen Quellen für Web-Arbeiter und verschachtelte 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 unter Verwendung von 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 verschachtelte Browsing-Kontexte an, die in <fencedframe>-Elemente geladen werden.

font-src

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

frame-src

Gibt gültige Quellen für verschachtelte 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 Anwendungsmanifestdateien an.

media-src

Gibt gültige Quellen zum Laden von Medien unter Verwendung der <audio>, <video> und <track>-Elemente 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 gerendert 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 als Einzelwert 'none' angegeben werden, was anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden soll, oder als eine oder mehrere Quellausdrücke, die gültige Quellen für diesen Ressourcentyp angeben. Siehe Fetch-Direktivsyntax für weitere Details.

Fallbacks

Einige Fetch-Direktiven fungieren als Fallbacks für andere, granularere Direktiven. Das bedeutet, dass, wenn die granularere 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, aber default-src enthalten ist, dann wird die durch default-src definierte Richtlinie auf Bilder angewendet.
• Wenn script-src-elem weggelassen, aber script-src enthalten ist, dann wird die durch script-src definierte Richtlinie auf <script>-Elemente angewendet.
• Wenn sowohl script-src-elem als auch script-src weggelassen werden, aber default-src enthalten ist, dann wird die durch default-src definierte Richtlinie auf <script>-Elemente angewendet.

Dokumentdirektiven regeln die Eigenschaften eines Dokuments oder Arbeiter-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 Nutzer navigieren oder ein Formular absenden kann.

form-action

Beschränkt die URLs, die als Ziel eines Formularabsendungen 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.

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

report-to

Bietet dem Browser ein Token, das den Berichtsendpunkt oder die Gruppe von Endpunkten identifiziert, an die Informationen über CSP-Verletzungen gesendet werden sollen. Die Endpunkte, die das Token repräsentiert, werden über andere HTTP-Header wie Reporting-Endpoints und Report-To Veraltet bereitgestellt.

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 spezifizieren (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 bei den DOM-XSS-Injektionsquellen.

trusted-types

Wird verwendet, um eine Positivliste von Trusted Types-Richtlinien zu spezifizieren. Trusted Types ermöglicht es Anwendungen, DOM-XSS-Injektionsquellen so zu sichern, dass nur nicht manipulierbare, typisierte Werte statt Zeichenketten akzeptiert werden.

upgrade-insecure-requests

Instruierte Benutzeragenten, 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, veralteter URLs haben, die umgeschrieben werden müssen.

block-all-mixed-content Veraltet

Verhindert das Laden jeglicher Assets mit HTTP, 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 angegeben werden:

• der Einzelwert 'none', der angibt, 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 für alle Fetch-Direktiven anwendbar sind: Siehe die Dokumentation für jede Fetch-Direktive, um herauszufinden, welche Formen auf sie 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 werden.

Dieser Wert besteht aus dem Zeichenfolgenpräfix nonce-, gefolgt von einer Base64-codierten Zeichenkette. Diese Zeichenkette ist ein zufälliger Wert, der vom Server für jede HTTP-Antwort generiert wird. Zum 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 ein Nonce und unsafe-inline enthält, ignoriert der Browser unsafe-inline.

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

Dieser Wert besteht aus einer Zeichenfolge, die einen Hash-Algorithmus identifiziert, gefolgt von -, gefolgt von einer Base64-codierten Zeichenkette, die den Hashwert darstellt.

• Der Hash-Algorithmusbezeichner muss einer der folgenden sein: sha256, sha384 oder sha512.
• Der Hashwert ist der Base64-codierte 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, hash erstellt 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 eine Übereinstimmung gefunden wird.

Wenn das Element eine externe Ressource lädt (z. B. unter Verwendung des src-Attributs), 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 Nutzungsinformationen.

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 Vergleichen von Schemata sind sichere Upgrades erlaubt. Zum Beispiel:

• http://example.com ermöglicht auch Ressourcen von https://example.com
• ws://example.org ermöglicht auch Ressourcen von wss://example.org.

Wildcards ('*') können für Subdomains, Hostadresse und Portnummer verwendet werden, was bedeutet, dass alle zulässigen Werte jedes Werts gültig sind. Zum Beispiel:

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

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

• example.com/api/ ermöglicht Ressourcen von example.com/api/users/new.

Pfad, die nicht mit / enden, werden genau übereinstimmt. Zum Beispiel:

• https://example.com/file.js ermöglicht Ressourcen von https://example.com/file.js, jedoch nicht https://example.com/file.js/file2.js.

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

Sichere Upgrades sind erlaubt, so dass:

• http: ermöglicht auch Ressourcen, die über HTTPS geladen werden
• ws: ermöglicht auch Ressourcen, die über WSS geladen werden.

Ressourcen des gegebenen Typs dürfen nur vom selben Ursprung wie das Dokument geladen werden.

Sichere Upgrades sind erlaubt. Zum Beispiel:

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

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 für setTimeout(), oder den Function()-Konstruktor ein.

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

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

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 schließt ein:

• Inline-<script>-Tags
• Inline-Ereignishandlerei
• javascript:-URLs.

Ähnlich verhält es sich, wenn eine CSP default-src oder eine style-src-Direktive enthält, dann 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 erlauben.

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

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

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

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

Wenn der Hashwert mit dem Hashwert eines Inline-Ereignishandlers 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. Das 'inline-speculation-rules' erlaubt dem Browser, Inline-<script>-Elemente zu laden, die ein type-Attribut von speculationrules haben.

Siehe Speculation Rules API für weitere Informationen.

Das 'strict-dynamic'-Schlüsselwort erweitert das Vertrauen, das durch ein Nonce oder einen Hash einem Skript erwiesen wird, 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 Quellausdruckswerte alle ignoriert:

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

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

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 Ereignishandlerei blockiert, enthält der Verstoßbericht, den der Browser generiert, eine sample-Eigenschaft, die die ersten 40 Zeichen der blockierten Ressource enthält.

Arbeiter werden im Allgemeinen nicht von der Content-Security-Policy des Dokuments (oder Elternarbeiters) geregelt, die sie erstellt hat. Um eine Content-Security-Policy für den Arbeiter festzulegen, setzen Sie einen Content-Security-Policy-Antwortheader für die Anforderung, die das Arbeiter-Skript selbst angefordert hat.

Die Ausnahme ist, wenn der Ursprung des Arbeiterskript ein weltweit eindeutiger Bezeichner ist (z. B. wenn die URL ein Schema von Daten oder Blobs hat). In diesem Fall erbt der Arbeiter die Content-Security-Policy des Dokuments oder Arbeiters, der ihn erstellt hat.

Der CSP-Mechanismus ermöglicht es, dass mehrere Richtlinien für eine Ressource angegeben werden, 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 mehrmals verwenden, wie im Beispiel unten gezeigt. 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 nur weiter die Fähigkeiten der geschützten Ressource einschränken, was bedeutet, dass keine Verbindung erlaubt wird 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 so, dass Ressourcen (Bilder, Schriftarten, Skripte usw.) nur über HTTPS geladen werden können. 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 angewendet werden.

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

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

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

Dieses Beispiel setzt die gleichen Einschränkungen wie das vorherige Beispiel, aber unter Verwendung des Content-Security-Policy-Report-Only-Headers und der report-to-Direktive. Diese Vorgehensweise wird während des Testens verwendet, um Verstöße zu melden, aber den Code nicht an der Ausführung zu hindern.

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

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

Ein bestimmter Endpunkt wird dann als Berichtsziele in der CSP-Richtlinie unter Nutzung 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.

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

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