CSP-Nonces: Skripte gezielt autorisieren

Was ein CSP-Nonce autorisiert

Der Server trägt einen Wert in die script-src-Direktive und denselben Wert in das nonce-Attribut der beabsichtigten script-Elemente ein. Der Browser kann diese Elemente dadurch autorisieren. Das funktioniert für Inline-Skripte und externe Skriptelemente. Für style-Elemente gibt es den entsprechenden Weg über die Stildirektive; ein Skript-Nonce erlaubt nicht automatisch Stile. MDN: Nonces in CSP

Ein Nonce saniert weder den Skriptinhalt noch die Daten, die das Skript später verwendet. Markieren Sie nur Elemente, deren Ausführung Sie beabsichtigen. Ein nachträglicher Durchlauf, der jedem gefundenen Skript einen Nonce gibt, könnte auch eingeschleusten Code freigeben.

Nonce bedeutet hier keine Anmeldung oder Berechtigungsprüfung für einen Nutzer. Es ist eine Autorisierung im CSP-Regelwerk. Fehlt der passende Nonce, scheitert zunächst dieser Freigabepfad. Andere wirksame Quellen, Hashes oder dynamische Ladewege können das Skript dennoch erlauben; weitere durchgesetzte Policies können es zusätzlich blockieren.

Die Spezifikation verlangt einen neuen Wert bei jeder übermittelten Policy. Sie empfiehlt mindestens 128 Bit vor der Kodierung und einen kryptographisch sicheren Zufallsgenerator. Derselbe Wert kann mehrere autorisierte Elemente einer Antwort markieren. Ein einzelner Headerabruf beweist weder Unvorhersehbarkeit noch fehlende Wiederverwendung oder die richtige Zuordnung im HTML. W3C: Nonce-Anforderungen

Grenze eines Nachweises: CSP kann Skript-Injection erschweren. Ein Nonce oder Hash allein belegt jedoch kein vollständiges Skriptinventar, keine fortlaufende Integritäts- oder Manipulationskontrolle und keine NIS2-, PCI-DSS- oder Datenschutzkonformität. Für relevante Zahlungsskripte beschreibt PCI SSC zusätzliche Anforderungen im Kontext von PCI DSS 4.0.1. PCI SSC: Sicherheit von Zahlungsseiten

Erzeugung, Header und HTML zusammenführen

1. Einen geeigneten Zufallswert erzeugen

Verwenden Sie einen kryptographisch sicheren Zufallsgenerator. Math.random() ist keine geeignete kryptographische Quelle. Die folgenden unabhängigen Ausschnitte erzeugen jeweils 16 zufällige Bytes und kodieren sie als Base64. Die beiden Node.js-Varianten und der Python-Ausschnitt wurden hier ausgeführt; der PHP-Ausschnitt wurde anhand der Herstellerdokumentation geprüft, nicht in einer PHP-Laufzeit.

Node.js, CommonJS:

const crypto = require('node:crypto');
const nonce = crypto.randomBytes(16).toString('base64');

Web Crypto in Node.js, CommonJS:

const { webcrypto } = require('node:crypto');
const array = new Uint8Array(16);
webcrypto.getRandomValues(array);
const nonce = Buffer.from(array).toString('base64');

Die zweite Variante zeigt die Web-Crypto-Schnittstelle in einer ausdrücklich benannten Serverumgebung. Eine vergleichbare API existiert auch im Browser; ein dort nachträglich erzeugter Wert setzt aber nicht rückwirkend den zuvor empfangenen CSP-Antwortheader. Die Erzeugung muss mit Ihrer tatsächlichen HTML- und Headerausgabe verbunden werden. Node.js: randomBytes und Web Crypto

PHP:

<?php
$nonce = base64_encode(random_bytes(16));

PHP: random_bytes liefert kryptographisch geeignete Zufallsbytes. Wenn die Erzeugung fehlschlägt, darf ein fester Ersatztoken nicht unbemerkt an ihre Stelle treten.

Python:

import secrets
import base64

nonce = base64.b64encode(secrets.token_bytes(16)).decode('ascii')

Python: secrets ist für sicherheitsrelevante Zufallswerte vorgesehen. Die explizite Bytezahl vermeidet eine Abhängigkeit von einem Standardwert der Funktion.

16 Bytes entsprechen 128 Bit. In gepolstertem Base64 ergeben sie 24 Zeichen einschließlich der abschließenden ==. Die Zeichenanzahl eines beliebigen Tokens beweist aber keine Entropie; ein fester 24-Zeichen-Wert bleibt fest.

2. Den Wert in den CSP-Header übernehmen

In der Direktive steht vor dem Wert nonce-, und der ganze Quellausdruck ist in einfache Anführungszeichen eingeschlossen. Im HTML-Attribut steht nur der Wert. Der folgende feste Wert ist ausschließlich ein synthetischer Platzhalter, kein erzeugtes Messergebnis und kein Produktionstoken. Er muss bei der wirklichen Auslieferung ersetzt werden.

Content-Security-Policy: default-src 'self'; script-src 'nonce-N4M0bqjA3jEwA8aSPT9V1w==' 'strict-dynamic'; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'self'

Die Policy zeigt das Zusammenspiel der Quellen. Sie ist keine universelle Konfiguration: 'unsafe-inline' erlaubt hier bewusst Inline-Stile; object-src 'none' sperrt entsprechende Einbettungen, und base-uri 'self' begrenzt die Basis-URL. Ob diese Werte zur Anwendung passen, ist offen. Der Headerwert steht in einer Zeile.

3. Ausschließlich beabsichtigte Elemente markieren

Die nächsten Elemente gehören zum eben gezeigten Modell. Angenommen sind ein unterstützender Browser, Enforcement, keine abweichende script-src-elem-Regel und keine weitere blockierende Policy. Unter diesen Bedingungen autorisiert der passende Nonce die ersten beiden Elemente; das dritte Inline-Skript ohne Nonce würde blockiert. Das ist eine Regelerklärung, kein Browserergebnis.

<script nonce="N4M0bqjA3jEwA8aSPT9V1w==">
  console.log('Authorised example');
</script>

<script nonce="N4M0bqjA3jEwA8aSPT9V1w==" src="/main.js"></script>

<script>console.log('Example without a nonce');</script>

Header und autorisierte Elemente derselben Antwort müssen denselben Wert verwenden. Es genügt nicht, nur den Header zu erneuern oder nur das HTML anzupassen. Prüfen Sie auch zusätzliche Policies: Ein gültiger Nonce in einer Policy setzt eine Sperre in einer anderen nicht außer Kraft.

Was strict-dynamic verändert

'strict-dynamic' erlaubt im entsprechenden Skriptkontext nicht vom HTML-Parser eingefügte Skripte. Ein per Nonce oder Hash autorisiertes Skript kann so weitere Skripte nachladen, etwa mit document.createElement('script'). Eine Einfügung über document.write() gehört nicht automatisch dazu. W3C: strict-dynamic

Unter der Modellpolicy oben wäre der folgende Ladeweg durch strict-dynamic erlaubt. Der Code wurde nicht ausgeführt; die Datei auf cdn.example.com ist ein Beispielziel.

<script nonce="N4M0bqjA3jEwA8aSPT9V1w==">
  const script = document.createElement('script');
  script.src = 'https://cdn.example.com/library.js';
  document.head.appendChild(script);
</script>

In unterstützenden Browsern werden für diese Skriptauswertung Host- und Schemaquellen sowie 'self' und 'unsafe-inline' ignoriert. Nonces und Hashes bleiben relevant. Ohne strict-dynamic benötigt das nachgeladene Element einen anderen passenden Freigabepfad; eine Hostfreigabe ist eine Möglichkeit, nicht die einzige.

Die verbreitete Bezeichnung „Vertrauenskette“ beschreibt hier weitergegebene Ausführungsrechte. Sie beweist keine Vertrauenswürdigkeit des geladenen Inhalts. Kann ein Angreifer die vom Ladeprogramm verwendete URL steuern, kann dieser Weg missbraucht werden. Verwenden Sie strict-dynamic nur mit kontrollierten Ladewegen und tatsächlichem Bedarf. Der CSP-3-Entwurf weist ausdrücklich darauf hin, dass der Mechanismus vermieden werden sollte, wo er nicht gebraucht wird. W3C: Strict CSP

Kompatibilitätswerte sind zusätzliche Freigaben

Das folgende historische Kompatibilitätsmuster bewirkt je nach unterstütztem CSP-Level Unterschiedliches. NONCE_VALUE ist ein Platzhalter:

script-src 'nonce-NONCE_VALUE' 'strict-dynamic' 'unsafe-inline' https:

Das ist eine Erklärung der Rückfallwirkung, keine Empfehlung für „maximale Sicherheit“ in allen Browsern. Entscheiden Sie anhand Ihrer Zielbrowser, welche älteren Freigaben vertretbar sind. MDN: script-src und strict-dynamic

Fehler bei Erzeugung und Caching vermeiden

Ein CDN-Cache mit fertigem Nonce-HTML löst die Anforderung an neue Werte nicht von selbst. Ein geeigneter Auslieferungsschritt müsste Policy und ausschließlich autorisierte Elemente konsistent neu erzeugen. Pauschales nachträgliches Markieren aller Skripte ist dafür ungeeignet. Bei statischen Inhalten können Hashes besser passen. MDN: Nonces und Hashes

Cache-Control: no-store kann für dynamisch erzeugtes HTML Teil einer passenden Strategie sein. Es erzeugt aber keinen Nonce, entfernt nicht automatisch zuvor gespeicherte Antworten und beweist keine korrekte CDN- oder Anwendungskonfiguration. Prüfen Sie die tatsächlich beteiligten Caches und die Konsistenz von Header und HTML; eine bloße Direktive ersetzt diesen Abgleich nicht. RFC 9111: no-store

British Airways 2018: Ein Nonce ist keine Inhaltsprüfung

Die britische Datenschutzbehörde ICO beschreibt in ihrer Entscheidung vom 16. Oktober 2020, dass ein Angreifer nach einem Netzwerkzugriff eine vorhandene JavaScript-Datei auf der Website von British Airways veränderte. Die Änderung diente dem Abfluss von Kartendaten. Die verhängte Geldbuße betrug 20 Millionen Pfund. ICO: British Airways Penalty Notice, Absätze 1.2 und 1.7

Daraus lässt sich nicht ableiten, ein Nonce hätte den konkreten Angriff verhindert. Wenn ein autorisiertes externes Skriptelement auf eine veränderte Datei zeigt, ist der Nonce keine Prüfung ihrer Bytes. Für die Integrität einer Datei kommen andere Mechanismen wie Subresource Integrity infrage; auch deren Wirkung hängt von der konkreten Einbindung ab. Die historische Fallbeschreibung ist kein durchgeführter CSP-Gegenversuch.

unsafe-inline und Nonces vergleichen

Ohne einen im selben Inline-Kontext wirksamen Nonce oder Hash erlaubt 'unsafe-inline' beliebige Inline-Skripte. Unterstützende Browser ignorieren es in einer entsprechenden Nonce- oder Hash-Quellenliste. Beachten Sie script-src-elem und script-src-attr getrennt: Eine eigens gesetzte Attributregel kann Ereignishandler weiter erlauben. Ein Nonce an einem script-Element autorisiert nicht dessen beliebige onclick-Nachbarn. MDN: script-src

Vorausgesetzt sind Enforcement, Browserunterstützung und keine andere effektive Skriptelementregel. NONCE_VALUE steht für einen korrekt erzeugten Wert. Die Tabelle ist ungemessen; sie verspricht weder einen erfolgreichen Datendiebstahl im ersten noch eine insgesamt sichere Seite im zweiten Fall.

Nonce oder Hash: nach der Auslieferung entscheiden

Nonces und Hashes lassen sich kombinieren. Das macht einen wiederverwendeten Nonce in einer vollständig gecachten Antwort aber nicht korrekt. Für eine konkrete Integration müssen Sie die Erzeugungs- und Cachewege sowie die tatsächlich ausgegebenen Skripte untersuchen.

Vollständiges Antwortpaar und eigene Browserprobe

Die folgende CommonJS-Funktion wurde im lokalen Node.js-24.3.0-Labor verwendet. Sie erzeugt bei jedem Aufruf eine neue Dokumentantwort. Zwei beabsichtigte Inline-Skripte und ein eigenes externes Skript teilen den Nonce dieser Antwort. Die feste Beispieldatei /main.js muss Ihre Anwendung selbst ausliefern; in der Probe setzte sie lediglich eine beobachtbare Testvariable.

const { randomBytes } = require('node:crypto');

function createDocument(label) {
  const nonce = randomBytes(16).toString('base64');
  const data = JSON.stringify({ label: String(label) })
    .replace(/</g, '\\u003c')
    .replace(/\u2028/g, '\\u2028')
    .replace(/\u2029/g, '\\u2029');

  const headers = {
    'Content-Type': 'text/html; charset=utf-8',
    'Cache-Control': 'no-store',
    'Content-Security-Policy': `default-src 'self'; script-src 'nonce-${nonce}' 'strict-dynamic'; style-src 'self' 'unsafe-inline'; object-src 'none'; base-uri 'none'`,
  };
  const html = `<!doctype html>
<html lang="de">
<meta charset="utf-8">
<title>Lokales Nonce-Beispiel</title>
<h1 id="output"></h1>
<script nonce="${nonce}">
  window.exampleData = ${data};
  document.getElementById('output').textContent = window.exampleData.label;
</script>
<script nonce="${nonce}">
  document.body.dataset.secondScript = 'executed';
</script>
<script nonce="${nonce}" src="/main.js"></script>
</html>`;
  return { headers, html };
}

module.exports = { createDocument };

Rufen Sie createDocument(label) innerhalb des tatsächlichen Dokument-Requests auf. Übergeben Sie die zurückgegebenen Header an die HTTP-Antwort und danach genau das zurückgegebene HTML als Body. Erzeugen Sie dafür keinen zweiten Nonce und speichern Sie das fertige Paar nicht zur unveränderten Wiederverwendung für weitere Dokumentantworten. In einer vorhandenen Anwendung muss dieser Schritt zu deren Response-API und Cacheweg passen.

Sichere Einbettung ist eine zusätzliche Aufgabe: JSON.stringify erzeugt hier zunächst einen JavaScript-Datenwert. Das Ersetzen von < verhindert, dass eine Zeichenfolge wie </script> den HTML-Skriptblock vorzeitig beendet; die beiden Unicode-Zeilentrenner werden ebenfalls escaped. Die Ausgabe erfolgt über textContent. Der Nonce selbst stammt ausschließlich aus dem Generator und enthält keine eingegebenen Nutzerdaten. Diese Behandlung ist für diesen Kontext gedacht, kein universeller Encoder für HTML, URLs oder andere Templates.

Die gemeinsame CSP-Probe umfasste je Engine 13 Fälle, einschließlich des Report-Only-/Enforcement-Vergleichs. Getrennt liefen die drei Generatorausschnitte mit Node.js 24.3.0 und Python 3.9.6. PHP, ein echter CDN-Cache, fremde Skriptdienste, Safari, iPhone und produktive Anwendungen wurden nicht geprüft. Die absichtliche Cache-Gegenprobe war eine Wiederverwendung durch den eigenen Testserver.

Weiterführende Anleitungen

Der Web Security Check kann einen ersten Befund zu den CSP-Headern der abgerufenen Antwort liefern. Sichere Zufallswerte, fehlende Wiederverwendung, passende HTML-Attribute und funktionierende Skripte belegt ein solcher Abruf nicht.