Content-Security-Policy (CSP)

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

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

Fetch-Richtlinien 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-Richtlinien.

Fallback für alle anderen Fetch-Richtlinien.

fenced-frame-src Experimentell

Spezifiziert gültige Quellen für verschachtelte Browsing-Kontexte, die in <fencedframe>-Elemente geladen werden.

font-src

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

frame-src

Spezifiziert gültige Quellen für verschachtelte Browsing-Kontexte, die in Elemente wie <frame> und <iframe> geladen werden.

img-src

Spezifiziert gültige Quellen für Bilder und Favicons.

manifest-src

Spezifiziert gültige Quellen für Anwendungsmanifestdateien.

media-src

Spezifiziert gültige Quellen zum Laden von Medien mit den Elementen <audio>, <video> und <track>.

object-src

Spezifiziert gültige Quellen für die Elemente <object> und <embed>.

prefetch-src Veraltet Nicht standardisiert

Spezifiziert gültige Quellen zum Vorabrufen oder Vorerstellen.

script-src

Spezifiziert gültige Quellen für JavaScript- und WebAssembly-Ressourcen.

Fallback für script-src-elem und script-src-attr.

script-src-elem

Spezifiziert gültige Quellen für JavaScript-<script>-Elemente.

script-src-attr

Spezifiziert gültige Quellen für JavaScript-Inline-Ereignishandler.

style-src

Spezifiziert gültige Quellen für Stylesheets.

Fallback für style-src-elem und style-src-attr.

style-src-elem

Spezifiziert gültige Quellen für Stylesheets in <style>-Elementen und <link>-Elementen mit rel="stylesheet".

style-src-attr

Spezifiziert gültige Quellen für Inline-Stile, die auf einzelne DOM-Elemente angewendet werden.

worker-src

Spezifiziert gültige Quellen für Worker, SharedWorker oder ServiceWorker-Skripte.

Alle Fetch-Richtlinien können mit dem einzelnen Wert 'none' spezifiziert werden, was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert werden soll, oder mit einem oder mehreren source expression-Werten, die gültige Quellen für diesen Ressourcentyp angeben. Siehe Fetch-Richtlinien-Syntax für weitere Details.

Fallbacks

Einige Fetch-Richtlinien fungieren als Fallbacks für andere, spezifischere Richtlinien. Das bedeutet, wenn die spezifischere Richtlinie nicht angegeben ist, wird das Fallback verwendet, 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 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 script-src-elem und script-src weggelassen werden, aber default-src enthalten ist, wird die von default-src definierte Richtlinie auf <script>-Elemente angewendet.

Dokumentrichtlinien bestimmen die Eigenschaften eines Dokuments oder Workers-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 bestimmen, zu welchen Orten ein Benutzer navigieren oder ein Formular absenden kann, zum Beispiel.

form-action

Beschränkt die URLs, die als Ziel einer Formularübermittlung von einem gegebenen Kontext verwendet werden können.

frame-ancestors

Spezifiziert gültige Eltern, die eine Seite mittels <frame>, <iframe>, <object> oder <embed> einbetten dürfen.

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

report-to

Gibt dem Browser ein Token, das den Meldeendpunkt oder eine Gruppe von Endpunkten identifiziert, an die Informationen über CSP-Verletzungen gesendet werden sollen. Die Endpunkte, die das Token darstellt, werden durch andere HTTP-Header bereitgestellt, wie z.B. Reporting-Endpoints und Report-To Veraltet .

Warnung: Diese Richtlinie ist dazu gedacht, report-uri zu ersetzen; in Browsern, die report-to unterstützen, wird die report-uri-Richtlinie ignoriert. Bis report-to jedoch umfassend unterstützt wird, sollten Sie beide Header wie gezeigt angeben (wobei endpoint_name der Name eines separat bereitgestellten Endpunktes 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-Einschleusungspunkten.

trusted-types Experimentell

Wird verwendet, um eine Positivliste von Trusted Types-Richtlinien anzugeben. Trusted Types erlaubt es Anwendungen, DOM XSS-Einschleusungspunkte zu verriegeln, sodass nur nicht-verschleierbare, typisierte Werte anstelle von Zeichenfolgen akzeptiert werden.

upgrade-insecure-requests

Informiert Benutzeragenten, alle unsicheren URLs einer Seite (die über HTTP geliefert werden) so zu behandeln, als wären sie durch sichere URLs (die über HTTPS geliefert werden) ersetzt worden. Diese Richtlinie ist für Websites gedacht, die viele unsichere, veraltete URLs haben, die umgeschrieben werden müssen.

block-all-mixed-content Veraltet

Verhindert das Laden von beliebigen Assets ü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. Diese wurde durch die report-to-Richtlinie ersetzt.

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

• der Einzelwert 'none', was darauf hinweist, 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 hat eine der unten aufgeführten Formen. Beachten Sie, dass nicht alle Formen für alle Fetch-Richtlinien anwendbar sind: Siehe die Dokumentation jeder Fetch-Richtlinie, um herauszufinden, welche Formen für sie anwendbar sind.

Die Formate <host-source> und <scheme-source> müssen nicht umschlossen werden, und alle anderen Formate müssen in einfache Anführungszeichen eingeschlossen 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 jedes <script>- oder <style>-Ressourcen einschließen, die sie vom Dokument laden möchten.

Der Browser vergleicht den Wert aus der CSP-Richtlinie mit dem Wert im Elementattribut 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 Nonce im CSP-Leitfaden für weitere Anwendungsinformationen.

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 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 aller <script>- und <style>-Elemente, vergleicht das Ergebnis mit allen Hashes in der CSP-Richtlinie und lädt die Ressource nur, wenn es eine Übereinstimmung gibt.

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 Richtlinie einen Hash und unsafe-inline enthält, ignoriert der Browser unsafe-inline.

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

Die URL oder IP-Adresse eines Host, 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 auch Ressourcen von https://example.com
• ws://example.org erlaubt auch Ressourcen von wss://example.org.

Platzhalter ('*') können für Subdomains, Hostadressen und Portnummern verwendet werden, was darauf hinweist, dass alle legalen Werte jedes einzelnen 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, dessen Präfix sie 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 z. B. https:. Der Doppelpunkt ist erforderlich.

Sichere Upgrades sind erlaubt, so dass:

• 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. Zum Beispiel:

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

Standardmäßig, wenn eine CSP default-src oder eine script-src-Richtlinie enthält, 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 Zeichenfolgen als JavaScript zuzulassen.

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

Standardmäßig, wenn eine CSP eine default-src oder eine script-src-Richtlinie enthält, wird es einer Seite nicht erlaubt sein, WebAssembly mit 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, wenn eine CSP default-src oder eine script-src-Richtlinie enthält, wird Inline-JavaScript nicht zur Ausführung zugelassen. Dies schließt ein:

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

Ähnlich, wenn eine CSP default-src oder eine style-src-Richtlinie 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 zuzulassen.

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

Standardmäßig, wenn eine CSP default-src oder eine script-src-Richtlinie enthält, werden Inline-Ereignishandlerattribute wie onclick und Inline-style-Attribute nicht zur Ausführung zugelassen.

Der Ausdruck 'unsafe-hashes' erlaubt es dem Browser, hash expressions für Inline-Ereignishandler und style-Attribute zu verwenden. Zum Beispiel könnte eine CSP eine Richtlinie enthalten wie diese:

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

Wenn der Hash-Wert mit dem Hash-Wert eines Inline-Ereignishandlerattributs oder eines style-Attributswerts übereinstimmt, wird der Code zur Ausführung zugelassen.

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

Standardmäßig, wenn eine CSP default-src oder eine script-src-Richtlinie enthält, wird Inline-JavaScript nicht zur Ausführung zugelassen. Die 'inline-speculation-rules' erlaubt es dem Browser, Inline-<script>-Elemente zu laden, die ein type-Attribut von speculationrules haben.

Siehe die Speculation Rules API für weitere Informationen.

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

Ist dieses Schlüsselwort in einer Richtlinie vorhanden, werden die folgenden source expression-Werte alle ignoriert:

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

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

Wenn dieser Ausdruck in einer Richtlinie zur Steuerung von Skripten oder Stilen enthalten ist und die Richtlinie den Browser dazu veranlasst, Inline-Skripte, Inline-Stile oder Event-Handler-Attribute zu blockieren, enthält der Verletzungsbericht, den der Browser generiert, eine sample-Eigenschaft mit den ersten 40 Zeichen der blockierten Ressource.

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

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

Der CSP-Mechanismus erlaubt, dass mehrere Richtlinien für eine Ressource angegeben werden, einschließlich durch 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. Achten Sie besonders auf die connect-src-Richtlinie 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 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 so, dass das Laden von Ressourcen (Bilder, Schriftarten, Skripte usw.) nur über HTTPS zulässt. Da die unsafe-inline und unsafe-eval-Richtlinien nicht gesetzt sind, werden Inline-Skripte blockiert.

Content-Security-Policy: default-src https:

Die gleichen Einschränkungen können auch mit dem HTML-<meta>-Element angewendet werden.

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

Diese Richtlinie könnte auf einer vorhandenen Seite verwendet werden, die zu viel Inline-Code für eine Korrektur verwendet, 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 die gleichen Einschränkungen wie das vorherige Beispiel, jedoch unter Verwendung des Content-Security-Policy-Report-Only-Headers und der report-to-Richtlinie. Dieser Ansatz wird während des Testens verwendet, um Verstöße zu berichten, aber den Code nicht am Ausführen zu hindern.

Endpunkte (URLs) zur Übermittlung von Berichten werden mit dem Reporting-Endpoints-HTTP-Antwort-Header definiert.

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

Ein bestimmter Endpunkt wird dann als Berichtsziele in der CSP-Richtlinie mit der 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 spezifiziert ist, weil report-to von Browsern noch nicht umfassend unterstützt wird.

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

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