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

http
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 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 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 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-Ereignis-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-Stile an, die auf individuelle DOM-Elemente angewendet werden.

worker-src

Gibt gültige Quellen für Worker, SharedWorker oder ServiceWorker 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ü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.

Beispielsweise:

  • Wenn img-src ausgelassen, aber default-src eingeschlossen wird, dann wird die Richtlinie von default-src auf Bilder angewendet.
  • Wenn script-src-elem ausgelassen, aber script-src eingeschlossen wird, dann wird die Richtlinie von script-src auf <script>-Elemente angewendet.
  • Wenn script-src-elem und script-src beide ausgelassen werden, aber default-src eingeschlossen ist, dann wird die Richtlinie von default-src auf <script>-Elemente angewendet.

Dokument-Richtlinien

Dokument-Richtlinien regeln die Eigenschaften eines Dokuments oder Worker Umgebung, auf die eine Richtlinie anzuwenden ist.

base-uri

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

sandbox

Ermöglicht eine Sandbox für die angeforderte Ressource, ähnlich dem <iframe> sandbox Attribut.

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 und Report-To Veraltet .

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

Hinweis: Nonce-Quell-Ausdrücke sind nur auf <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 base64-kodierten String, der den Hash-Wert darstellt.

  • Der Hash-Algorithmus-Bezeichner muss einer der folgenden sein: sha256, sha384 oder sha512.
  • 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.

Hinweis: Hash-Quell-Ausdrücke sind nur auf <script>- und <style>-Elemente anwendbar.

<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 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 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 auf alle Pfade, deren Präfix sie sind. Zum Beispiel:

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

Pfade, die nicht mit / enden, werden exakt 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 z. B. https:. Der Doppelpunkt ist erforderlich.

Sichere Upgrades sind erlaubt, daher:

  • http: erlaubt auch Ressourcen, die über HTTPS geladen werden
  • ws: 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 von https://example.com.
  • Wenn das Dokument von ws://example.org bereitgestellt wird, erlaubt ein CSP von 'self' auch Ressourcen von wss://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:

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

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

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

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.

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

Die gleichen Einschränkungen können unter Verwendung 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 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:

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

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

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 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 GitHub
desktopmobile
Chrome
Edge
Firefox
Opera
Safari
Chrome Android
Firefox for Android
Opera Android
Safari on iOS
Samsung Internet
WebView Android
WebView on iOS
Content-Security-Policy
base-uri
block-all-mixed-content
Deprecated
child-src
connect-src
default-src
fenced-frame-src
Experimental
font-src
form-action
Redirects are blocked after a form submission
Non-standard
frame-ancestors
frame-src
img-src
manifest-src
media-src
<meta> element support
object-src
prefetch-src
DeprecatedNon-standard
report-sample source value
report-to
report-uri
Deprecated
require-trusted-types-for
Experimental
sandbox
script-src
External scripts with hash
inline-speculation-rules source expression
Experimental
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
Experimental
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