Content-Security-Policy
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since August 2016.
Der HTTP Content-Security-Policy
Antwort-Header erlaubt es Website-Administratoren, die Ressourcen zu kontrollieren, die der Benutzeragent für eine gegebene Seite laden darf. Mit wenigen Ausnahmen beinhalten Richtlinien hauptsächlich die Spezifizierung von Serverursprüngen und Skript-Endpunkten. Dies hilft, gegen Cross-Site-Scripting-Angriffe zu schützen.
Für weitere Informationen siehe den einführenden Artikel zur Content Security Policy (CSP).
Typ des Headers | Antwort-Header |
---|---|
Verbotener Header-Name | nein |
Syntax
Content-Security-Policy: <policy-directive>; <policy-directive>
wobei <policy-directive>
aus folgendem besteht:
<directive> <value>
ohne interne Zeichensetzung.
Direktiven
Fetch-Direktiven
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 Betrachtungs-Kontexte, die mit Elementen wie
<frame>
und<iframe>
geladen werden.Fallback für
frame-src
undworker-src
. connect-src
-
Beschränkt die URLs, die mittels 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 Betrachtungs-Kontexte in
<fencedframe>
-Elementen an. font-src
-
Gibt gültige Quellen für Schriften an, die mittels
@font-face
geladen werden. frame-src
-
Gibt gültige Quellen für verschachtelte Betrachtungs-Kontexte in Elementen wie
<frame>
und<iframe>
an. 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
<audio>
,<video>
und<track>
Elementen an. object-src
-
Gibt gültige Quellen für die
<object>
und<embed>
Elemente an. prefetch-src
Veraltet Nicht standardisiert-
Gibt gültige Quellen für das Vorladen oder Vorberechnen an.
script-src
-
Gibt gültige Quellen für JavaScript- und WebAssembly-Ressourcen an.
Fallback für
script-src-elem
undscript-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
undstyle-src-attr
. style-src-elem
-
Gibt gültige Quellen für Stylesheets
<style>
Elemente und<link>
Elemente mitrel="stylesheet"
an. style-src-attr
-
Gibt gültige Quellen für inline Stile, die auf einzelne DOM-Elemente angewendet werden, an.
worker-src
-
Gibt gültige Quellen für
Worker
,SharedWorker
oderServiceWorker
Skripte an.
Alle Fetch-Direktiven können als einzelner Wert 'none'
angegeben werden, was anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden sollte, oder als einer oder mehrere Source Expression-Werte, die gültige Quellen für diesen Ressourcentyp anzeigen. Siehe Fetch-Direktiven-Syntax für mehr Details.
Fallbacks
Einige Fetch-Direktiven funktionieren 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ürscript-src-attr
undscript-src-elem
.style-src
ist ein Fallback fürstyle-src-attr
undstyle-src-elem
.child-src
ist ein Fallback fürframe-src
undworker-src
.
Beispielsweise:
- Wenn
img-src
weggelassen wird, aberdefault-src
enthalten ist, dann wird die vondefault-src
definierte Richtlinie auf Bilder angewendet. - Wenn
script-src-elem
weggelassen wird, aberscript-src
enthalten ist, dann wird die vonscript-src
definierte Richtlinie auf<script>
-Elemente angewendet. - Wenn
script-src-elem
undscript-src
weggelassen werden, aberdefault-src
enthalten ist, dann wird die vondefault-src
definierte Richtlinie auf<script>
-Elemente angewendet.
Dokumentdirektiven
Dokumentdirektiven regeln die Eigenschaften eines Dokuments oder Worker-Umgebung, auf die eine Richtlinie angewendet wird.
Navigationsdirektiven
Navigationsdirektiven regeln, zu welchen Orten ein Benutzer navigieren oder ein Formular einreichen kann, zum Beispiel.
form-action
-
Beschränkt die URLs, die als Ziel von Formulareinreichungen 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 können.
Berichtsdirektiven
Berichtsdirektiven steuern 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 Berichtsendpunkt oder die Gruppe von Berichts-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
undReport-To
Veraltet .Warnung: Diese Direktive soll
report-uri
ersetzen; in Browsern, diereport-to
unterstützen, wird die Direktivereport-uri
ignoriert. Bisreport-to
jedoch breit unterstützt wird, sollten Sie beide Header wie gezeigt angeben (wobeiendpoint_name
der Name eines separat bereitgestellten Endpunkts ist):httpContent-Security-Policy: …; report-uri https://endpoint.example.com; report-to endpoint_name
Andere Direktiven
require-trusted-types-for
Experimentell-
Erzwingt Trusted Types an den DOM-XSS-Injektionsstellen.
trusted-types
Experimentell-
Wird verwendet, um eine Positivliste von Trusted Types-Richtlinien anzugeben. Trusted Types erlaubt Anwendungen, DOM-XSS-Injektionsstellen so zu sichern, dass sie nur nicht manipulierbare, typisierte Werte anstelle von Strings 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, älterer URLs gedacht, die umgeschrieben werden müssen.
Veraltete Direktiven
block-all-mixed-content
Veraltet-
Verhindert das Laden jeglicher Ressourcen über HTTP, wenn die Seite über HTTPS geladen wird.
report-uri
Veraltet-
Bietet dem Browser eine URL, an die CSP-Verletzungsberichte gesendet werden sollen. Dies wurde durch die
report-to
Direktive ersetzt.
Fetch-Direktiven-Syntax
Alle Fetch-Direktiven können als einer der folgenden Werte angegeben werden:
- der einzelne Wert
'none'
, der anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden soll - eine oder mehrere Source Expression-Werte, die gültige Quellen für diesen Ressourcentyp anzeigen.
Jede Source Expression nimmt eine der unten aufgeführten Formen an. Beachten Sie, dass nicht alle Formen auf alle Fetch-Direktiven anwendbar sind: siehe die Dokumentation zu jeder Fetch-Direktive, um herauszufinden, welche Formen darauf anwendbar sind.
Die Formate <host-source>
und <scheme-source>
müssen unzitiert sein, und alle anderen Formate müssen in einfache Anführungszeichen gesetzt werden.
'nonce-<nonce_value>'
Dieser Wert besteht aus dem String nonce-
gefolgt von einem Base64-codierten String. Dieser String ist ein zufälliger Wert, den der Server für jede HTTP-Antwort generiert. Beispiel:
'nonce-416d1177-4d12-4e3b-b7c9-f6c409789fb8'
Der Server kann dann den gleichen Wert als Wert des nonce
-Attributs von jedem <script>
oder <style>
Ressourcen, die sie aus dem Dokument laden möchten, aufnehmen.
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 eine 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 einem String, der einen Hash-Algorithmus identifiziert, gefolgt von -
, gefolgt von einem Base64-codierten String, der den Hash-Wert repräsentiert.
- Der Hash-Algorithmus-Identifikator muss einer von
sha256
,sha384
odersha512
sein. - Der Hash-Wert ist der Base64-codierte Hash einer
<script>
oder<style>
Ressource, berechnet mit einer der folgenden Hash-Funktionen: SHA-256, SHA-384, oder SHA-512.
Beispiel:
'sha256-cd9827ad...'
Wenn der Browser das Dokument empfängt, hasht er den Inhalt aller <script>
und <style>
Elemente, vergleicht das Ergebnis mit den 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 unter Verwendung des src
Attributs), muss das Element auch das integrity
Attribut enthalten.
Wenn eine Direktive 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 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 Dokuments ursprungs verwendet.
Beim Schema-Vergleich sind sichere Upgrades erlaubt. Zum Beispiel:
http://example.com
erlaubt auch Ressourcen vonhttps://example.com
ws://example.org
erlaubt auch Ressourcen vonwss://example.org
.
Platzhalter ('*'
) können für Subdomains, Host-Adressen und Portnummern verwendet werden, um anzuzeigen, dass alle legalen Werte jeweils gültig sind. Zum Beispiel:
http://*.example.com
erlaubt Ressourcen von jeder Subdomain vonexample.com
, über HTTP oder HTTPS.
Pfade, die mit /
enden, stimmen mit jedem Pfad überein, dem sie Präfix sind. Zum Beispiel:
example.com/api/
erlaubt Ressourcen vonexample.com/api/users/new
.
Pfade, die nicht mit /
enden, werden genau abgeglichen. Zum Beispiel:
https://example.com/file.js
erlaubt Ressourcen vonhttps://example.com/file.js
aber nichthttps://example.com/file.js/file2.js
.
<scheme-source>
Ein Schema, wie https:
. Der Doppelpunkt ist erforderlich.
Sichere Upgrades sind erlaubt, also:
http:
erlaubt auch Ressourcen, die über HTTPS geladen werdenws:
erlaubt auch Ressourcen, die über WSS geladen werden.
'self'
Ressourcen des gegebenen Typs dürfen nur vom selben Ursprung wie das Dokument geladen werden.
Sichere Upgrades sind erlaubt. Beispiel:
- Wenn das Dokument von
http://example.com
bereitgestellt wird, dann erlaubt ein CSP mit'self'
auch Ressourcen vonhttps://example.com
. - Wenn das Dokument von
ws://example.org
bereitgestellt wird, dann erlaubt ein CSP mit'self'
auch Ressourcen vonwss://example.org
.
'unsafe-eval'
Standardmäßig, wenn ein CSP eine default-src
oder eine script-src
Direktive enthält, sind JavaScript-Funktionen, die ihre Argumente als JavaScript auswerten, deaktiviert. Dies schließt eval()
, das code
Argument zu setTimeout()
, oder den Funktion()
Konstruktor ein.
Das unsafe-eval
Schlüsselwort kann verwendet werden, um diesen Schutz rückgängig zu machen, um die dynamische Auswertung von Strings als JavaScript zu ermöglichen.
Warnung: Entwickler sollten 'unsafe-eval'
vermeiden, da es einen Großteil des Zwecks eines CSP aushebelt.
Siehe eval()
und ähnliche APIs im CSP-Leitfaden für weitere Nutzungsinformationen.
'wasm-unsafe-eval'
Standardmäßig, wenn ein CSP eine default-src
oder eine script-src
Direktive enthält, wird es einer Seite nicht erlaubt, WebAssembly mit Funktionen wie WebAssembly.compileStreaming()
zu kompilieren.
Das wasm-unsafe-eval
Schlüsselwort kann verwendet werden, um diesen Schutz rückgängig zu machen. Dies ist eine viel sicherere Alternative zu 'unsafe-eval'
, da es keine allgemeine Auswertung von JavaScript ermöglicht.
'unsafe-inline'
Standardmäßig, wenn ein CSP eine default-src
oder eine script-src
Direktive enthält, ist es Inline-JavaScript nicht erlaubt, ausgeführt zu werden. Dies schließt ein:
- Inline
<script>
Tags - Inline Event-Handler-Attribute
javascript:
URLs.
Ähnlich, wenn ein 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 rückgängig zu machen und alle diese Formen zu laden.
Warnung: Entwickler sollten 'unsafe-inline'
vermeiden, da es einen Großteil des Zwecks eines CSP aushebelt.
Siehe Inline-JavaScript im CSP-Leitfaden für weitere Nutzungsinformationen.
'unsafe-hashes'
Standardmäßig, wenn ein CSP eine default-src
oder eine script-src
Direktive enthält, sind Inline Event-Handler-Attribute wie onclick
und Inline style
Attribute nicht erlaubt, ausgeführt zu werden.
Die 'unsafe-hashes'
Expression erlaubt es dem Browser, Hash-Ausdrücke für Inline-Event-Handler und style
Attribute zu verwenden. Beispiel: Ein CSP könnte 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, dann wird der Code erlaubt, ausgeführt zu werden.
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:
<button onclick="transferAllMyMoney()">
Übertragen Sie mein gesamtes Geld
</button>
Wenn ein Angreifer ein Inline <script>
Element mit diesem Code injizieren kann, wird der CSP es automatisch erlauben, es auszuführen.
Allerdings ist 'unsafe-hashes'
viel sicherer als 'unsafe-inline'
.
'inline-speculation-rules'
Standardmäßig, wenn ein CSP eine default-src
oder eine script-src
Direktive enthält, ist es Inline-JavaScript nicht erlaubt, ausgeführt zu werden. Die 'inline-speculation-rules'
erlaubt 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 eine Nonce oder einen Hash verliehen wird, auf Skripte, die dieses Skript dynamisch lädt, zum Beispiel, indem neue <script>
Tags mittels Document.createElement()
erstellt und dann mit Node.appendChild()
in das Dokument eingefügt werden.
Wenn dieses Schlüsselwort in einer Direktive vorhanden ist, werden die folgenden Source-Expressions alle ignoriert:
Siehe Das strict-dynamic
Schlüsselwort im CSP-Leitfaden für weitere Nutzungsinformationen.
'report-sample'
Wenn dieser Ausdruck in einer Direktive enthalten ist, die Skripte oder Stile kontrolliert, und die Direktive dazu führt, dass der Browser Inline-Skripte, Inline-Stile oder Event-Handler-Attribute blockiert, wird der Verletzungsbericht, den der Browser generiert, eine sample
Eigenschaft enthalten, die die ersten 40 Zeichen der blockierten Ressource enthält.
CSP in Workern
Worker werden im Allgemeinen nicht durch die Content-Security-Richtlinie des Dokuments (oder des übergeordneten Workers) gesteuert, das sie erstellt hat. Um eine Content-Security-Richtlinie für den Worker anzugeben, setzen Sie einen Content-Security-Policy
Antwort-Header für die Anforderung, die das Worker-Skript selbst angefordert hat.
Die Ausnahme von dieser Regel 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 Content-Security-Richtlinie des Dokuments oder Workers, das ihn erstellt hat.
Mehrere Content-Security-Richtlinien
Der CSP-Mechanismus erlaubt es, mehrere Richtlinien für eine Ressource anzugeben, 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 folgenden 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 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/
Beispiele
Unsicheren Inline-Code deaktivieren und nur HTTPS-Ressourcen zulassen
Dieser HTTP-Header setzt die Standardrichtlinie, um das Laden von Ressourcen (Bilder, Schriftarten, Skripte usw.) nur über HTTPS zu erlauben. 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 unter Verwendung des HTML-<meta>
Elements angewendet werden.
<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 bereits existierenden Seite 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'
Verstöße melden, aber während des Testens nicht durchsetzen
Dieses Beispiel setzt dieselben 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 den Code nicht daran zu hindern, ausgeführt zu werden.
Endpunkte (URLs), an die Berichte gesendet werden sollen, werden unter Verwendung des Reporting-Endpoints
HTTP-Antwort-Headers definiert.
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
Ein bestimmter Endpunkt wird dann als Berichts-Ziel in der CSP-Richtlinie unter Verwendung 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 ebenfalls oben angegeben ist, da report-to
noch nicht breit von Browsern unterstützt wird.
Siehe Content Security Policy (CSP) Implementierung für weitere Beispiele.
Spezifikationen
Specification |
---|
Content Security Policy Level 3 # csp-header |
Browser-Kompatibilität
BCD tables only load in the browser
Siehe auch
Content-Security-Policy-Report-Only
- Erfahren Sie mehr über: Content Security Policy
- Content Security in WebExtensions
- Annahme einer strengen Richtlinie
- CSP Evaluator - Bewerten Sie Ihre Content Security Policy