Content-Security-Policy: script-src Richtlinie

Syntax

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

Diese Richtlinie 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 Quellenausdrücke übereinstimmen. Für diese Richtlinie sind alle Quellenausdrückewerte aus der Fetch-Direktiven-Syntax anwendbar.

Beispiele

Erlauben von Ressourcen von vertrauenswürdigen Domänen

Gegeben ist dieser CSP-Header, der nur Skripte von https://example.com erlaubt:

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

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

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

Beachten Sie, dass auch Inline-Event-Handler blockiert werden:

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

Sie sollten sie durch addEventListener Aufrufe ersetzen:

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

Falls Sie Inline-Event-Handler nicht ersetzen können, können Sie den Quellenausdruck 'unsafe-hashes' verwenden, um sie zu erlauben. Weitere Informationen finden Sie unter Unsichere Hashes.

Erlauben von externen Skripten mit Hashes

Das Erlauben von vertrauenswürdigen Domänen, wie im obigen Abschnitt gezeigt, ist ein pragmatischer Ansatz für die Spezifikation der Standorte, von denen Code sicher geladen werden kann, insbesondere wenn Ihre Site viele Ressourcen verwendet und Sie darauf vertrauen, dass die vertrauenswürdige Site nicht kompromittiert wird.

Eine alternative Methode besteht darin, erlaubte Skripte mit Dateihashes zu spezifizieren. 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 Subresource Integrity-Funktion überprüft zusätzlich, ob die heruntergeladene Datei den angegebenen Hash-Wert hat und daher nicht verändert wurde. Dies ist sicherer als das Vertrauen in eine Domäne, da Dateien nur verwendet werden, wenn sie unverändert sind, selbst wenn sie von einer kompromittierten Site geladen werden. Es ist jedoch granularer und erfordert, dass Hash-Werte in CSP- und Skriptelementen aktualisiert werden, wann immer die zugehörigen Skripte geändert werden.

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

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

Das example-framework.js-Skript unten sollte geladen werden, weil der Hash-Wert in seinem integrity-Attribut auch im CSP vorhanden ist (vorausgesetzt, die Datei hat tatsächlich den Hash, sobald sie heruntergeladen ist!)

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

Das integrity-Attribut kann mehrere Werte enthalten, die jeweils einen Hash für die Datei darstellen, berechnet mit einem anderen Algorithmus. Damit ein externes Skript geladen werden kann, erfordert CSP, dass alle gültigen Hash-Werte im Attribut auch in der CSP script-src-Deklaration vorhanden sein müssen. Daher würde das folgende Skript nicht geladen, da der zweite Hash im obigen CSP-Header nicht vorhanden ist.

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

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

Subresource Integrity enthält weitere Informationen zur Berechnung von Hashes und zur Verwendung des integrity-Attributs.

Unsichere Inline-Skripte

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

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

Das folgende <script>-Element wird durch die Richtlinie erlaubt:

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

Das Erlauben aller Inline-Skripte gilt als Sicherheitsrisiko, daher wird empfohlen, stattdessen eine Nonce-Quelle oder eine Hash-Quelle zu verwenden. Um Inline-Skripte und Styles mit einer Nonce-Quelle zu erlauben, müssen Sie einen zufälligen Nonce-Wert (unter Verwendung eines kryptographisch sicheren Zufallstoken-Generators) generieren und in die Richtlinie aufnehmen. Es ist wichtig zu beachten, dass dieser Nonce-Wert dynamisch generiert werden muss, da er für jede HTTP-Anfrage einzigartig sein muss:

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

Dann müssen Sie den gleichen Nonce in das <script>-Element aufnehmen:

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

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

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

Wenn Sie den Hash generieren, schließen Sie die <script>-Tags nicht ein und beachten Sie, dass Großschreibung und Leerzeichen eine Rolle spielen, einschließlich führender oder nachfolgender Leerzeichen.

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

Unsichere Hashes

Richtlinien für Inline-Ressourcen mit Hashes wie script-src 'sha256-{HASHED_INLINE_SCRIPT}' erlauben Skripte und Styles anhand ihres Hashes, aber nicht Event-Handler:

<!-- 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 Quellenausdruck 'unsafe-hashes' verwenden, wenn der Code nicht zu entsprechenden addEventListener Aufrufen aktualisiert werden kann. Angesichts einer HTML-Seite, die den folgenden Inline-Event-Handler enthält:

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

Der folgende CSP-Header erlaubt die Ausführung des Skripts:

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

Unsichere eval-Ausdrücke

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

• eval()
• Function()

• Wenn Sie eine Zeichenfolgenliterale wie an Methoden übergeben: setTimeout("alert(\"Hello World!\");", 500);

  • setTimeout()
  • setInterval()
  • setImmediate()

• window.execScript() Nicht standardisiert (nur IE < 11)

Unsichere WebAssembly-Ausführung

Der Quellenausdruck 'wasm-unsafe-eval' steuert die WebAssembly-Ausführung. Wenn eine Seite einen CSP-Header hat und 'wasm-unsafe-eval' nicht in der script-src-Richtlinie angegeben ist, wird das Laden und Ausführen von WebAssembly auf der Seite blockiert.

Der Quellenausdruck 'wasm-unsafe-eval' ist spezifischer als 'unsafe-eval', das sowohl die Kompilierung (und Instanzierung) von WebAssembly als auch zum Beispiel die Verwendung des eval-Vorgangs in JavaScript erlaubt. Wenn das Schlüsselwort 'unsafe-eval' verwendet wird, überschreibt dies jedes Vorkommen von 'wasm-unsafe-eval' in der CSP-Richtlinie.

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

strict-dynamic

Der Quellenausdruck 'strict-dynamic' gibt an, dass das einer im Markup vorhandenen Script explizit gegebene Vertrauen, indem es von einem Nonce oder einem Hash begleitet wird, auf alle von diesem Root-Skript geladenen Skripte übertragen werden soll. Gleichzeitig werden alle Erlaubnislisten 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 Root-Skripts mit <script nonce="R4nd0m" src="https://example.com/loader.js"> und die Übertragung dieses Vertrauens auf jedes von loader.js geladene Skript erlauben, aber das Laden von Skripten von https://allowlisted.example.com/ verbieten, es sei denn, sie werden von einem Nonce begleitet oder von einem vertrauenswürdigen Skript geladen.

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

Oder:

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

Es ist möglich, strict-dynamic rückwärtskompatibel zu implementieren, ohne eine Benutzeragenten-Abfrage zu benötigen. Die Richtlinie:

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

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

Zulassen von Spekulationsregeln

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

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

Spezifikationen

Browser-Kompatibilität

Siehe auch

• Content-Security-Policy
• <script>
• script-src-elem
• script-src-attr