Content-Security-Policy (CSP)

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

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

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

child-src

Definiert die gültigen Quellen für Web Workers und verschachtelte Browsing-Kontexte, die mithilfe von Elementen 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 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 Schriften 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 Bildquellen 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 vorausgeladen 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-Ereignishandler in Attribute 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 in <style> Elementen und <link> Elementen 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 einzelnen Wert 'none' angegeben werden, was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert werden soll, oder als eine oder mehrere source expression Werte, die gültige Quellen für diesen Ressourcentyp angeben. Siehe Fetch-Direktiv-Syntax für weitere Details.

Fallbacks

Einige Fetch-Direktiven fungieren 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.

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.

Dokument-Direktiven regeln 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.

Navigations-Direktiven regeln, zu welchen Orten ein Benutzer navigieren oder ein Formular übermitteln kann, zum Beispiel.

form-action

Beschränkt die URLs, die als Ziel von Formularübermittlungen 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.

Bericht-Direktiven steuern die Ziel-URL für CSP-Verstoßberichte in Content-Security-Policy und Content-Security-Policy-Report-Only.

report-to

Bietet dem Browser ein Token, das den Berichtsendpunkt oder eine Gruppe von Endpunkten identifiziert, an die CSP-Verletzungsinformationen gesendet werden sollen. Die Endpunkte, die das Token repräsentiert, werden durch 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 Direktive report-uri ignoriert. Solange report-to jedoch noch nicht breit unterstützt wird, sollten Sie beide Header wie gezeigt angeben (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 anzugeben. Trusted Types ermöglicht es Anwendungen, DOM XSS-Injektionsstellen so zu sperren, dass diese nur nicht fälschbare, typisierte Werte anstelle von Zeichenfolgen 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 alter URLs vorgesehen, die umgeschrieben werden müssen.

block-all-mixed-content Veraltet

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

report-uri Veraltet

Bietet dem Browser eine URL, an die CSP-Verstoßberichte gesendet werden sollen. Dies wurde durch die Direktive report-to ersetzt.

Alle Fetch-Direktiven können wie folgt angegeben werden:

• der einzelne Wert 'none', der angibt, dass der spezifische Ressourcentyp vollständig blockiert werden soll
• ein oder mehrere source expression Werte, die gültige Quellen für diesen Ressourcentyp angeben.

Jeder source expression 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 anwendbar sind.

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

Dieser Wert besteht aus dem String nonce- gefolgt von einem base64-kodierten String. Dieser String ist ein Zufallswert, den der Server für jede HTTP-Antwort generiert. Zum Beispiel:

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

Der Server kann dann denselben Wert als Wert des nonce Attributs von <script> oder <style> Ressourcen einfügen, die er vom Dokument laden möchte.

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

Siehe Nonces im CSP Leitfaden für weitere Informationen zur Verwendung.

Dieser Wert besteht aus einem String, der einen Hash-Algorithmus identifiziert, gefolgt von -, gefolgt von einem base64-kodierten String, der den Hash-Wert darstellt.

• Der Hash-Algorithmus-Identifier muss einer von sha256, sha384 oder sha512 sein.
• Der Hash-Wert ist der base64-kodierte 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, hasht er den Inhalt der <script> und <style> Elemente, vergleicht das Ergebnis mit allen Hashes in der CSP-Direktive und lädt die Ressource nur, wenn ein Match vorliegt.

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 Informationen zur Verwendung.

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

Das Schema, die Portnummer und der Pfad sind optional.

Wenn das Schema ausgelassen wird, wird das Schema des Ursprungs des Dokuments verwendet.

Beim Abgleichen 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, Hostadressen und Portnummern verwendet werden, was angibt, dass alle zulässigen Werte jeweils gültig sind. Zum Beispiel:

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

Pfad, die in / enden, passen zu jedem Pfad, den sie als Präfix haben. Zum Beispiel:

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

Pfad, die nicht in / 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 angegebenen Typs dürfen nur vom gleichen 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 für setTimeout() oder den Function() Konstruktor ein.

Das unsafe-eval Schlüsselwort kann verwendet werden, um diesen Schutz rückgängig zu machen, sodass die dynamische Auswertung von Zeichenfolgen als JavaScript erlaubt wird.

Siehe eval() und ähnliche APIs im CSP Leitfaden für weitere Informationen zur Verwendung.

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, dann darf eine Seite kein WebAssembly kompilieren, indem Funktionen wie WebAssembly.compileStreaming() verwendet werden.

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, dann darf Inline-JavaScript nicht ausgeführt werden. Dies schließt ein:

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

In gleicher Weise, wenn eine CSP default-src oder eine style-src Direktive enthält, dann werden Inline-CSS nicht geladen, einschließlich:

• Inline <style> Tags
• style Attribute.

Das unsafe-inline Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben, sodass alle diese Formen geladen werden dürfen.

Siehe Inline-JavaScript im CSP Leitfaden für weitere Informationen zur Verwendung.

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, dann sind Inline-Ereignishandlerattribute wie onclick und Inline-Style-Attribute nicht ausführbar.

Der Ausdruck 'unsafe-hashes' ermöglicht es dem Browser, Hash-Ausdrücke für Inline-Ereignishandler und Style-Attribute zu verwenden. Zum Beispiel könnte eine CSP eine Direktive dieser Art enthalten:

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

Wenn der Hash-Wert mit dem Hash eines Inline-Ereignishandlerattribut-Werts oder eines Style-Attribut-Werts ü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, dann 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 die Speculation Rules API für mehr Informationen.

Das 'strict-dynamic' Schlüsselwort lässt das Vertrauen, das ein Skript durch ein Nonce oder einen Hash erhält, auch auf Skripte ausdehnen, die dieses Skript dynamisch lädt, zum Beispiel durch Erzeugung 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 Quellenausdruckswerte alle ignoriert:

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

Siehe Das strict-dynamic Schlüsselwort im CSP Leitfaden für mehr Informationen zur Verwendung.

Wenn dieser Ausdruck in einer Direktive enthalten ist, die Skripte oder Styles steuert, und die Direktive dazu führt, dass der Browser irgendwelche Inline-Skripte, Inline-Styles oder Ereignishandlerattribute blockiert, dann enthält der Verstoßbericht, den der Browser generiert, eine sample Eigenschaft, die die ersten 40 Zeichen der blockierten Ressource enthält.

Workers unterliegen im Allgemeinen nicht der Content-Sicherheitsrichtlinie des Dokuments (oder des übergeordneten Workers), das sie erstellt hat. Um eine Content-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 zu diesem Fall ist, wenn der Ursprung des Worker-Skripts eine global eindeutige Kennung ist (zum Beispiel, wenn seine URL ein Schema von Data oder Blob hat). In diesem Fall erbt der Worker die Content-Sicherheitsrichtlinie des Dokuments oder Workers, das ihn erstellt hat.

Der CSP-Mechanismus erlaubt es, dass mehrere Richtlinien für eine Ressource spezifiziert werden können, 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 untenstehenden Beispiel. Achten Sie besonders auf die connect-src Direktive hier. Auch wenn die zweite Richtlinie die Verbindung zulassen würde, enthält die erste Richtlinie connect-src 'none'. Das Hinzufügen zusätzlicher Richtlinien kann nur weiter einschränken die Fähigkeiten der geschützten Ressource, was bedeutet, dass keine Verbindung erlaubt ist, und als strengste Richtlinie wird connect-src 'none' durchgesetzt.

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, nur Ressourcennutzung (Bilder, Schriften, Skripte usw.) ü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 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 diese zu korrigieren, um sicherzustellen, dass Ressourcen nur über HTTPS geladen werden und Plugins zu deaktivieren:

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

Dieses Beispiel setzt die gleichen 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 nicht um Code daran zu hindern, ausgeführt zu werden.

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

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

Ein bestimmter Endpunkt wird dann in der CSP-Richtlinie als Zielbericht 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 oben ebenfalls 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
• Erlangung einer strengen Richtlinie
• CSP Evaluator - Bewerten Sie Ihre Content-Sicherheitsrichtlinie