Content-Security-Policy (CSP) header

Syntax

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

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

Richtlinien

Fetch-Richtlinien

Fetch-Richtlinien steuern 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 geladen mit Elementen wie <frame> und <iframe>.

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

connect-src

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

default-src

Dient als Fallback für die anderen Fetch-Richtlinien.

Fallback für alle anderen Fetch-Richtlinien.

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 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 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 vorgeladen oder vorgemixt werden dürfen.

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

worker-src

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

Alle Fetch-Richtlinien können als einzelner Wert 'none' angegeben werden, was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert werden soll, oder als ein oder mehrere source expression-Werte, die gültige Quellen für diesen Ressourcentyp angeben. Siehe Fetch-Richtlinien-Syntax für mehr Details.

Fallbacks

Einige Fetch-Richtlinien fungieren als Fallbacks für andere, granularere Richtlinien. Dies bedeutet, dass, wenn die granularere Richtlinie 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-Richtlinien.
• 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 festgelegte Richtlinie auf Bilder angewendet.
• Wenn script-src-elem weggelassen wird, aber script-src enthalten ist, wird die von script-src festgelegte Richtlinie auf <script>-Elemente angewendet.
• Wenn script-src-elem und script-src beide weggelassen werden, aber default-src enthalten ist, wird die von default-src festgelegte Richtlinie auf <script>-Elemente angewendet.

Dokumentenrichtlinien

Dokumentenrichtlinien regeln die Eigenschaften eines Dokuments oder der Worker-Umgebung, auf die eine Richtlinie zutrifft.

base-uri

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

sandbox

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

Navigationsrichtlinien

Navigationsrichtlinien 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 gegebenen Kontext verwendet werden können.

frame-ancestors

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

Bericht-Richtlinien

Bericht-Richtlinien steuern 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 Identifizierung des Berichterstattungsendpunkts oder der Endpunktgruppe bereit, an die CSP-Verletzungsinformationen gesendet werden sollen. Die durch das Token repräsentierten Endpunkte werden durch andere HTTP-Header bereitgestellt, wie zum Beispiel Reporting-Endpoints und Report-To Veraltet .

Warnung: Diese Richtlinie soll report-uri ersetzen; in Browsern, die report-to unterstützen, wird die report-uri-Richtlinie ignoriert. Bis report-to jedoch weit 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

Andere Richtlinien

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öglichen es Anwendungen, DOM-XSS-Injektionsstellen so zu sichern, dass nur nicht fälschbare, typisierte Werte anstelle von Zeichenfolgen akzeptiert werden.

upgrade-insecure-requests

Weist Benutzeragenten an, alle unsicheren URLs einer Site (die über HTTP bereitgestellt werden), als ob sie durch sichere URLs (die über HTTPS bereitgestellt werden) ersetzt worden seien, zu behandeln. Diese Richtlinie ist für Websites vorgesehen, die eine große Anzahl unsicherer Legacy-URLs haben, die umgeschrieben werden müssen.

Veraltete Richtlinien

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 bereit, an die CSP-Verletzungsberichte gesendet werden sollen. Dies wurde durch die report-to Richtlinie ersetzt.

Fetch-Richtlinien-Syntax

Alle Fetch-Richtlinien können als eine der folgenden angegeben werden:

• der einzelne Wert 'none', was bedeutet, 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 Quellausdruck nimmt eine der unten aufgeführten Formen an. Beachten Sie, dass nicht alle Formen für alle Fetch-Richtlinien anwendbar sind: siehe die Dokumentation für jede Fetch-Richtlinie, um herauszufinden, welche Formen anwendbar sind.

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

'nonce-<nonce_value>'

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

Diese Zeichenkette 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 den Wert des nonce-Attributs eines beliebigen <script>- oder <style>-Ressourcen einschließen, die er aus dem Dokument laden möchte.

Der Browser vergleicht den Wert aus der CSP-Richtlinie mit dem Wert im Element-Attribut und lädt die Ressource nur, wenn sie übereinstimmen.

Wenn eine Richtlinie einen Nonce und unsafe-inline enthält, ignoriert der Browser unsafe-inline.

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

'<hash_algorithm>-<hash_value>'

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

• Der Hash-Algorithmus-Identifikator muss entweder sha256, sha384 oder sha512 sein.
• Der Hash-Wert ist der base64-kodierte Hash einer <script>- oder <style>-Ressource, die unter Verwendung einer der folgenden Hash-Funktionen berechnet wurde: SHA-256, SHA-384 oder SHA-512.

Zum Beispiel:

'sha256-cd9827ad...'

Wenn der Browser das Dokument erhält, hasht es den Inhalt etwaiger <script>- und <style>-Elemente, vergleicht das Ergebnis mit eventuellen Hashes in der CSP-Richtlinie, und lädt die Ressource nur, wenn eine Übereinstimmung vorliegt.

Wenn das Element eine externe Ressource lädt (beispielsweise unter Verwendung des src-Attributs), dann muss das Element auch das integrity-Attribut setzen.

Wenn eine Richtlinie einen Hash und unsafe-inline enthält, ignoriert der Browser unsafe-inline.

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

<host-source>

Die URL oder IP-Adresse eines Hosts, die als eine gültige Quelle für die Ressource gilt.

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

• http://example.com lässt auch Ressourcen von https://example.com zu
• ws://example.org lässt auch Ressourcen von wss://example.org zu.

Sternchen ('*') können für Subdomains, Host-Adressen und Portnummern verwendet werden, um anzugeben, dass alle rechtlich zulässigen Werte dafür gültig sind. Zum Beispiel:

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

Pfadendungen mit / stimmen mit jedem Pfad überein, der ein Präfix von ihnen ist. Zum Beispiel:

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

Pfadendungen ohne / stimmen genau überein. Zum 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: lässt auch Ressourcen zu, die HTTPS verwenden
• ws: lässt auch Ressourcen zu, die WSS verwenden.

'self'

Ressourcen des angegebenen 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 zulassen.
• Wenn das Dokument von ws://example.org bereitgestellt wird, wird eine CSP von 'self' auch Ressourcen von wss://example.org zulassen.

'trusted-types-eval'

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

Das trusted-types-eval-Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben, jedoch nur, wenn Trusted Types erzwungen werden und an diese Funktionen anstelle von Strings übergeben werden. Dies ermöglicht die dynamische Auswertung von Zeichenfolgen als JavaScript, jedoch nur nach einer Transformationsfunktion, bevor es injiziert wird, was die Möglichkeit bietet, die Eingabe zu sanitizen, um potenziell gefährliche Markups zu entfernen.

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

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

'unsafe-eval'

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

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

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

'wasm-unsafe-eval'

Standardmäßig wird, wenn eine CSP eine default-src oder eine script-src-Richtlinie enthält, eine Seite nicht erlaubt, WebAssembly zu 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.

'unsafe-inline'

Standardmäßig wird, wenn eine CSP eine default-src oder eine script-src-Richtlinie enthält, Inline-JavaScript nicht ausgeführt. Dies umfasst:

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

Similarly, if a CSP contains default-src or a style-src-Richtlinie, 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.

'unsafe-hashes'

Standardmäßig wird, wenn eine CSP eine default-src oder eine script-src-Richtlinie enthält, Inline-Event-Handler Attribute wie onclick und Inline-style Attribute nicht ausgeführt.

Der Ausdruck 'unsafe-hashes' ermöglicht es dem Browser, Hash-Ausdrücke für Inline-Event-Handler und style Attribute zu verwenden. Zum Beispiel könnte eine CSP eine Richtlinie wie diese enthalten:

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

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

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

'inline-speculation-rules'

Standardmäßig wird, wenn eine CSP eine default-src oder eine script-src-Richtlinie enthält, Inline-JavaScript nicht ausgeführt. Das 'inline-speculation-rules' ermöglicht 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.

'strict-dynamic'

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

Wenn dieses Schlüsselwort in einer Richtlinie vorhanden ist, werden die folgenden Quellausdruck-Werte alle ignoriert:

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

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

'report-sample'

Wenn dieser Ausdruck in einer richtliniengesteuerten Richtlinie enthalten ist, und die Richtlinie dazu führt, dass der Browser alle Inline-Skripte, Inline-Stile oder Event-Handler Attribute blockiert, dann enthält der Verletzungsbericht, den der Browser erzeugt, eine sample Eigenschaft mit den ersten 40 Zeichen der blockierten Ressource.

CSP in Workern

Worker werden im Allgemeinen nicht von der Content-Security-Policy des Dokuments (oder der übergeordneten Worker) geregelt, das sie erstellt haben. Um eine Content-Security-Policy für den Worker festzulegen, setzen Sie einen Content-Security-Policy Antwort-Header für die Anfrage, die das Worker-Skript selbst angefordert hat.

Die Ausnahme dabei ist, wenn der Ursprung des Worker-Skriptes ein global eindeutiger Bezeichner ist (zum Beispiel, wenn seine URL ein Schema von Daten oder Blob hat). In diesem Fall erbt der Worker die Content-Security-Policy des Dokuments oder Workers, das ihn erstellt hat.

Mehrere Content-Security-Policies

Der CSP-Mechanismus erlaubt es, mehrere Richtlinien für eine Ressource zu spezifizieren, einschließlich über den Content-Security-Policy-Header, dem Content-Security-Policy-Report-Only-Header und einem <meta>-Element.

Sie können den Content-Security-Policy-Header mehrmals verwenden, wie im folgenden Beispiel. Achten Sie besonders auf die connect-src-Richtlinie hier. Obwohl die zweite Richtlinie die Verbindung erlauben würde, enthält die erste Richtlinie connect-src 'none'. Das Hinzufügen weiterer Richtlinien kann nur die Fähigkeiten der geschützten Ressource 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/

Beispiele

Deaktivieren Sie unsicheren Inline-Code und lassen Sie nur HTTPS-Ressourcen zu

Dieser HTTP-Header setzt die Standardrichtlinie, um ausschließlich das Laden von Ressourcen (Bildern, Schriften, Skripten usw.) über HTTPS zu erlauben. Da die unsafe-inline und unsafe-eval-Richtlinien nicht gesetzt sind, werden Inline-Skripts 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:" />

Erlauben Sie Inline-Code und HTTPS-Ressourcen, aber deaktivieren Sie Plugins

Diese Richtlinie könnte auf einer bestehenden Website 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'

Berichten, aber nicht durchsetzen von Verstößen bei Tests

Dieses Beispiel setzt dieselben Einschränkungen wie das vorherige Beispiel, jedoch mit dem Content-Security-Policy-Report-Only-Header und der report-to-Richtlinie. Dieser Ansatz wird während des Testens verwendet, um Verstöße zu melden, jedoch den Code nicht zu blockieren.

Endpunkte (URLs), an die Berichte gesendet werden, werden mithilfe des Reporting-Endpoints-HTTP-Antwort-Headers definiert.

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

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

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

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Content-Security-Policy-Report-Only
• Erfahren Sie mehr: Content Security Policy
• Inhaltsrichtlinien in WebExtensions
• Adopting a strict policy
• CSP Evaluator - Bewerten Sie Ihre Content-Security-Policy