Content-Security-Policy: script-src Direktive

Syntax

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 Quellen-Ausdrucks Werten. Ressourcen dieses Typs dürfen geladen werden, wenn sie mit einem der angegebenen Quellenausdrücke übereinstimmen. Für diese Direktive sind alle Quellenausdruckswerte, die in der Fetch-Direktive-Syntax aufgelistet sind, anwendbar.

Beispiele

Allowlisting von Ressourcen aus vertrauenswürdigen Domains

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

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 Inline-Ereignishandler ebenfalls blockiert werden:

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

Sie sollten sie durch addEventListener-Aufrufe ersetzen:

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

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

Allowlisting externer Skripte mit Hashes

Das Erlauben vertrauenswürdiger Domains, wie im obigen Abschnitt gezeigt, ist ein grober 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 Vertrauen darin haben, dass die vertrauenswürdige Website nicht kompromittiert wird.

Eine alternative Methode ist das Spezifizieren erlaubter Skripte durch Datei-Hashes. Bei 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. Das Subresource-Integrity-Feature überprüft zusätzlich, 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 Seite geladen werden. Es ist jedoch auch granularer und erfordert, dass Hash-Werte in CSP- und Skript-Elementen aktualisiert werden, wann immer die zugehörigen Skripte geändert werden.

Der folgende 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 untenstehende example-framework.js-Skript sollte geladen werden, da der Hash-Wert in seinem integrity-Attribut auch in der CSP vorhanden ist (vorausgesetzt, die Datei hat tatsächlich diesen Hash nach dem Herunterladen!).

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

Das integrity-Attribut kann mehrere Werte haben, von denen jeder einen Hash für die Datei liefert, der mit einem anderen Algorithmus berechnet wurde. Um ein externes Skript zu laden, erfordert die 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 werden, da der zweite Hash nicht im oberen CSP-Header 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 Hashwerte 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 mehr Informationen über das Berechnen von Hashes und die Verwendung des integrity-Attributes.

Unsicheres Inline-Skript

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 wird als Sicherheitsrisiko angesehen, 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 generieren (unter Verwendung eines kryptographisch sicheren Zufallstoken-Generators) und ihn 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 denselben Nonce im <script>-Element einfügen:

<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='

Beim Erzeugen des Hashes dürfen Sie die <script>-Tags nicht einbeziehen und beachten Sie, dass Groß- und Kleinschreibung sowie Leerzeichen, einschließlich führender oder nachfolgender Leerzeichen von Bedeutung sind.

<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 durch ihren Hash, aber nicht Ereignishandler:

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

Statt '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-Ereignishandler:

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

Der folgende CSP-Header erlaubt das Skript auszuführen:

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

• eval()
• Function()

• Bei Übergabe einer Zeichenfolgenliteral wie zu Methoden wie: setTimeout("alert(\"Hello World!\");", 500);

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

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

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 spezifiziert ist, wird das Laden und Ausführen von WebAssembly auf der Seite blockiert.

Der 'wasm-unsafe-eval'-Quellenausdruck ist spezifischer als 'unsafe-eval', welches sowohl die Kompilierung (und Instanziierung) von WebAssembly als auch zum Beispiel die Verwendung des eval-Operators in JavaScript erlaubt. Wenn das 'unsafe-eval'-Quellenschlüsselwort verwendet wird, überschreibt es jede Vorkommen von 'wasm-unsafe-eval' in der CSP-Richtlinie.

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

strict-dynamic

Der 'strict-dynamic'-Quellenausdruck gibt an, dass das Vertrauen, das einem Skript im Markup ausdrücklich durch Begleitung mit einem Nonce oder einem Hash gegeben wurde, auf alle Skripte, die von diesem Wurzelskript geladen werden, übertragen werden soll. Gleichzeitig werden alle Allowlisten 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 Skript übertragen, das von loader.js geladen wird, aber das Laden von Skripten von https://allowlisted.example.com/ nur erlauben, wenn es durch ein Nonce begleitet oder von einem vertrauenswürdigen Skript geladen wird.

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 auf abwärtskompatible Weise bereitzustellen, ohne Benutzer-Agenten-Erkennung zu benötigen. Die Richtlinie:

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

wird in Browsern, die CSP1 unterstützen, wie 'unsafe-inline' https: wirken, 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 Skript-Element einzuschließen (siehe auch <script type="speculationrules">), müssen Sie die script-src-Direktive mit einer der 'inline-speculation-rules'-Quellen, eine Hash-Quelle, oder 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