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: script-src Direktive

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.

Die HTTP Content-Security-Policy (CSP) script-src Direktive gibt gültige Quellen für JavaScript an. Dies umfasst nicht nur URLs, die direkt in <script>-Elemente geladen werden, sondern auch Dinge wie Inline-Skriptereignis-Handler (onclick) und XSLT-Stile, die Skriptausführung auslösen können.

CSP-Version 1
Direktivtyp Fetch-Direktive
default-src Rückfall Ja. Wenn diese Direktive fehlt, sucht der Benutzeragent nach der default-src Direktive.

Syntax

http
Content-Security-Policy: script-src 'none';
Content-Security-Policy: script-src <source-expression-list>;

Diese Direktive kann einen der folgenden Werte haben:

'none'

Keine Ressourcen dieses Typs dürfen geladen werden. Die einfachen Anführungszeichen sind obligatorisch.

<source-expression-list>

Eine durch Leerzeichen getrennte Liste von source expression Werten. Ressourcen dieses Typs dürfen geladen werden, wenn sie mit einem der angegebenen Quellen-Ausdrücke übereinstimmen. Für diese Direktive sind alle in der Fetch-Direktive-Syntax aufgeführten Quellen-Ausdrücke anwendbar.

Beispiele

Ressourcen von vertrauenswürdigen Domains auf die Whitelist setzen

Angenommen, dieser CSP-Header erlaubt nur Skripte von https://example.com:

http
Content-Security-Policy: script-src https://example.com/

wird das folgende Skript blockiert und nicht geladen oder ausgeführt:

html
<script src="https://not-example.com/js/library.js"></script>

Beachten Sie, dass auch Inline-Ereignis-Handler blockiert sind:

html
<button id="btn" onclick="doSomething()">Click me</button>

Sie sollten diese durch addEventListener-Aufrufe ersetzen:

js
document.getElementById("btn").addEventListener("click", doSomething);

Wenn Sie Inline-Ereignis-Handler nicht ersetzen können, können Sie den 'unsafe-hashes'-Quellenausdruck verwenden, um sie zuzulassen. Siehe Unsichere Hashes für weitere Informationen.

Externe Skripte mit Hashes auf die Whitelist setzen

Das Zulassen vertrauenswürdiger Domains, wie im obigen Abschnitt gezeigt, ist ein breit gefasster Ansatz, um die Orte zu spezifizieren, von denen Code sicher geladen werden kann. Dies ist ein pragmatischer Ansatz, insbesondere wenn Ihre Website viele Ressourcen verwendet und Sie zuversichtlich sind, dass die vertrauenswürdige Site nicht kompromittiert wird.

Eine alternative Methode besteht darin, erlaubte Skripte mithilfe von Datei-Hashes anzugeben. Mit diesem Ansatz kann eine externe Datei in einem <script>-Element nur geladen und ausgeführt werden, wenn alle gültigen Hash-Werte in ihrem integrity-Attribut mit den erlaubten Werten im CSP-Header übereinstimmen. Die Subressourcen-Integrität überprüft zudem, dass die heruntergeladene Datei den angegebenen Hash-Wert hat und daher nicht verändert wurde. Dies ist sicherer als das Vertrauen in eine Domain, da Dateien nur verwendet werden, wenn sie unverändert sind, selbst wenn sie von einer kompromittierten Website geladen werden. Es ist jedoch detaillierter und erfordert, dass Hash-Werte in CSP und Skriptelementen aktualisiert werden, wann immer die zugehörigen Skripte geändert werden.

Der CSP-Header unten zeigt den Ansatz. Er erlaubt Skripte, für die der SHA384-Hash oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC oder der SHA256-Hash fictional_value ist.

http
Content-Security-Policy: script-src 'sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC' 'sha256-fictional_value'

Das nachstehende example-framework.js-Skript sollte geladen werden, da der Hash-Wert in seinem integrity-Attribut auch im CSP vorhanden ist (vorausgesetzt, die Datei hat diesen Hash tatsächlich nach dem Herunterladen!)

html
<script
  src="https://example.com/example-framework.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

Das integrity-Attribut kann mehrere Werte haben, wobei jeder einen Hash für die Datei angibt, die mit einem anderen Algorithmus berechnet wurde. Damit ein externes Skript geladen wird, erfordert CSP, dass alle gültigen Hash-Werte im Attribut auch in der CSP script-src-Deklaration vorhanden sein müssen. Deshalb würde das untenstehende Skript nicht geladen, da der zweite Hash nicht im obenstehenden CSP-Header vorhanden ist.

html
<script
  src="https://example.com/example-framework.js"
  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC sha256-not-in-csp"
  crossorigin="anonymous"></script>

Diese Regel gilt nur für gültige Hash-Werte. Werte, die vom Browser nicht als Hashes erkannt werden, werden ignoriert, sodass das folgende Skript geladen werden sollte:

html
<script
  src="https://example.com/example-framework.js"
  integrity="invalid-or-unsupported-hash sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
  crossorigin="anonymous"></script>

Subressourcen-Integrität enthält weitere Informationen zur Berechnung von Hashes und zur Verwendung des integrity-Attributs.

Unsicheres Inline-Skript

Hinweis: Das Verbieten von Inline-Stilen und Inline-Skripten ist einer der größten Sicherheitsgewinne, die CSP bietet. Wenn Sie sie unbedingt verwenden müssen, gibt es einige Mechanismen, die sie erlauben. Hashes gelten für Inline-Skripte und Stile, aber nicht für Ereignis-Handler. Weitere Informationen finden Sie unter Unsichere Hashes.

Um Inline-Skripte und Stile zu erlauben, kann 'unsafe-inline', eine Nonce-Quelle oder eine Hash-Quelle, die mit dem Inline-Block übereinstimmt, angegeben werden. Die folgende Content-Security-Policy erlaubt alle Inline-<script>-Elemente:

http
Content-Security-Policy: script-src 'unsafe-inline';

Das folgende <script>-Element wird von der Richtlinie erlaubt:

html
<script>
  const inline = 1;
  // …
</script>

Das Zulassen aller Inline-Skripte wird als Sicherheitsrisiko angesehen, daher wird empfohlen, stattdessen eine Nonce-Quelle oder eine Hash-Quelle zu verwenden. Um Inline-Skripte und Stile mit einer Nonce-Quelle zu erlauben, müssen Sie einen zufälligen Nonce-Wert (mithilfe eines kryptografisch sicheren Zufallstoken-Generators) generieren und ihn in der Richtlinie einfügen. Es ist wichtig zu beachten, dass dieser Nonce-Wert dynamisch generiert werden muss, da er für jede HTTP-Anfrage einzigartig sein muss:

http
Content-Security-Policy: script-src 'nonce-2726c7f26c'

Dann müssen Sie denselben Nonce im <script>-Element einfügen:

html
<script nonce="2726c7f26c">
  const inline = 1;
  // …
</script>

Alternativ können Sie Hashes aus Ihren Inline-Skripten erstellen. CSP unterstützt sha256, sha384 und sha512.

http
Content-Security-Policy: script-src 'sha256-B2yPHKaXnvFWtRChIbabYmUBFZdVfKKXHbWtWidDVF8='

Beim Generieren des Hashs sollten die <script>-Tags nicht eingeschlossen werden, und es ist zu beachten, dass Groß- und Kleinschreibung sowie Leerzeichen wichtig sind, einschließlich führender oder nachgestellter Leerzeichen.

html
<script>
  const inline = 1;
</script>

Unsichere Hashes

Richtlinien für Inline-Ressourcen mit Hashes wie script-src 'sha256-{HASHED_INLINE_SCRIPT}' erlauben Skripte und Stile anhand ihres Hashs, jedoch keine Ereignis-Handler:

html
<!-- Allowed by CSP: script-src 'sha256-{HASHED_INLINE_SCRIPT}' -->
<script>
  const inline = 1;
</script>

<!-- CSP: script-src 'sha256-{HASHED_EVENT_HANDLER}'
      will not allow this event handler -->
<button onclick="myScript()">Submit</button>

Anstatt 'unsafe-inline' zu erlauben, können Sie den 'unsafe-hashes'-Quellenausdruck verwenden, wenn der Code nicht auf gleichwertige addEventListener-Aufrufe aktualisiert werden kann. Angenommen, eine HTML-Seite enthält den folgenden Inline-Ereignis-Handler:

html
<!-- I want to use addEventListener, but I can't :( -->
<button onclick="myScript()">Submit</button>

Der folgende CSP-Header lässt das Skript ausführen:

http
Content-Security-Policy:  script-src 'unsafe-hashes' 'sha256-{HASHED_EVENT_HANDLER}'

Unsichere eval-Ausdrücke

Der 'unsafe-eval'-Quellenausdruck steuert mehrere Skriptausführungsmethoden, die Code aus Strings erstellen. Wenn eine Seite einen CSP-Header hat und 'unsafe-eval' nicht mit der script-src Direktive angegeben ist, werden die folgenden Methoden blockiert und haben keine Wirkung:

Unsichere WebAssembly-Ausführung

Der 'wasm-unsafe-eval'-Quellenausdruck steuert die Ausführung von WebAssembly. Wenn eine Seite einen CSP-Header hat und 'wasm-unsafe-eval' nicht in der script-src Direktive angegeben ist, wird WebAssembly daran gehindert, auf der Seite geladen und ausgeführt zu werden.

Der 'wasm-unsafe-eval' Quellenausdruck ist spezifischer als 'unsafe-eval', der sowohl die Kompilierung (und Instanziierung) von WebAssembly als auch die Nutzung der eval-Operation in JavaScript erlaubt. Wenn das 'unsafe-eval' Quellenschlüsselwort verwendet wird, überschreibt dies das Vorkommen von 'wasm-unsafe-eval' in der CSP-Richtlinie.

http
Content-Security-Policy: script-src 'wasm-unsafe-eval'

strict-dynamic

Der 'strict-dynamic' Quellenausdruck gibt an, dass das Vertrauen, das explizit einem im Markup vorhandenen Skript gegeben wird, indem es mit einer Nonce oder einem Hash ausgestattet wird, auf alle von diesem Wurzelskript geladenen Skripte übertragen werden soll. Gleichzeitig werden jede Positivliste oder Quellenausdrücke wie 'self' oder 'unsafe-inline' ignoriert.

Zum Beispiel würde eine Richtlinie wie script-src 'strict-dynamic' 'nonce-R4nd0m' https://allowlisted.example.com/ das Laden eines Wurzelskripts mit <script nonce="R4nd0m" src="https://example.com/loader.js"> erlauben und dieses Vertrauen auf jedes von loader.js geladene Skript übertragen, aber das Laden von Skripten von https://allowlisted.example.com/ nicht erlauben, es sei denn, sie werden von einer vertrauenswürdigen Quelle geladen oder von einem Wurzelskript geladen, das mit einer Nonce ausgestattet ist.

http
Content-Security-Policy: script-src 'strict-dynamic' 'nonce-someNonce'

Oder:

http
Content-Security-Policy: script-src 'strict-dynamic' 'sha256-base64EncodedHash'

Es ist möglich, strict-dynamic auf eine rückwärtskompatible Weise bereitzustellen, ohne Benutzeragenten-Abfragen zu erfordern. Die Richtlinie:

http
Content-Security-Policy: script-src 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic'

wird in Browsern, die CSP1 unterstützen, wie 'unsafe-inline' https:, in Browsern, die CSP2 unterstützen, wie https: 'nonce-abcdefg', und in Browsern, die CSP3 unterstützen, wie 'nonce-abcdefg' 'strict-dynamic'.

Spekulationsregeln erlauben

Um Spekulationsregeln in einem Skriptelement einzuschließen (siehe auch <script type="speculationrules">), müssen Sie die script-src Direktive mit einer der 'inline-speculation-rules' Quellen, einer Hash-Quelle oder einer Nonce-Quelle verwenden. Zum Beispiel:

http
Content-Security-Policy: script-src 'inline-speculation-rules'

Spezifikationen

Specification
Content Security Policy Level 3
# directive-script-src

Browser-Kompatibilität

Siehe auch