Content-Security-Policy

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

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

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

child-src

Definiert die gültigen Quellen für Web-Worker und verschachtelte Betrachtungs-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 verschachtelte Betrachtungs-Kontexte in <fencedframe>-Elementen an.

font-src

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

frame-src

Gibt gültige Quellen für verschachtelte Betrachtungs-Kontexte in Elementen wie <frame> und <iframe> an.

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 für das Vorladen oder Vorberechnen an.

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, die auf einzelne DOM-Elemente angewendet werden, an.

worker-src

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

Alle Fetch-Direktiven können als einzelner Wert 'none' angegeben werden, was anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden sollte, oder als einer oder mehrere Source Expression-Werte, die gültige Quellen für diesen Ressourcentyp anzeigen. Siehe Fetch-Direktiven-Syntax für mehr Details.

Fallbacks

Einige Fetch-Direktiven funktionieren als Fallbacks für andere, granularere Direktiven. Das bedeutet, dass, wenn die granularere 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 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.

Beispielsweise:

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

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

base-uri

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

sandbox

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

Navigationsdirektiven regeln, zu welchen Orten ein Benutzer navigieren oder ein Formular einreichen kann, zum Beispiel.

form-action

Beschränkt die URLs, die als Ziel von Formulareinreichungen 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 können.

Berichtsdirektiven steuern 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 Berichts-Endpunkten identifiziert, an die CSP-Verletzungsinformationen gesendet werden sollen. Die Endpunkte, die das Token repräsentiert, werden durch andere HTTP-Header bereitgestellt, wie z.B. Reporting-Endpoints und Report-To Veraltet .

Warnung: Diese Direktive soll report-uri ersetzen; in Browsern, die report-to unterstützen, wird die Direktive report-uri 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 erlaubt Anwendungen, DOM-XSS-Injektionsstellen so zu sichern, dass sie nur nicht manipulierbare, typisierte Werte anstelle von Strings akzeptieren.

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, älterer URLs gedacht, die umgeschrieben werden müssen.

block-all-mixed-content Veraltet

Verhindert das Laden jeglicher Ressourcen über HTTP, wenn die Seite über HTTPS geladen wird.

report-uri Veraltet

Bietet dem Browser eine URL, 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 einzelne Wert 'none', der anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden soll
• eine oder mehrere Source Expression-Werte, die gültige Quellen für diesen Ressourcentyp anzeigen.

Jede Source Expression nimmt eine der unten aufgeführten Formen an. Beachten Sie, dass nicht alle Formen auf alle Fetch-Direktiven anwendbar sind: siehe die Dokumentation zu jeder Fetch-Direktive, um herauszufinden, welche Formen darauf anwendbar sind.

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

Dieser Wert besteht aus dem String nonce- gefolgt von einem Base64-codierten String. 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 den gleichen Wert als Wert des nonce-Attributs von jedem <script> oder <style> Ressourcen, die sie aus dem Dokument laden möchten, aufnehmen.

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 eine Nonce und unsafe-inline enthält, ignoriert der Browser unsafe-inline.

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

Dieser Wert besteht aus einem String, der einen Hash-Algorithmus identifiziert, gefolgt von -, gefolgt von einem Base64-codierten String, der den Hash-Wert repräsentiert.

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

Beispiel:

'sha256-cd9827ad...'

Wenn der Browser das Dokument empfängt, hasht 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 vorliegt.

Wenn das Element eine externe Ressource lädt (zum Beispiel unter Verwendung des src Attributs), muss das Element auch das integrity Attribut enthalten.

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, die 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 Dokuments ursprungs verwendet.

Beim Schema-Vergleich 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.

Platzhalter ('*') können für Subdomains, Host-Adressen und Portnummern verwendet werden, um anzuzeigen, dass alle legalen Werte jeweils 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, dem sie Präfix sind. Zum Beispiel:

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

Pfade, die nicht mit / enden, werden genau abgeglichen. 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 gegebenen Typs dürfen nur vom selben Ursprung wie das Dokument geladen werden.

Sichere Upgrades sind erlaubt. Beispiel:

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

Standardmäßig, wenn ein 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 zu setTimeout(), oder den Funktion() Konstruktor ein.

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

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

Standardmäßig, wenn ein CSP eine default-src oder eine script-src Direktive enthält, wird es einer Seite nicht erlaubt, WebAssembly mit Funktionen wie WebAssembly.compileStreaming() zu 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 ein CSP eine default-src oder eine script-src Direktive enthält, ist es Inline-JavaScript nicht erlaubt, ausgeführt zu werden. Dies schließt ein:

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

Ähnlich, wenn ein 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 Formen zu laden.

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

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

Die 'unsafe-hashes' Expression erlaubt es dem Browser, Hash-Ausdrücke für Inline-Event-Handler und style Attribute zu verwenden. Beispiel: Ein CSP könnte 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, dann wird der Code erlaubt, ausgeführt zu werden.

<button onclick="transferAllMyMoney()">
  Übertragen Sie mein gesamtes Geld
</button>

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

Siehe die Speculation Rules API für weitere Informationen.

Das 'strict-dynamic' Schlüsselwort erweitert das Vertrauen, das einem Skript durch eine Nonce oder einen Hash verliehen wird, auf Skripte, die dieses Skript dynamisch lädt, zum Beispiel, indem neue <script> Tags mittels Document.createElement() erstellt und dann mit Node.appendChild() in das Dokument eingefügt werden.

Wenn dieses Schlüsselwort in einer Direktive vorhanden ist, werden die folgenden Source-Expressions 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 kontrolliert, und die Direktive dazu führt, dass der Browser Inline-Skripte, Inline-Stile oder Event-Handler-Attribute blockiert, wird der Verletzungsbericht, den der Browser generiert, eine sample Eigenschaft enthalten, die die ersten 40 Zeichen der blockierten Ressource enthält.

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

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

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. Selbst 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, 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 das Laden von Ressourcen (Bilder, Schriftarten, Skripte usw.) nur über HTTPS zu erlauben. 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 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 existierenden Seite verwendet werden, die zu viel Inline-Code verwendet, um behoben zu werden, 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 dieselben Einschränkungen wie das vorherige Beispiel, jedoch unter Verwendung des Content-Security-Policy-Report-Only Headers und der report-to Direktive. Dieser Ansatz wird während des Testens 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 unter Verwendung des Reporting-Endpoints HTTP-Antwort-Headers definiert.

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

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

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

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