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'

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

<source-expression-list>

Eine durch Leerzeichen getrennte Liste von Quellausdrücken. Ressourcen dieses Typs dürfen geladen werden, wenn sie einem der angegebenen Quellausdrücke entsprechen. Für diese Direktive sind alle in der Fetch directive 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/

wird das folgende Skript 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 diese durch addEventListener-Aufrufe ersetzen:

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

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

Das Erlauben vertrauenswürdiger Domains, wie im obigen Abschnitt gezeigt, ist ein allgemeiner Ansatz, um die Orte zu spezifizieren, von denen Code sicher geladen werden kann. Dies ist ein pragmatischer Ansatz, insbesondere wenn Ihre Site viele Ressourcen verwendet und Sie Vertrauen darauf haben, dass die vertrauenswürdige Site nicht kompromittiert wird.

Eine alternative Methode ist das Spezifizieren erlaubter Skripte unter Verwendung von Dateihashes. 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. Das Feature Subresource-Integrität überprüft zusätzlich, dass die heruntergeladene Datei den angegebenen Hash-Wert hat und daher nicht modifiziert wurde. Dies ist sicherer als das Vertrauen einer Domain, da Dateien nur verwendet werden, wenn sie nicht modifiziert wurden, auch wenn sie von einer kompromittierten Site geladen werden. Es ist jedoch granularer und erfordert, dass Hash-Werte im CSP und in den Skript-Elementen aktualisiert werden, wann immer die zugehörigen Skripte geändert werden.

Der folgende CSP-Header demonstriert diesen 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, da der Hash-Wert in seinem integrity-Attribut auch im CSP vorhanden ist (vorausgesetzt, die Datei hat diesen Hash tatsächlich 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 wird. Damit ein externes Skript geladen wird, verlangt CSP, dass alle gültigen Hash-Werte im Attribut auch in der CSP script-src-Deklaration enthalten sein müssen. Daher würde das folgende Skript nicht geladen werden, da der zweite Hash nicht im oben genannten 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 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-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', ein Nonce-Source oder ein Hash-Source angegeben werden, der dem Inline-Block entspricht. 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>

Alle Inline-Skripte zu erlauben, wird als Sicherheitsrisiko angesehen, daher wird empfohlen, stattdessen einen Nonce-Source oder einen Hash-Source zu verwenden. Um Inline-Skripte und -Stile mit einem Nonce-Source zu erlauben, müssen Sie einen zufälligen Nonce-Wert (unter Verwendung eines kryptografisch sicheren Zufalls-Token-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 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 Generieren des Hashes schließen Sie die <script>-Tags nicht ein und beachten Sie, dass Groß- und Kleinschreibung sowie Leerzeichen, einschließlich führender oder nachfolgender Leerzeichen, eine Rolle spielen.

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

Richtlinien für Inline-Ressourcen mit Hashes wie script-src 'sha256-{HASHED_INLINE_SCRIPT}' erlauben Skripte und Stile nach ihrem Hash, aber keine 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' zuzulassen, können Sie den Quellausdruck 'unsafe-hashes' verwenden, wenn der Code nicht auf äquivalente 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 die Ausführung des Skripts:

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

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

• eval()
• Function()

• Wenn ein Stringliteral wie bei Methoden wie: setTimeout("alert(\"Hello World!\");", 500); übergeben wird.

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

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

Der Quellausdruck 'wasm-unsafe-eval' steuert die WebAssembly-Ausführung. 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 zu laden und auszuführen.

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

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

Der Quellausdruck 'strict-dynamic' legt fest, dass das Vertrauen, das einem im Markup präsentem Skript explizit gegeben wird, indem man es mit einem Nonce oder einem Hash begleitet, auf alle Skripte übertragen wird, die von diesem Wurzelskript geladen werden. Gleichzeitig werden alle Allowlists oder Quellausdrü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"> und die Weitergabe dieses Vertrauens an jedes Skript erlauben, das von loader.js geladen wird, jedoch das Laden von Skripten von https://allowlisted.example.com/ nicht erlauben, 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 in einer rückwärtskompatiblen Weise bereitzustellen, ohne dass Benutzeragenten-Sniffing erforderlich ist. 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: agieren, in Browsern, die CSP2 unterstützen, wie https: 'nonce-abcdefg', und in Browsern, die CSP3 unterstützen, wie 'nonce-abcdefg' 'strict-dynamic'.

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 eine Nonce-Quelle verwenden. Zum Beispiel:

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

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