1. Web
  2. HTTP
  3. Reference
  4. Headers
  5. Content-Security-Policy

Dieser Inhalt wurde automatisch aus dem Englischen übersetzt, und kann Fehler enthalten. Erfahre mehr über dieses Experiment.

View in English Always switch to English

Content-Security-Policy (CSP) header

Baseline Weitgehend verfügbar *

Diese Funktion ist gut etabliert und funktioniert auf vielen Geräten und in vielen Browserversionen. Sie ist seit August 2016 browserübergreifend verfügbar.

* Einige Teile dieser Funktion werden möglicherweise unterschiedlich gut unterstützt.

Der HTTP Content-Security-Policy Antwort-Header ermöglicht es Website-Administratoren, die Ressourcen zu kontrollieren, die der User-Agent für eine gegebene Seite laden darf. Mit wenigen Ausnahmen beinhalten Richtlinien größtenteils die Spezifikation von Serverursprüngen und Skriptendpunkten. Dies hilft, Cross-Site-Scripting-Angriffe zu verhindern.

Verstöße können mithilfe der Reporting API gemeldet werden. Berichte können auf der Seite, für die die Richtlinie durchgesetzt wird, beobachtet werden, indem ein ReportingObserver verwendet wird, und an Serverendpunkte gesendet werden, die in einem Reporting-Endpoints HTTP-Antwort-Header definiert und ausgewählt werden, indem die CSP-Direktive report-to verwendet wird. Weitere Informationen finden Sie unter CSPViolationReport.

Siehe den Content Security Policy (CSP) Leitfaden für Details, wie eine CSP an den Browser übermittelt wird, wie sie aussieht, sowie Anwendungsfälle und Einsatzstrategien.

Header-Typ Antwort-Header

Syntax

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

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

Direktiven

Fetch-Direktiven

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

Alle Fetch-Direktiven können mit dem einzelnen Wert 'none' angegeben werden, was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert wird, 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, detailliertere Direktiven. Das bedeutet, dass, wenn die detailliertere Direktive nicht angegeben ist, dann 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, dann wird die von default-src definierte Richtlinie auf Bilder angewendet.
  • Wenn script-src-elem ausgelassen wird, aber script-src enthalten ist, dann 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, dann wird die von default-src definierte Richtlinie auf <script>-Elemente angewendet.

Dokument-Direktiven

Dokument-Direktiven regeln die Eigenschaften eines Dokuments oder Worker-Umfeldes, auf das eine Richtlinie zutrifft.

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.

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

form-action

Beschränkt die URLs, die als Ziel einer Formularübermittlung 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 dürfen.

Bericht-Direktiven

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

report-to

Stellt dem Browser ein Token zur Verfügung, das den Berichtsendpunkt oder die Gruppe von Endpunkten identifiziert, an die Informationen über CSP-Verstöße gesendet werden sollen. Die Endpunkte, die das Token darstellt, werden über andere HTTP-Header bereitgestellt, wie Reporting-Endpoints und Report-To .

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

Andere Direktiven

require-trusted-types-for

Erzwingt Trusted Types an den DOM XSS-Injektionssenken.

trusted-types

Wird verwendet, um eine Positivliste von Trusted Types-Richtlinien zu spezifizieren. Trusted Types ermöglichen es Anwendungen, DOM XSS-Injektionssenken so zu sperren, dass sie nur nicht fälschbare, typisierte Werte anstelle von Zeichenfolgen akzeptieren.

upgrade-insecure-requests

Weist Benutzeragenten an, alle unsicheren URLs einer Website (die über HTTP bedient werden) so zu behandeln, als wären sie durch sichere URLs (die über HTTPS bedient werden) ersetzt worden. Diese Direktive ist für Webseiten gedacht, die eine große Anzahl unsicherer alter URLs haben, die umgeschrieben werden müssen.

Veraltete Direktiven

block-all-mixed-content

Verhindert das Laden von Vermögenswerten über HTTP, wenn die Seite mit HTTPS geladen wird.

report-uri

Stellt dem Browser eine URL zur Verfügung, an die CSP-Verstoßberichte gesendet werden sollen. Diese wurde von der report-to-Direktive ersetzt.

Fetch-Direktiven-Syntax

Alle Fetch-Direktiven können als einer der folgenden angegeben werden:

  • der einzelne Wert 'none', was bedeutet, dass der spezifische Ressourcentyp vollständig blockiert wird
  • ein oder mehrere Source-Expression-Werte, die gültige Quellen für diesen Ressourcentyp angeben.

Jede Source-Expression nimmt eine der unten aufgeführten Formen an. Beachten Sie, dass nicht alle Formen für alle Fetch-Direktiven zutreffen: siehe die Dokumentation für jede Fetch-Direktive, um herauszufinden, welche Formen für sie zutreffen.

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

'nonce-<nonce_value>'

Dieser Wert besteht aus dem String nonce- gefolgt von einem Nonce-Wert. Der Nonce-Wert kann beliebige Zeichen aus Base64 oder URL-sicherem Base64 verwenden.

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 für alle <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 mehr Informationen zur Verwendung.

Hinweis: Nonce-Quellausdrücke sind nur für <script> und <style> Elemente anwendbar.

'<hash_algorithm>-<hash_value>'

Dieser Wert besteht aus einem String, der einen Hash-Algorithmus identifiziert, gefolgt von -, gefolgt von einem Hash-Wert. Der Hash-Wert kann beliebige Zeichen aus Base64 oder URL-sicherem Base64 verwenden.

  • 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, hashiert 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 es eine Übereinstimmung gibt.

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

Hinweis: Hash-Quellausdrücke sind nur für <script> und <style> Elemente anwendbar.

<host-source>

Die URL oder die 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 ausgelassen wird, wird das Schema des Ursprungs des Dokuments verwendet.

Bei der Übereinstimmung von Schemata sind sichere Upgrades erlaubt. Zum Beispiel:

  • http://example.com wird auch Ressourcen von https://example.com zulassen
  • ws://example.org wird auch Ressourcen von wss://example.org zulassen.

Platzhalter ('*') können für Subdomains, Hostadressen und Portnummern verwendet werden, was bedeutet, dass alle legalen Werte von jedem gültig sind. Zum Beispiel:

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

Pfade, die mit / enden, passen zu jedem Pfad, den sie ein Präfix bilden. 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.

<scheme-source>

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

Sichere Upgrades sind erlaubt, so dass:

  • http: wird auch Ressourcen erlauben, die über HTTPS geladen werden
  • ws: wird auch Ressourcen erlauben, die über WSS geladen werden.

'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 bedient wird, wird eine CSP von 'self' auch Ressourcen von https://example.com zulassen.
  • Wenn das Dokument von ws://example.org bedient 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 Direktive enthält, werden 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 trusted-types-eval Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben, aber nur, wenn Trusted Types durchgesetzt werden und anstelle von Zeichenfolgen an diese Funktionen übergeben werden. Dies ermöglicht die dynamische Auswertung von Zeichenfolgen als JavaScript, jedoch nur, nachdem Eingaben durch eine Transformationsfunktion geleitet wurden, bevor sie injiziert werden, die die Möglichkeit zum Bereinigen der Eingabe hat, um potenziell gefährliches Markup zu entfernen.

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

Hinweis: Entwickler sollten die Verwendung von trusted-types-eval oder dieser Methoden vermeiden, es sei denn, dies ist absolut notwendig. Trusted Types stellen sicher, dass die Eingabe durch eine Transformationsfunktion geleitet wird – sie stellen nicht sicher, dass die Transformation die Eingabe sicher macht (und dies kann sehr schwierig richtig zu machen sein).

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

'unsafe-eval'

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, werden 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 zu ermöglichen.

Warnung: Entwickler sollten 'unsafe-eval' vermeiden, da dies einen Großteil des Zwecks einer CSP zunichte macht. 'trusted-types-eval' bietet eine "potenziell" sicherere Alternative, wenn die Verwendung dieser Methoden notwendig ist.

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

'wasm-unsafe-eval'

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, wird eine Seite nicht erlaubt, 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 die allgemeine Auswertung von JavaScript nicht ermöglicht.

'unsafe-inline'

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

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

Ebenso, wenn eine CSP eine 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 alle diese Formen zu laden.

Warnung: Entwickler sollten 'unsafe-inline' vermeiden, da es einen Großteil des Zwecks einer CSP zunichte macht.

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

'unsafe-hashes'

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

Die 'unsafe-hashes' Expression erlaubt es dem Browser, Hash-Ausdrücke für Inline-Event-Handler und style Attribute zu verwenden. Zum Beispiel könnte eine CSP eine Direktive wie diese enthalten:

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

Warnung: Der 'unsafe-hashes' Wert ist unsicher.

Insbesondere ermöglicht er einen Angriff, bei dem der Inhalt des Inline-Event-Handler-Attributs als Inline <script>-Element in das Dokument injiziert wird. Angenommen, der Inline-Event-Handler ist:

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

Wenn ein Angreifer ein Inline <script>-Element mit diesem Code injizieren kann, wird die CSP es automatisch ausführen lassen.

'unsafe-hashes' ist jedoch viel sicherer als 'unsafe-inline'.

'inline-speculation-rules'

Standardmäßig, wenn eine CSP eine default-src oder eine script-src Direktive enthält, ist das Ausführen von Inline-JavaScript nicht erlaubt. '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.

'strict-dynamic'

Das 'strict-dynamic' Schlüsselwort lässt das Vertrauen, das durch eine Nonce oder einen Hash auf ein Skript übertragen wird, auf Skripte ausweiten, 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().

Wenn dieses Schlüsselwort in einer Direktive vorhanden ist, werden die folgenden Quellaufrufwerte alle ignoriert:

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

'report-sample'

Wenn dieser Ausdruck in einer Direktive enthalten ist, die Skripte oder Stile steuert, und die Direktive dazu führt, dass der Browser jegliche Inline-Skripte, Inline-Stile oder Event-Handler-Attribute blockiert, enthält der Violationsbericht, den der Browser erstellt, eine sample Eigenschaft, die die ersten 40 Zeichen der blockierten Ressource enthält.

CSP in Workern

Worker werden im Allgemeinen nicht von der Content Security Policy des Dokuments (oder übergeordneten Workers) gesteuert, das sie erstellt hat. Um eine Content Security Policy 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 ist, wenn der Ursprung des Worker-Skripts ein global eindeutiges Identifikator 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, der ihn erstellt hat.

Mehrere Content Security Policies

Der CSP-Mechanismus ermöglicht die Spezifikation mehrerer Richtlinien für eine Ressource, 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 unten stehenden 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 nur weiter einschränken die Fähigkeiten der geschützten Ressource, was bedeutet, dass keine Verbindung erlaubt ist und, als die strengste Richtlinie, connect-src 'none' durchgesetzt wird.

http
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

Unsicherer Inline-Code deaktivieren und nur HTTPS-Ressourcen zulassen

Dieser HTTP-Header legt die Standardrichtlinie so fest, dass das Laden von Ressourcen (Bildern, Schriften, Skripten usw.) nur über HTTPS erlaubt ist. Da die Direktiven unsafe-inline und unsafe-eval nicht gesetzt sind, werden Inline-Skripte blockiert.

http
Content-Security-Policy: default-src https:

Dieselben Beschränkungen können mithilfe des HTML <meta>-Elements angewendet werden.

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

Inline-Code und HTTPS-Ressourcen zulassen, aber Plugins deaktivieren

Diese Richtlinie könnte auf einer bestehenden Seite verwendet werden, die zu viel Inline-Code verwendet, um sie zu reparieren – um sicherzustellen, dass Ressourcen nur über HTTPS geladen werden und Plugins deaktiviert werden:

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

Verstöße melden, aber beim Testen nicht durchsetzen

Dieses Beispiel setzt dieselben Beschränkungen wie das vorherige Beispiel, verwendet jedoch den Content-Security-Policy-Report-Only Header und die report-to Direktive. Dieser Ansatz wird während des Testens verwendet, um Verstöße zu melden, aber nicht das Ausführen von Code zu blockieren.

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

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

Ein bestimmter Endpunkt wird dann im CSP-Richtlinie als Berichtsziel mithilfe der report-to Direktive ausgewählt.

http
Content-Security-Policy-Report-Only: default-src https:; report-uri /csp-violation-report-url/; report-to csp-endpoint

Beachten Sie, dass die report-uri -Direktive oben ebenfalls angegeben ist, da report-to noch nicht weit verbreitet von Browsern unterstützt wird.

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

Spezifikationen

Spezifikation
Content Security Policy Level 3
# csp-header

Browser-Kompatibilität

Siehe auch

Help improve MDN

Erfahren Sie, wie Sie beitragen können Diese Seite wurde automatisch aus dem Englischen übersetzt.
Übersetzung auf GitHub anzeigen • Fehler mit dieser Übersetzung melden