Content-Security-Policy (CSP)
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.
* Some parts of this feature may have varying levels of support.
Der HTTP-Header Content-Security-Policy
ermöglicht 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 Angabe von Serverursprüngen und Skript-Endpunkten.
Dies hilft, Cross-Site Scripting-Angriffe zu verhindern.
Details zur Bereitstellung einer CSP im Browser, deren Aussehen sowie Anwendungsfälle und Einsatzstrategien finden Sie im Content Security Policy (CSP) Leitfaden.
Header-Typ | Antwort-Header |
---|---|
Verbotener Header-Name | nein |
Syntax
Content-Security-Policy: <policy-directive>; <policy-directive>
wobei <policy-directive>
besteht aus:
<directive> <value>
ohne interne Interpunktion.
Richtlinien
Fetch-Richtlinien
Fetch-Richtlinien kontrollieren die Orte, von denen bestimmte Ressourcentypen geladen werden dürfen.
child-src
-
Definiert die gültigen Quellen für Web Workers und verschachtelte Browsing-Kontexte, die mit Elementen wie
<frame>
und<iframe>
geladen wurden.Fallback für
frame-src
undworker-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 Anwendungsmanifest-Dateien 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 zum Vorababrufen oder Vorausladen 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-Ereignis-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 an, die auf individuelle DOM-Elemente angewendet werden.
worker-src
-
Gibt gültige Quellen für
Worker
,SharedWorker
oderServiceWorker
Skripte an.
Alle Fetch-Richtlinien können den einzigen Wert 'none'
enthalten, was angibt, dass der spezifische Ressourcentyp vollständig blockiert werden soll, oder als ein oder mehrere Quell-Ausdruck-Werte, 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, detailliertere Richtlinien. Das bedeutet, dass wenn die detailliertere 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ü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
ausgelassen, aberdefault-src
eingeschlossen wird, dann wird die Richtlinie vondefault-src
auf Bilder angewendet. - Wenn
script-src-elem
ausgelassen, aberscript-src
eingeschlossen wird, dann wird die Richtlinie vonscript-src
auf<script>
-Elemente angewendet. - Wenn
script-src-elem
undscript-src
beide ausgelassen werden, aberdefault-src
eingeschlossen ist, dann wird die Richtlinie vondefault-src
auf<script>
-Elemente angewendet.
Dokument-Richtlinien
Dokument-Richtlinien regeln die Eigenschaften eines Dokuments oder Worker Umgebung, auf die eine Richtlinie anzuwenden ist.
Navigations-Richtlinien
Navigations-Richtlinien regeln, zu welchen Orten ein Benutzer navigieren oder ein Formular absenden 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 Eltern 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
-
Gibt dem Browser ein Token, das den Berichtsendpunkt oder eine Gruppe von Endpunkten identifiziert, an die Informationen über CSP-Verletzungen gesendet werden sollen. Die Endpunkte, die das Token repräsentiert, werden über andere HTTP-Header bereitgestellt, wie
Reporting-Endpoints
undReport-To
Veraltet .Warnung: Diese Direktive soll
report-uri
ersetzen; in Browsern, diereport-to
unterstützen, wird diereport-uri
-Direktive ignoriert. Bisreport-to
jedoch umfassend 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 Richtlinien
require-trusted-types-for
Experimentell-
Erzwingt Trusted Types an den DOM XSS-Injektionspunkten.
trusted-types
Experimentell-
Wird verwendet, um eine Positivliste von Trusted Types-Richtlinien anzugeben. Trusted Types ermöglicht es Anwendungen, DOM XSS-Injektionspunkte so zu sperren, dass nur nicht fälschbare, typisierte Werte anstelle von Strings akzeptiert werden.
upgrade-insecure-requests
-
Weist Benutzeragenten an, alle unsicheren URLs einer Site (die über HTTP bereitgestellt werden) so zu behandeln, als wären sie durch sichere URLs (die über HTTPS bereitgestellt werden) ersetzt worden. Diese Richtlinie ist für Websites vorgesehen, die eine große Anzahl unsicherer veralteter 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-
Gibt dem Browser eine URL, an die CSP-Verletzungsberichte gesendet werden sollen. Dies wurde durch die
report-to
-Richtlinie abgelöst.
Fetch-Richtlinien-Syntax
Alle Fetch-Richtlinien können als einer der folgenden Werte angegeben werden:
- Der Einzelwert
'none'
, der angibt, dass der spezifische Ressourcentyp vollständig blockiert werden soll - Ein oder mehrere Quell-Ausdruck Werte, die gültige Quellen für diesen Ressourcentyp angeben.
Jeder Quell-Ausdruck nimmt eine der unten aufgeführten Formen an. Beachten Sie, dass nicht alle Formen für alle Fetch-Richtlinien anwendbar sind: Sehen Sie in der Dokumentation zu jeder Fetch-Richtlinie nach, welche Formen anwendbar sind.
Die Formate <host-source>
und <scheme-source>
müssen ohne Anführungszeichen angegeben werden, und alle anderen Formate müssen in einfache Anführungszeichen eingeschlossen sein.
'nonce-<nonce_value>'
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 für alle <script>
- oder <style>
-Ressourcen einfügen, die sie aus dem Dokument laden möchten.
Der Browser vergleicht den Wert aus der CSP-Direktive mit dem Wert im Elementattribut 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 Informationen zur Nutzung.
'<hash_algorithm>-<hash_value>'
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-Bezeichner muss einer der folgenden sein:
sha256
,sha384
odersha512
. - 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 jeglicher <script>
- und <style>
-Elemente, vergleicht das Ergebnis mit den Hashs 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 mit dem 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 weitere Informationen zur Nutzung.
<host-source>
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 Vergleichen von Schemata 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, 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 vonexample.com
, über HTTP oder HTTPS.
Pfade, die mit /
enden, passen auf alle Pfade, deren Präfix sie sind. Zum Beispiel:
example.com/api/
erlaubt Ressourcen vonexample.com/api/users/new
.
Pfade, die nicht mit /
enden, werden exakt 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 z. B. https:
. Der Doppelpunkt ist erforderlich.
Sichere Upgrades sind erlaubt, daher:
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 aus demselben Ursprung wie das Dokument geladen werden.
Sichere Upgrades sind erlaubt. Zum Beispiel:
- Wenn das Dokument von
http://example.com
bereitgestellt wird, erlaubt ein CSP von'self'
auch Ressourcen vonhttps://example.com
. - Wenn das Dokument von
ws://example.org
bereitgestellt wird, erlaubt ein CSP von'self'
auch Ressourcen vonwss://example.org
.
'unsafe-eval'
Standardmäßig, wenn eine CSP eine default-src
- oder script-src
-Richtlinie enthält, sind JavaScript-Funktionen, die ihre Argumente als JavaScript auswerten, deaktiviert. Dazu gehören eval()
, das code
Argument zu setTimeout()
oder der Function()
Konstruktor.
Das Schlüsselwort unsafe-eval
kann verwendet werden, um diesen Schutz aufzuheben und die dynamische Auswertung von Strings als JavaScript zuzulassen.
Warnung:
Entwickler sollten 'unsafe-eval'
vermeiden, da es den Zweck einer CSP weitgehend zunichte macht.
Siehe eval()
und ähnliche APIs im CSP-Leitfaden für mehr Informationen zur Nutzung.
'wasm-unsafe-eval'
Standardmäßig, wenn eine CSP eine default-src
- oder script-src
-Richtlinie enthält, wird eine Seite nicht erlaubt, WebAssembly zu kompilieren, indem Funktionen wie WebAssembly.compileStreaming()
verwenden werden.
Das Schlüsselwort wasm-unsafe-eval
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, wenn eine CSP eine default-src
- oder script-src
-Richtlinie enthält, darf kein Inline-JavaScript ausgeführt werden. Dazu gehören:
- Inline-
<script>
-Tags - Inline-Ereignis-Handler-Attribute
javascript:
-URLs.
Ebenso, wenn eine CSP default-src
oder eine style-src
-Richtlinie enthält, wird kein Inline-CSS geladen, einschließlich:
- Inline-
<style>
-Tags style
Attribute.
Das Schlüsselwort unsafe-inline
kann verwendet werden, um diesen Schutz aufzuheben und alle diese Formen zuzulassen.
Warnung:
Entwickler sollten 'unsafe-inline'
vermeiden, da es den Zweck einer CSP weitgehend zunichte macht.
Siehe Inline-JavaScript im CSP-Leitfaden für mehr Informationen zur Nutzung.
'unsafe-hashes'
Standardmäßig, wenn eine CSP eine default-src
- oder eine script-src
-Richtlinie enthält, dürfen Inline-Ereignis-Handler-Attribute wie onclick
und Inline-style
-Attribute nicht ausgeführt werden.
Der Ausdruck 'unsafe-hashes'
erlaubt es dem Browser, Hash-Ausdrücke für Inline-Ereignis-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-Ereignis-Handler-Attributwerts oder eines style
-Attributwerts übereinstimmt, wird der Code zur Ausführung zugelassen.
Warnung:
Der Wert 'unsafe-hashes'
ist unsicher.
Insbesondere ermöglicht er einen Angriff, bei dem der Inhalt des Inline-Ereignis-Handler-Attributs als Inline-<script>
-Element in das Dokument injiziert wird. Angenommen, der Inline-Ereignis-Handler ist:
<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 zur Ausführung zulassen.
Allerdings ist 'unsafe-hashes'
viel sicherer als 'unsafe-inline'
.
'inline-speculation-rules'
Standardmäßig, wenn eine CSP eine default-src
- oder script-src
-Richtlinie enthält, darf kein Inline-JavaScript ausgeführt werden. Mit 'inline-speculation-rules'
kann der Browser Inline-<script>
-Elemente laden, die ein type
Attribut von speculationrules
haben.
Weitere Informationen finden Sie in der Speculation Rules API.
'strict-dynamic'
Das Schlüsselwort 'strict-dynamic'
erweitert das Vertrauen, das ein Skript durch eine Nonce oder einen Hash erhält, auf Skripte, die dieses Skript dynamisch lädt, beispielsweise 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 Richtlinie vorhanden ist, werden die folgenden Quell-Ausdruck-Werte alle ignoriert:
Siehe Das Schlüsselwort strict-dynamic
im CSP-Leitfaden für mehr Informationen zur Nutzung.
'report-sample'
Wenn dieser Ausdruck in einer Richtlinie enthalten ist, die Skripte oder Stile steuert, und die Richtlinie den Browser dazu bringt, Inline-Skripte, Inline-Stile oder Ereignis-Handler-Attribute zu blockieren, dann enthält der Verletzungsbericht, den der Browser generiert, eine sample
Eigenschaft mit den ersten 40 Zeichen der blockierten Ressource.
CSP in Workern
Worker unterliegen im Allgemeinen nicht der Content-Sicherheitsrichtlinie des Dokuments (oder Hauptworkerns), das sie erstellt hat. Um eine Content-Sicherheitsrichtlinie für den Worker festzulegen, setzen Sie einen
Content-Security-Policy
Antwort-Header für die Anfrage, die das Workerskript selbst angefordert hat.
Die Ausnahme ist, wenn der Ursprung des Workerskripts ein weltweit eindeutiger Bezeichner ist (zum Beispiel, wenn seine URL ein Schema von Daten oder Blob hat). In diesem Fall erbt der Worker die Content-Sicherheitsrichtlinie des Dokuments oder Workers, das ihn erstellt hat.
Mehrere Content-Sicherheitsrichtlinien
Der CSP-Mechanismus ermöglicht 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 gezeigt. Achten Sie besonders auf die connect-src
-Richtlinie hier. Auch 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, da 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
Unsicheres Inline-Code deaktivieren und nur HTTPS-Ressourcen zulassen
Dieser HTTP-Header setzt die Standardrichtlinie, Ressourcen (Bilder, Schriftarten, Skripte usw.) nur über HTTPS zu laden.
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 bestehenden Website verwendet werden, die zu viel Inline-Code verwendet, um umgearbeitet 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 nicht erzwingen während des Testens
Dieses Beispiel setzt die gleichen Einschrä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 den Code nicht zu blockieren.
Endpunkte (URLs), an die Berichte gesendet werden, werden mit dem Reporting-Endpoints
HTTP-Antwort-Header definiert.
Reporting-Endpoints: csp-endpoint="https://example.com/csp-reports"
Ein bestimmter Endpunkt wird dann als Berichtsziel 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 oben ebenfalls angegeben ist, da report-to
von Browsern noch nicht umfassend 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
Report problems with this compatibility data on GitHubdesktop | mobile | |||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
Content-Security-Policy | ||||||||||||
base-uri | ||||||||||||
block-all-mixed-content | ||||||||||||
child-src | ||||||||||||
connect-src | ||||||||||||
default-src | ||||||||||||
fenced-frame-src | ||||||||||||
font-src | ||||||||||||
form-action | ||||||||||||
Redirects are blocked after a form submission | ||||||||||||
frame-ancestors | ||||||||||||
frame-src | ||||||||||||
img-src | ||||||||||||
manifest-src | ||||||||||||
media-src | ||||||||||||
<meta> element support | ||||||||||||
object-src | ||||||||||||
prefetch-src | ||||||||||||
report-sample source value | ||||||||||||
report-to | ||||||||||||
report-uri | ||||||||||||
require-trusted-types-for | ||||||||||||
sandbox | ||||||||||||
script-src | ||||||||||||
External scripts with hash | ||||||||||||
inline-speculation-rules source expression | ||||||||||||
Source expression allowing WebAssembly execution | ||||||||||||
script-src-attr | ||||||||||||
script-src-elem | ||||||||||||
strict-dynamic source value | ||||||||||||
style-src | ||||||||||||
style-src-attr | ||||||||||||
style-src-elem | ||||||||||||
trusted-types | ||||||||||||
unsafe-hashes source value | ||||||||||||
upgrade-insecure-requests | ||||||||||||
worker-src | ||||||||||||
Worker support |
Legend
Tip: you can click/tap on a cell for more information.
- Full support
- Full support
- Partial support
- Partial support
- No support
- No support
- Experimental. Expect behavior to change in the future.
- Non-standard. Check cross-browser support before using.
- Deprecated. Not for use in new websites.
- See implementation notes.
- User must explicitly enable this feature.
- Uses a non-standard name.
- Has more compatibility info.
Siehe auch
Content-Security-Policy-Report-Only
- Lernen Sie über: Content Security Policy
- Content Security in WebExtensions
- Annahme einer strengen Richtlinie
- CSP Evaluator - Bewerten Sie Ihre Content-Sicherheitsrichtlinie