CSP: script-src

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 übereinstimmen. Für diese Direktive sind alle Quellenwerte, die in der Fetch-Direktive Syntax aufgeführt sind, anwendbar.

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

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

Sie sollten sie durch Aufrufe von addEventListener ersetzen:

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

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

Das Zulassen vertrauenswürdiger Domains, wie im obigen Abschnitt gezeigt, ist ein grober Ansatz, um die Orte festzulegen, 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 Website nicht kompromittiert wird.

Eine alternative Methode besteht darin, erlaubte Skripte mit Dateihashes anzugeben. Bei diesem Ansatz kann eine externe Datei in einem <script>-Element nur geladen und ausgeführt werden, wenn alle gültigen Hashwerte in ihrem integrity-Attribut den erlaubten Werten im CSP-Header entsprechen. Das Subresource Integrity-Feature überprüft zusätzlich, dass die heruntergeladene Datei den angegebenen Hashwert hat und somit 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 granularer und erfordert, dass die Hashwerte in CSP- und Script-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 fiktiver_wert ist.

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

Das example-framework.js Skript unten sollte geladen werden, weil der Hashwert in seinem integrity-Attribut auch im CSP vorhanden ist (vorausgesetzt, die Datei hat tatsächlich diesen 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 haben, die jeweils einen Hash für die Datei berechnen, wobei unterschiedliche Algorithmen verwendet werden. Um ein externes Skript zu laden, erfordert CSP, dass alle gültigen Hash-Werte im Attribut auch in der script-src Deklaration des CSP enthalten sein müssen. Daher würde das untenstehende 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 zum Berechnen von Hashes und zur Verwendung des integrity-Attributs.

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

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

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

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

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

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

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

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

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

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

Beim Generieren des Hashs sollten Sie die <script>-Tags nicht einschließen und beachten, dass Groß-/Kleinschreibung und Leerzeichen, einschließlich führender oder nachfolgender Leerzeichen, wichtig sind.

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

Richtlinien für Inline-Ressourcen mit Hashes wie script-src 'sha256-{HASHED_INLINE_SCRIPT}' erlauben Skripte und Stile durch ihren Hash, jedoch 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>

Anstatt 'unsafe-inline' zu erlauben, können Sie den 'unsafe-hashes' Quellenwert verwenden, wenn der Code nicht zu äquivalenten addEventListener-Aufrufen aktualisiert werden kann. Gegeben eine HTML-Seite, die den folgenden Inline-Ereignishandler 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}'

Der 'unsafe-eval' Quellenwert 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()

• Beim Übergeben eines Zeichenfolgenwerts wie bei Methoden wie: setTimeout("alert(\"Hello World!\");", 500);

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

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

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

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

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

Der 'strict-dynamic' Quellenwert gibt an, dass das Vertrauen, das einem im Markup vorhandenen Skript durch die Begleitung mit einem Nicht oder einem Hash explizit gegeben wird, auf alle durch dieses Wurzelskript geladenen Skripte weitergeleitet werden soll. Gleichzeitig werden jede Positivliste oder Quellenwerte wie 'self' oder 'unsafe-inline' ignoriert.

Beispielsweise 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 durch loader.js geladene Skript übertragen, jedoch das Laden von Skripten von https://allowlisted.example.com/ verbieten, es sei denn, sie werden von einem Nicht 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 in einer rückwärtskompatiblen Weise einzusetzen, ohne dass User-Agent-Erkennung erforderlich ist. Die Richtlinie:

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

wird sich verhalten 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.

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, einer Hash-Quelle oder einer Nicht-Quelle verwenden. Zum Beispiel:

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

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