Der HTTPContent-Security-Policy Antwort-Header ermöglicht es Webseitenadministratoren, die Ressourcen zu kontrollieren, die der Benutzeragent für eine gegebene Seite laden darf. Mit einigen Ausnahmen bestehen Richtlinien hauptsächlich darin, Server-Herkünfte und Skript-Endpunkte anzugeben. Dies hilft,Cross-Site-Scripting-Angriffe zu verhindern.

Sehen Sie sich denContent Security Policy (CSP) Leitfaden für Details dazu an, wie eine CSP an den Browser übermittelt wird, wie sie aussieht, sowie Anwendungsfälle und Einsatzstrategien.

Syntax

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

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

Richtlinien

Fetch-Richtlinien

Fetch-Richtlinien steuern, von welchen Standorten bestimmte Ressourcentypen geladen werden dürfen.

child-src

Definiert die gültigen Quellen fürWeb Worker und verschachtelte Browsing-Kontexte, die mit Elementen wie<frame> und<iframe> geladen werden.

Fallback fürframe-src undworker-src.

connect-src

Beschränkt die URLs, die über Skriptschnittstellen geladen werden können.

default-src

Dient als Fallback für die anderenFetch-Richtlinien.

Fallback für alle anderen Fetch-Richtlinien.

fenced-frame-srcExperimentell

Gibt gültige Quellen für verschachtelte Browsing-Kontexte an, die in<fencedframe>-Elementen 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 Elementen 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 über die<audio>,<video> und<track>-Elemente an.

object-src

Gibt gültige Quellen für die<object> und<embed>-Elemente an.

prefetch-srcVeraltetNicht standardisiert

Gibt gültige Quellen an, die vorgeladen oder vorgerendert werden sollen.

script-src

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

Fallback fürscript-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ürstyle-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-Styles an, die auf individuelle DOM-Elemente angewendet werden.

worker-src

Gibt gültige Quellen fürWorker,SharedWorker oderServiceWorker Skripte an.

Alle Fetch-Richtlinien können den Einzelwert'none' haben, was anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden soll, oder als eine oder mehrereSource-Expressions-Werte, die gültige Quellen für diesen Ressourcentyp angeben. SieheFetch-Richtlinien-Syntax für mehr Details.

Fallbacks

Einige Fetch-Richtlinien fungieren als Fallbacks für andere, spezifischere Richtlinien. Das bedeutet, dass, wenn die spezifischere 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.

Zum Beispiel:

• Wennimg-src weggelassen wird, aberdefault-src enthalten ist, wird die vondefault-src definierte Richtlinie auf Bilder angewandt.
• Wennscript-src-elem weggelassen wird, aberscript-src enthalten ist, wird die vonscript-src definierte Richtlinie auf<script>-Elemente angewandt.
• Wennscript-src-elem undscript-src beide weggelassen werden, aberdefault-src enthalten ist, wird die vondefault-src definierte Richtlinie auf<script>-Elemente angewandt.

Dokument-Richtlinien

Dokument-Richtlinien regeln die Eigenschaften eines Dokuments oderWorker-Umgebung, auf die eine Richtlinieangewendet wird.

base-uri

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

sandbox

Aktiviert einen Sandbox-Modus für die angeforderte Ressource, ähnlich dem<iframe>sandbox-Attribut.

Navigations-Richtlinien

Navigations-Richtlinien steuern, zu welchen Standorten ein Benutzer navigieren oder ein Formular übermitteln kann.

form-action

Beschränkt die URLs, die als Ziel von Formularübermittlungen aus einemgegebenen Kontext verwendet werden können.

frame-ancestors

Gibt gültige Eltern an, die eine Seite mit<frame>,<iframe>,<object> oder<embed> einbetten dürfen.

Report-Richtlinien

Report-Richtlinien steuern die Ziel-URL für CSP-Verletzungsberichte inContent-Security-Policy undContent-Security-Policy-Report-Only.

report-to

Stellt dem Browser ein Token bereit, das den Berichtendpunkt oder eine Gruppe von Endpunkten identifiziert, an die CSP-Verletzungsinformationen gesendet werden.Die Endpunkte, die das Token repräsentiert, werden über andere HTTP-Header bereitgestellt, wieReporting-Endpoints undReport-ToVeraltet.

Warnung:Diese Richtlinie ist dazu gedacht,report-uri zu ersetzen. In Browsern, diereport-to unterstützen, wird diereport-uri-Richtlinie ignoriert.Dareport-to jedoch noch nicht umfassend unterstützt wird, sollten Sie beide Header festlegen, wie gezeigt (wobeiendpoint_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

ErzwingtTrusted Types bei den DOM-XSS-Injection-Senken.

trusted-types

Wird verwendet, um eine Positivliste vonTrusted Types-Richtlinien anzugeben.Trusted Types ermöglicht Anwendungen, DOM-XSS-Injection-Senken 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 Website (jene, die über HTTP bereitgestellt werden) so zu behandeln, als wären sie durch sichere URLs (jene, die über HTTPS bereitgestellt werden) ersetzt worden.Diese Richtlinie ist für Websites mit einer großen Anzahl unsicherer, veralteter URLs gedacht, die umgeschrieben werden müssen.

Veraltete Richtlinien

block-all-mixed-contentVeraltet

Verhindert das Laden von jeglichen Assets über HTTP, wenn die Seite über HTTPS geladen wird.

report-uriVeraltet

Bietet dem Browser eine URL, an die CSP-Verletzungsberichte gesendet werden sollen.Diese wurde durch diereport-to-Richtlinie ersetzt.

Fetch-Richtlinien-Syntax

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

• der Einzelwert'none', der anzeigt, dass der spezifische Ressourcentyp vollständig blockiert werden soll
• ein oder mehrereSource-Expressions-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-Richtlinien anwendbar sind: Sehen Sie die Dokumentation für jede Fetch-Richtlinie, um herauszufinden, welche Formen für sie anwendbar sind.

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

'nonce-<nonce_value>'

Dieser Wert besteht aus dem Stringnonce- gefolgt von einem Nonce-Wert. Der Nonce-Wert kann alle Zeichen vonBase64 oderURL-sicherem Base64 verwenden.

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 desnonce-Attributs von jeglichen<script>- oder<style>-Ressourcen aufnehmen, die sie aus dem 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 undunsafe-inline enthält, ignoriert der Browserunsafe-inline.

SieheNonces im CSP-Leitfaden für mehr Nutzungshinweise.

'<hash_algorithm>-<hash_value>'

Dieser Wert besteht aus einem String, der einen Hash-Algorithmus identifiziert, gefolgt von- und einem Hash-Wert. Der Hash-Wert kann alle Zeichen vonBase64 oderURL-sicherem Base64 verwenden.

• Der Hash-Algorithmus-Identifikator muss einer der folgenden sein:sha256,sha384 odersha512.
• Der Hash-Wert ist der base64-kodierteHash einer<script> oder<style>-Ressource, berechnet unter Verwendung 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 von<script> und<style>-Elementen, vergleicht das Ergebnis mit den Hashes in der CSP-Richtlinie und lädt die Ressource nur, wenn eine Übereinstimmung vorliegt.

Wenn das Element eine externe Ressource lädt (zum Beispiel unter Verwendung dessrc-Attributs), muss das Element auch dasintegrity-Attribut gesetzt haben.

Wenn eine Richtlinie einen Hash undunsafe-inline enthält, ignoriert der Browserunsafe-inline.

SieheHashes im CSP-Leitfaden für mehr Nutzungshinweise.

<host-source>

DieURL oder IP-Adresse einesHosts, 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 der Ursprungsadresse des Dokuments verwendet.

Beim Schema-Abgleich sind sichere Upgrades erlaubt. Zum Beispiel:

• http://example.com wird auch Ressourcen vonhttps://example.com erlauben
• ws://example.org wird auch Ressourcen vonwss://example.org erlauben.

Wildcards ('*') können für Subdomains, Hostadressen und Portnummern verwendet werden, was bedeutet, dass alle legalen Werte jedes davon 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, dessen Präfix sie sind. Zum Beispiel:

• example.com/api/ wird Ressourcen vonexample.com/api/users/new erlauben.

Pfade, die nicht mit/ enden, stimmen genau überein. Zum Beispiel:

• https://example.com/file.js erlaubt Ressourcen vonhttps://example.com/file.js, aber nicht vonhttps://example.com/file.js/file2.js.

<scheme-source>

EinSchema, wiehttps:. Der Doppelpunkt ist erforderlich.

Sichere Upgrades sind erlaubt, sodass:

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

'self'

Ressourcen des angegebenen Typs dürfen nur von derselbenUrsprung wie das Dokument geladen werden.

Sichere Upgrades sind erlaubt. Zum Beispiel:

• Wenn das Dokument vonhttp://example.com bereitgestellt wird, erlaubt ein CSP von'self' auch Ressourcen vonhttps://example.com.
• Wenn das Dokument vonws://example.org bereitgestellt wird, erlaubt ein CSP von'self' auch Ressourcen vonwss://example.org.

'trusted-types-eval'

Standardmäßig sind, wenn ein CSP einedefault-src- oder einescript-src-Richtlinie enthält, JavaScript-Funktionen, die ihre Argumente als JavaScript auswerten, deaktiviert. Dazu gehöreneval(), dascode-Argument vonsetTimeout(), oder derFunction()-Konstruktor.

Dastrusted-types-eval-Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben, jedoch nur, wennTrusted Types durchgesetzt und anstelle von Strings an diese Funktionen übergeben werden.Dies ermöglicht die dynamische Auswertung von Strings als JavaScript, jedoch nur, nachdem Eingaben durch eine Transformationsfunktion geleitet wurden, bevor sie eingefügt werden, was die Möglichkeit bietet, die Eingabe zusanitieren, um potenziell gefährliche Markups zu entfernen.

Dastrusted-types-eval muss anstelle von'unsafe-eval' verwendet werden, wenn diese Methoden mit vertrauenswürdigen Typen verwendet werden.Dies stellt sicher, dass der Zugriff auf die Methoden in Browsern, die keine vertrauenswürdigen Typen unterstützen, blockiert wird.

Sieheeval() und ähnliche APIs im CSP-Leitfaden für mehr Nutzungshinweise.

'unsafe-eval'

Standardmäßig sind, wenn ein CSP einedefault-src- oder einescript-src-Richtlinie enthält, JavaScript-Funktionen, die ihre Argumente als JavaScript auswerten, deaktiviert. Dazu gehöreneval(), dascode-Argument vonsetTimeout(), oder derFunction()-Konstruktor.

Dasunsafe-eval-Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben und die dynamische Auswertung von Strings als JavaScript zu ermöglichen.

Sieheeval() und ähnliche APIs im CSP-Leitfaden für mehr Nutzungshinweise.

'wasm-unsafe-eval'

Standardmäßig ist, wenn ein CSP einedefault-src- oder einescript-src-Richtlinie enthält, eine Seite nicht berechtigt, WebAssembly zu kompilieren, indem Funktionen wieWebAssembly.compileStreaming() verwendet werden.

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

'unsafe-inline'

Standardmäßig ist, wenn ein CSP einedefault-src- oder einescript-src-Richtlinie enthält, Inline-JavaScript nicht zur Ausführung zugelassen. Dies schließt ein:

• Inline-<script>-Tags
• Inline-Event-Handler-Attribute
• #"/de/docs/Web/API/HTMLElement/style">style-Attribute.

Dasunsafe-inline-Schlüsselwort kann verwendet werden, um diesen Schutz aufzuheben und all diese Formen zu laden.

SieheInline JavaScript im CSP-Leitfaden für mehr Nutzungshinweise.

'unsafe-hashes'

Standardmäßig sind, wenn ein CSP einedefault-src- oder einescript-src-Richtlinie enthält, Inline-Event-Handler-Attribute wieonclick und Inline-style-Attribute nicht zur Ausführung zugelassen.

Die'unsafe-hashes'-Expression erlaubt dem Browser,Hash-Expressions für Inline-Event-Handler undstyle-Attribute zu verwenden. Zum Beispiel könnte ein CSP eine Richtlinie wie diese enthalten:

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

Wenn der Hashwert mit dem Hash eines Inline-Event-Handler-Attributwertes oder einesstyle-Attributwertes übereinstimmt, wird der Code zur Ausführung zugelassen.

<button>Transfer all my money</button>

'inline-speculation-rules'

Standardmäßig ist, wenn ein CSP einedefault-src- oder einescript-src-Richtlinie enthält, Inline-JavaScript nicht zur Ausführung zugelassen. Die'inline-speculation-rules'-Richtlinie erlaubt es dem Browser, Inline-<script>-Elemente zu laden, die eintype-Attribut vom Typspeculationrules haben.

Siehe dieSpeculation Rules API für weitere Informationen.

'strict-dynamic'

Das'strict-dynamic'-Schlüsselwort erweitert das durch einenNonce oder einenHash verliehene Vertrauen auf Skripte, die dieses Skript dynamisch lädt, z. B. durch Erstellen neuer<script>-Tags mitDocument.createElement() und anschließendes Einfügen in das Dokument mitNode.appendChild().

Wenn dieses Schlüsselwort in einer Richtlinie vorhanden ist, werden die folgenden Source-Expressions-Werte alle ignoriert:

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

SieheDasstrict-dynamic-Schlüsselwort im CSP-Leitfaden für mehr Nutzungshinweise.

'report-sample'

Wenn dieser Ausdruck in einer Richtlinie enthalten ist, die Skripte oder Stylesheets kontrolliert und die Richtlinie den Browser veranlasst, Inline-Skripte, Inline-Styles oder Event-Handler-Attribute zu blockieren, wird derVerletzungsbericht, den der Browser generiert, einesample-Eigenschaft enthalten, die die ersten 40 Zeichen der blockierten Ressource enthält.

CSP in Workern

Worker werden im Allgemeinennicht durch die Content-Security-Policy des Dokuments regiert (oder des übergeordneten Workers), das sie erstellt hat. Um eine Content-Security-Policy für den Worker festzulegen, setzen Sie einenContent-Security-Policy-Antwort-Header für die Anforderung, die dasWorker-Skript selbst angefordert hat.

Die Ausnahme ist, wenn die Ursprungsadresse des Worker-Skripts ein global eindeutiger Bezeichner ist(z. B. wenn die URL ein Schema von data oder blob hat). In diesem Fall übernimmt der Worker die Content-Security-Policy des Dokuments oder Workers, das ihn erstellt hat.

Mehrere Content-Security-Policies

Der CSP-Mechanismus erlaubt es, dass mehrere Richtlinien für eine Ressource angegeben werden können, einschließlichüber denContent-Security-Policy-Header, denContent-Security-Policy-Report-Only-Header und ein<meta>-Element.

Sie können denContent-Security-Policy-Header mehrmals verwenden, wie imBeispiel unten gezeigt. Achten Sie besonders auf dieconnect-src-Richtlinie hier. Auch wenn die zweite Richtlinie die Verbindung zulassen würde, enthält die erste Richtlinieconnect-src 'none'. Das Hinzufügen zusätzlicher Richtlinienkann nur weitereinschränken , die Fähigkeiten der geschützten Ressource, was bedeutet, dass keine Verbindung erlaubt wird und als die strengste Richtlinieconnect-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, Schriften, Skripte usw.) nur über HTTPS zu erlauben.Da dieunsafe-inline undunsafe-eval-Richtlinien nicht gesetzt sind, werden Inline-Skripte blockiert.

Content-Security-Policy: default-src https:

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

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

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

Diese Richtlinie könnte auf einer bestehenden Website verwendet werden, die zu viel Inline-Code verwendet, um ihn zu beheben, um sicherzustellen, dass Ressourcen nur über HTTPS geladen werden, und um Plugins zu deaktivieren:

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 dieselben Beschränkungen wie das vorherige Beispiel, verwendet jedoch denContent-Security-Policy-Report-Only-Header und diereport-to-Richtlinie.Diese Methode wird während des Testens verwendet, um Verstöße zu melden, ohne den Code daran zu hindern, ausgeführt zu werden.

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

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

Ein bestimmter Endpunkt wird dann als Ziel für Berichte in der CSP-Richtlinie unter Verwendung derreport-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 diereport-uriVeraltet-Richtlinie ebenfalls oben angegeben ist, dareport-to noch nicht umfassend von Browsern unterstützt wird.

SieheContent Security Policy (CSP)-Implementierung für weitere Beispiele.

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Content-Security-Policy-Report-Only
• Erfahren Sie mehr über: Content Security Policy
• Content Security in WebExtensions
• Einführung einer strikten Richtlinie
• CSP Evaluator - Bewertung IhrerContent-Security-Policy