Content-Security-Policy (CSP)

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

wobei <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 Worker 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 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>-Elementen 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 Elementen 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 für das Laden von Medien mit den Elementen <audio>, <video> und <track> an.

object-src

Gibt gültige Quellen für die Elemente <object> und <embed> 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 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 mit dem einzelnen Wert 'none' spezifiziert werden, was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert werden sollte, oder als ein oder mehrere source expression Werte, die gültige Quellen für diesen Ressourcentyp angeben. Siehe Fetch-Direktiven-Syntax für weitere Details.

Fallbacks

Einige Fetch-Direktiven fungieren als Fallbacks für andere, granulärere Direktiven. Dies bedeutet, dass, wenn die granulärere 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 ausgelassen wird, aber default-src enthalten ist, wird die Richtlinie, die durch default-src definiert wird, auf Bilder angewendet.
• Wenn script-src-elem ausgelassen wird, aber script-src enthalten ist, wird die Richtlinie, die durch script-src definiert wird, auf <script>-Elemente angewendet.
• Wenn sowohl script-src-elem als auch script-src ausgelassen werden, aber default-src enthalten ist, wird die Richtlinie, die durch default-src definiert wird, auf <script>-Elemente angewendet.

Dokument-Direktiven regeln die Eigenschaften eines Dokuments oder einer worker-Umgebung, auf die eine Richtlinie angewendet wird.

base-uri

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

sandbox

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

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

form-action

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

Berichts-Direktiven 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 Berichts-Endpunkt 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 z.B. 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 jedoch report-to breit unterstützt wird, sollten Sie beide Header angeben, wie gezeigt (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-Injektions-Punkten.

trusted-types Experimentell

Verwendet, um eine Whitelist von Trusted Types-Richtlinien zu spezifizieren. Trusted Types ermöglichen es Anwendungen, DOM XSS Injektions-Punkte zu sperren, sodass 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 mit einer großen Anzahl unsicherer Legacy-URLs gedacht, die umgeschrieben werden müssen.

block-all-mixed-content Veraltet

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

report-uri Veraltet

Gibt dem Browser eine URL an, an die CSP-Verletzungsberichte gesendet werden sollen. Dies wurde durch die report-to-Direktive ersetzt.

Alle Fetch-Direktiven können auf eine der folgenden Arten angegeben werden:

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

Jede Quell-Ausdrucksform 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 darauf anwendbar sind.

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

Dieser Wert besteht aus dem String nonce-, gefolgt von einem base64-kodierten String. Dieser String 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 Wert des nonce-Attributs von <script> oder <style> Ressourcen einfügen, die er aus dem Dokument laden möchte.

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

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-Identifikator muss entweder 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 erhält, hasht er den Inhalt aller <script> und <style> Elemente, vergleicht das Ergebnis mit allen 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 mit dem src Attribut), muss das Element auch das integrity Attribut 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 Vergleich von Schemas sind sichere Upgrades erlaubt. Zum Beispiel:

• http://example.com erlaubt ebenfalls Ressourcen von https://example.com
• ws://example.org erlaubt ebenfalls Ressourcen von wss://example.org.

Platzhalter ('*') können für Subdomains, Host-Adressen und Portnummern verwendet werden und geben an, dass alle legalen Werte von jedem gültig sind. Zum Beispiel:

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

Pfade, die mit / enden, stimmen mit jedem Pfad überein, dessen Präfix sie sind. Zum Beispiel:

• example.com/api/ wird Ressourcen von example.com/api/users/new erlauben.

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 von https://example.com/file.js/file2.js.

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

Sichere Upgrades sind erlaubt, also:

• http: erlaubt ebenfalls Ressourcen, die unter HTTPS geladen werden
• ws: erlaubt ebenfalls Ressourcen, die unter WSS geladen werden.

Ressourcen des gegebenen 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 ausgeliefert wird, erlaubt eine CSP von 'self' ebenfalls Ressourcen von https://example.com.
• Wenn das Dokument von ws://example.org ausgeliefert wird, erlaubt eine CSP von 'self' ebenfalls Ressourcen von wss://example.org.

Standardmäßig werden, wenn eine CSP eine default-src oder eine script-src Direktive enthält, JavaScript-Funktionen, die ihre Argumente als JavaScript auswerten, deaktiviert. Dies umfasst eval(), das code Argument zu setTimeout(), oder den Function() Konstruktor.

Das unsafe-eval Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben, sodass die dynamische Auswertung von Strings als JavaScript ermöglicht wird.

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

Standardmäßig ist, wenn eine CSP eine default-src oder eine script-src Direktive enthält, eine Seite nicht erlaubt, WebAssembly unter Verwendung von Funktionen wie WebAssembly.compileStreaming() zu 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 ist, wenn eine CSP eine default-src oder eine script-src Direktive enthält, das Ausführen von Inline-JavaScript nicht erlaubt. Dies umfasst:

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

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

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

Standardmäßig ist, wenn eine CSP eine default-src oder eine script-src Direktive enthält, das Ausführen von Inline-Event-Handler-Attributen wie onclick und Inline-style-Attributen nicht erlaubt.

Der 'unsafe-hashes' Ausdruck erlaubt es dem Browser, hash expressions für Inline-Event-Handler und style Attribute zu verwenden. Beispielsweise 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.

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

Standardmäßig ist, wenn eine CSP eine default-src oder eine script-src Direktive enthält, das Ausführen von Inline-JavaScript nicht erlaubt. Durch 'inline-speculation-rules' kann der Browser Inline-<script>-Elemente laden, die ein type Attribut von speculationrules haben.

Siehe die Speculation Rules API für mehr Informationen.

Das 'strict-dynamic' Schlüsselwort erweitert das Vertrauen, das von einem nonce oder einem hash auf ein Skript übertragen wird, auf Skripte, die dieses Skript dynamisch lädt, z. B. durch Erstellen neuer <script>-Tags mit Document.createElement() und anschließendes Einfügen in das Dokument mit Node.appendChild().

Wenn dieses Schlüsselwort in einer Direktive vorhanden ist, werden folgende Quell-Ausdruckswerte alle ignoriert:

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

Siehe The strict-dynamic keyword im CSP-Leitfaden für mehr Nutzungsinformationen.

Wenn dieser Ausdruck in eine Direktive aufgenommen wird, die Skripte oder Stile steuert, und die Direktive den Browser dazu veranlasst, Inline-Skripte, Inline-Stile oder Event-Handler-Attribute zu blockieren, dann enthält der Verletzungsbericht das der Browser generiert, eine sample Eigenschaft, die die ersten 40 Zeichen der blockierten Ressource enthält.

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

Die Ausnahme hiervon 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 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 nachstehenden 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 weiterer Richtlinien kann nur weitere Einschränkungen der Fähigkeiten der geschützten Ressource bewirken, was bedeutet, dass keine Verbindung erlaubt ist 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 zuzulassen. 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 mithilfe des HTML-<meta>-Elements angewendet werden.

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

Diese Richtlinie könnte auf einer bereits existierenden Website verwendet werden, die zu viel Inline-Code verwendet, um es zu beheben, 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 legt dieselben Einschränkungen wie das vorherige Beispiel fest, jedoch unter Verwendung des Content-Security-Policy-Report-Only Headers und der report-to Direktive. Dieser Ansatz wird bei Tests verwendet, um Verstöße zu melden, aber den Code nicht am Ausführen zu hindern.

Endpunkte (URLs), an die Berichte gesendet werden, werden über den Reporting-Endpoints HTTP-Antwort-Header definiert.

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

Ein bestimmter Endpunkt wird dann in der CSP-Richtlinie mit der report-to Direktive als Berichtsziel 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 derzeit noch nicht weitgehend von Browsern unterstützt wird.

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

• Content-Security-Policy-Report-Only
• Lernen Sie über: Content Security Policy
• Content Security in WebExtensions
• Einführung einer strengen Richtlinie
• CSP Evaluator - Evaluieren Sie Ihre Content-Security-Policy