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 Quellausdrücke übereinstimmen. Für diese Direktive sind alle in der Fetch-Direktive-Syntax aufgeführten Quellausdrücke 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 addEventListener-Aufrufe ersetzen:

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

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

Das Zulassen von vertrauenswürdigen Domains, wie im obigen Abschnitt gezeigt, ist ein pragmatischer Ansatz, um die sicheren Ladeorte von Code zu spezifizieren. Dies ist insbesondere dann sinnvoll, wenn Ihre Seite viele Ressourcen nutzt und Sie Vertrauen haben, dass die vertrauenswürdige Seite nicht kompromittiert wird.

Eine alternative Methode besteht darin, zulässige 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 Hash-Werte in ihrem integrity-Attribut mit den im CSP-Header erlaubten Werten übereinstimmen. Die Subresource-Integrität-Funktion stellt zusätzlich sicher, dass die heruntergeladene Datei den angegebenen Hash-Wert hat und daher nicht modifiziert wurde. Dies ist sicherer, als einer Domain zu vertrauen, da Dateien nur verwendet werden, wenn sie nicht verändert sind, selbst wenn sie von einer kompromittierten Seite geladen werden. Es ist jedoch granulärer und erfordert, dass Hash-Werte in CSP und Skriptelementen aktualisiert werden, wenn die zugehörigen Skripte geändert werden.

Der folgende CSP-Header demonstriert diesen Ansatz. Es 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, da der Hash-Wert in seinem integrity-Attribut auch im CSP vorhanden ist (sofern die Datei tatsächlich diesen Hash hat, 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 bereitstellen, der 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 enthalten sein müssen. Daher würde das Skript unten nicht geladen, da der zweite Hash nicht im obigen 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 nicht als Hashes vom Browser 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-Integrität 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 Nonce-Quelle oder eine Hash-Quelle, die mit dem Inline-Block übereinstimmt, angegeben 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 Zulassen aller Inline-Skripte wird als Sicherheitsrisiko betrachtet, 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 generieren (unter Verwendung eines kryptografisch sicheren Zufalls-Tokengenerators) 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 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ß-/Kleinschreibung und Leerzeichen wichtig sind, einschließlich führender oder nachfolgender Leerzeichen.

<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' Quellausdruck 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, dass das Skript ausgeführt wird:

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

Der 'unsafe-eval' Quellausdruck 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 spezifiziert ist, werden die folgenden Methoden blockiert und haben keine Wirkung:

• eval()
• Function()

• Beim Übergeben eines String-Literals an Methoden wie: setTimeout("alert(\"Hallo Welt!\");", 500);

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

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

Der 'wasm-unsafe-eval' Quellausdruck 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 WebAssembly daran gehindert, auf der Seite geladen und ausgeführt zu werden.

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

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

Der 'strict-dynamic' Quellausdruck gibt an, dass das Vertrauen, das explizit einem Skript im Markup gegeben wird, indem es mit einer Nonce oder einem Hash versehen wird, auf alle Skripte übertragen wird, die von diesem Wurzelskript geladen werden. Gleichzeitig werden alle Whitelists oder Quellausdrücke 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 Skript übertragen, das von loader.js geladen wird, aber das Laden von Skripten von https://allowlisted.example.com/ verweigern, es sei denn, sie sind mit einer Nonce versehen oder stammen aus einem vertrauenswürdigen Skript.

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 abwärtskompatiblen Weise einzuführen, ohne Benutzeragenten-Sniffing zu erfordern. 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 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:

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

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