CSP-Leitfaden: Report-Only, dann unsafe-inline loswerden

So sieht der Normalfall auf einer laufenden Seite aus, wenn die CSP strenger werden soll:

Content-Security-Policy: script-src 'self' 'unsafe-inline'
Content-Security-Policy-Report-Only: script-src 'self' 'nonce-…'; report-to csp; report-uri /csp-berichte
Reporting-Endpoints: csp="https://www.example.at/csp-berichte"

Die erste Zeile ist die alte, scharfe Richtlinie und blockiert weiter wie bisher. Die zweite ist die neue Richtlinie im Berichtsmodus: Der Browser prüft jede Ressource auch gegen sie, blockiert aber nichts und schickt stattdessen einen Bericht an die Adresse aus der dritten Zeile. Die Spezifikation nennt den Zweck ausdrücklich: Die Kopfzeile erlaubt, „Richtlinien durch Beobachten (nicht Erzwingen) ihrer Wirkung auszuprobieren“, und beschreibt den Weg gleich mit: eine Report-Only-Richtlinie nach bester Schätzung ausrollen, Verstoßberichte lesen, dann zur erzwungenen Richtlinie wechseln (W3C, CSP Level 3, § 3.2).

Ohne Berichtsziel ist die Kopfzeile wirkungslos. Sie blockiert nichts, und sie meldet auch nichts, wenn in der Richtlinie kein report-to oder report-uri steht. MDN formuliert es knapp: Ohne report-to „hat der Vorgang keine Wirkung“ (MDN, Content-Security-Policy-Report-Only). Wer die Kopfzeile setzt und wartet, wartet auf nichts.

Dass beide Kopfzeilen nebeneinander gelten, ist kein Trick, sondern Teil des Standards: Auf eine Ressource können mehrere Richtlinien angewendet werden, und jede hat eine Disposition, entweder enforce oder report (CSP3, § 2.2; MDN, CSP-Leitfaden). Genau dieses disposition-Feld taucht später in jedem Bericht auf. Es sagt, ob die Meldung aus der scharfen oder der beobachtenden Richtlinie stammt. Das zählt, sobald beide laufen, weil sonst nicht klar ist, ob etwas tatsächlich blockiert wurde.

Wie selten der Berichtsmodus draußen läuft, zeigt eine eigene Zählung vom 03.10.2026 an 131 Tiroler Startseiten (in eigener Sache, per curl, nur Summen): 3 senden Content-Security-Policy-Report-Only, 5 noch das alte Report-To, keine einzige Reporting-Endpoints. Von 16 scharfen Policies enthält eine eine report--Direktive. Die anderen 15 erfahren nie, was ihre Policy gerade blockiert.

Dieser Leitfaden hat zwei Teile. Der erste ist der Berichtsmodus: wohin die Berichte gehen, wie sie aussehen, was darin Rauschen ist. Der zweite ist die Frage, was am Ende in der scharfen Richtlinie stehen darf, und warum 'unsafe-inline' dort nichts verloren hat.

Wohin die Berichte gehen#

Es gibt zwei Wege, und sie liefern unterschiedliche Formate.

report-uri ist der alte. Die Direktive nennt eine Adresse, der Browser schickt je Verstoß einen POST mit Content-Type: application/csp-report. Die Spezifikation markiert sie als veraltet und schreibt dazu, dass „ein einzelner Request pro Verstoß schlicht nicht skaliert“ (CSP3, § 6.5.1, § 5.5).

report-to ist der neue. Die Direktive nennt keinen Pfad, sondern einen Namen, und der Name muss in einer eigenen Kopfzeile Reporting-Endpoints auf eine Adresse zeigen (MDN, report-to). Der Browser sammelt die Berichte und liefert sie gebündelt als JSON-Liste mit Content-Type: application/reports+json; die Reporting-API sagt, der Browser holt sich „periodisch“ die Warteschlange und stellt zu (W3C Reporting API, § 3.5). Berichte kommen also verzögert und in Paketen. Das Feld age im Bericht gibt an, wie viele Millisekunden seit dem Verstoß vergangen sind.

Stehen beide Direktiven in einer Richtlinie, gewinnt report-to; report-uri wird dann ignoriert. Die Spezifikation empfiehlt trotzdem beide, damit ältere Browser noch melden können (CSP3, § 6.5.1). MDN begründet das mit dem Stand der Unterstützung (MDN, report-uri):

Quelle: MDN browser-compat-data, Stand 14.09.2026. Firefox hat report-to erst mit Version 149 bekommen; MDN führt das Feature deshalb als „Baseline 2026, neu verfügbar seit März 2026“. Wer heute nur report-to setzt, bekommt von jedem älteren Firefox keinen einzigen Bericht.

Ein Stolperstein in Reporting-Endpoints: Die Adresse muss https sein. Unsichere Endpunkte werden ignoriert, ohne Fehlermeldung (MDN, Reporting-Endpoints).

Warum das nicht per Meta-Tag geht#

Eine normale CSP kann als <meta http-equiv="Content-Security-Policy"> im Dokument stehen. Die Report-Only-Fassung nicht. Die Spezifikation ist eindeutig: „The Content-Security-Policy-Report-Only header is not supported inside a meta element“ (CSP3, § 3.2). Wer keinen Zugriff auf die Serverkonfiguration hat, kann den Berichtsmodus also nicht aus dem Theme heraus nachrüsten; er braucht die Kopfzeile in der Auslieferung. Wo die hingehört, steht in Security-Header einrichten.

Ein zweiter Sonderfall: Die Direktive sandbox wird in einer Report-Only-Kopfzeile „vollständig ignoriert“ (CSP3, § 6.3.2). Sie lässt sich nicht beobachten, nur erzwingen.

Wie ein Verstoßbericht aussieht#

Über report-to kommt ein Objekt vom Typ csp-violation. So sieht das Beispiel bei MDN aus (MDN, report-to):

{
  "age": 53531,
  "type": "csp-violation",
  "url": "https://example.com/csp-report",
  "user_agent": "Mozilla/5.0 …",
  "body": {
    "blockedURL": "inline",
    "disposition": "enforce",
    "documentURL": "https://example.com/csp-report",
    "effectiveDirective": "script-src-elem",
    "originalPolicy": "default-src 'self'; report-to csp-endpoint-name",
    "referrer": "https://www.google.com/",
    "sourceFile": "https://example.com/csp-report",
    "lineNumber": 121,
    "columnNumber": 39,
    "sample": "console.log(\"lo\")",
    "statusCode": 200
  }
}

Die Felder sind in der Spezifikation als CSPViolationReportBody definiert: documentURL, referrer, blockedURL, effectiveDirective, originalPolicy, sourceFile, sample, disposition, statusCode, lineNumber, columnNumber (CSP3, § 5). Das alte report-uri-Format verpackt dasselbe in ein Objekt csp-report mit Bindestrich-Namen: blocked-uri, document-uri, effective-directive, violated-directive, original-policy, script-sample (MDN, report-uri). Ein Endpunkt, der beide Wege bedient, muss beide Schreibweisen kennen.

Zum Lesen reichen drei Felder: effectiveDirective sagt, welche Regel verletzt wurde, blockedURL sagt, was, sourceFile mit Zeile und Spalte sagt, wo es im eigenen Code steht.

sample ist leer, solange 'report-sample' fehlt. Erst mit diesem Schlüsselwort in der Direktive schreibt der Browser die ersten 40 Zeichen des Inline-Codes in den Bericht (CSP3, § 4.2.3). Ohne die Probe steht bei jedem Inline-Skript nur inline, und man weiß nicht, welches gemeint ist. Für die Aufräumarbeit ist das Schlüsselwort deshalb Pflicht.

Das Rauschen durch Erweiterungen#

Wer den ersten Tag Berichte liest, findet Verstöße, die es auf der eigenen Seite gar nicht gibt: blockierte Skripte, die niemand eingebaut hat, mit blockedURL-Werten wie chrome-extension oder moz-extension.

Das sind Browser-Erweiterungen, die Code in die Seite einschleusen. Die Spezifikation sagt, eine Richtlinie „sollte nicht“ mit Add-ons, Erweiterungen oder Bookmarklets in Konflikt geraten, und nennt den Grund gleich mit: Auf solche Features angewendet, erzeugt CSP „eine erhebliche Menge Rauschen in Verstoßberichten“. Chrome nimmt das Schema chrome-extension: deshalb ganz von der Prüfung aus (CSP3, § 9.1). Was bei anderen Browsern und anderen Injektionswegen durchkommt, zeigt sich im Bericht nur verkürzt: Für alles, was nicht http oder https ist, enthält der Bericht nur das Schema, nicht die Adresse (CSP3, § 5.4).

Daraus folgt eine Filterregel, die man beim Auswerten braucht: Ein Bericht, dessen blockedURL kein http- oder https-Wert und keines von inline, eval ist, stammt nicht von deiner Seite. Er sagt etwas über den Browser des Besuchers, nicht über deinen Code, und gehört aussortiert, bevor man zählt.

Ein Endpunkt, der Berichte annimmt#

Der Endpunkt muss wenig können: POST annehmen, den Körper speichern, mit einem Status zwischen 200 und 299 antworten. Die Reporting-API wertet genau diesen Bereich als Erfolg; eine 410 streicht den Endpunkt aus der Liste, alles andere gilt als Fehlschlag (Reporting API, § 3.5.2). Beim alten report-uri-Weg wird die Antwort ohnehin ignoriert (CSP3, § 5.5).

Ein minimales Beispiel für Node, ohne Abhängigkeiten:

import { createServer } from "node:http";
import { appendFile } from "node:fs/promises";

createServer((req, res) => {
  if (req.method !== "POST" || req.url !== "/csp-berichte") {
    res.writeHead(404).end(); return;
  }
  let body = "";
  req.on("data", (chunk) => { if ((body += chunk).length > 65536) req.destroy(); });
  req.on("end", async () => {
    let berichte = [];
    try {
      const daten = JSON.parse(body);
      // report-to: Liste von Berichten; report-uri: ein Objekt mit "csp-report"
      berichte = Array.isArray(daten) ? daten : [daten];
    } catch { res.writeHead(400).end(); return; }
    const zeile = berichte.map((b) => JSON.stringify(b)).join("\n") + "\n";
    await appendFile("csp-berichte.jsonl", zeile);
    res.writeHead(204).end();
  });
}).listen(3000);

Zwei Dinge sind darin absichtlich drin. Die Größenbegrenzung, weil jeder Browser der Welt an diese Adresse schicken darf. Und die Unterscheidung Liste oder Objekt, weil report-to eine Liste liefert und report-uri ein einzelnes Objekt. MDN weist zudem darauf hin, dass Berichte als angreifergesteuerte Daten zu behandeln und vor dem Speichern oder Anzeigen zu bereinigen sind, besonders das Feld script-sample (MDN, report-uri). Wer die Datei später in einem Browser ansieht, sollte das ernst nehmen.

Am wenigsten Ärger macht ein Endpunkt auf derselben Domain wie die Seite. Die Reporting-API schickt cross-origin ohne Anmeldedaten und im CORS-Modus (Reporting API, § 3.5.2); wer das Ziel woanders betreibt, muss sich um diese Antwortkopfzeilen kümmern.

Scharf nur ohne 'unsafe-inline'#

Von 131 Tiroler Startseiten, die ich am 03.10.2026 per curl abgerufen habe, senden 16 eine Content-Security-Policy. 11 davon sind reine frame-ancestors-Anweisungen, also Einbettungsschutz ohne Skriptregel. Nur 4 enthalten script-src oder default-src, und 3 dieser 4 erlauben 'unsafe-inline'. Eine arbeitet mit Nonce. (In eigener Sache gemessen, nur Summen; die ganze Verteilung steht in Security-Header einrichten.)

Wer eine Skript-Policy hat, hat die Lücke also meistens drin. Und sie ist keine kleine: 'unsafe-inline' in script-src erlaubt genau das, wogegen die CSP gedacht war, nämlich eingeschleusten Code, der direkt im Dokument steht. Die Richtlinie ist an ihrer wichtigsten Stelle wirkungslos, auch wenn jeder Scanner sie grün anzeigt.

Das ist keine Nachlässigkeit einzelner. Es ist der Weg des geringsten Widerstands: Ohne 'unsafe-inline' bricht alles, was ein Theme, ein Plugin oder ein Tag-Manager als Inline-Skript in die Seite schreibt, und die Richtlinie wird dann so lange aufgeweicht, bis nichts mehr bricht. Der Berichtsmodus oben ist der Weg, das zu vermeiden: Er zeigt, welche Inline-Skripte es gibt, bevor etwas bricht.

Warum das die Schutzwirkung aufhebt#

Der Kern einer CSP für Skripte ist eine Herkunftsprüfung: Der Browser führt nur aus, was aus einer erlaubten Quelle kommt. Cross-Site-Scripting funktioniert, indem ein Angreifer eigenen Code in deine Seite einschleust, und der steht dann inline, direkt im Markup.

script-src 'self' 'unsafe-inline' sagt dem Browser: Führe alles aus, was im Dokument steht. Der eingeschleuste Code steht im Dokument. Er wird ausgeführt.

Man behält also die Richtlinie, den Kopfzeileneintrag und das gute Gefühl, und verliert den Schutz, für den man sie eingeführt hat.

Wie das von außen aussieht, zeigt der Security-Scan an der eigenen Seite: www.cyberscale.io bekommt am 03.10.2026 genau diese eine Warnung, alles andere steht.

Und so sieht es aus, wenn die Policy ohne 'unsafe-inline' auskommt: www.elitegear.io, ebenfalls eine eigene Seite, erlaubt das eine Inline-Skript per Hash. Gleicher Scan, gleicher Tag, keine Warnung.

Die zwei Auswege: Nonce oder Hash#

Nonce. Der Server erzeugt bei jedem Aufruf eine Zufallszeichenfolge, schreibt sie in die Kopfzeile (script-src 'nonce-abc123') und in jedes erlaubte <script nonce="abc123">. Nur was die Zahl trägt, wird ausgeführt, und der Angreifer kennt sie nicht, weil sie sich bei jedem Aufruf ändert.

Hash. Der Server nennt den SHA-Hash des erlaubten Skriptinhalts: script-src 'sha256-...'. Ändert sich das Skript um ein Zeichen, passt der Hash nicht mehr.

Die Wahl ist im Kern eine Frage der Ausspielung:

Faustregel: Wer eine Seite ausliefert, die vollständig zwischengespeichert wird, kann keine Nonce verwenden. Sie wäre in jeder gecachten Kopie dieselbe und damit wertlos. Dann bleibt der Hash.

Der Fallstrick mit dem doppelten Netz#

Steht in der Richtlinie sowohl eine Nonce oder ein Hash als auch 'unsafe-inline', dann ignorieren Browser, die CSP Level 2 oder 3 können, das 'unsafe-inline'. So legt es die Spezifikation fest, als Rückfall für alte Browser (MDN, script-src).

Das klingt gut und hat eine unangenehme Folge: Deine Seite funktioniert im Test weiter, obwohl du die Richtlinie verschärft hast, aber nur, weil der Browser den strengeren Teil anwendet. Wer die Nonce falsch einbaut und den Fehler nicht bemerkt, weil 'unsafe-inline' noch als Netz gedacht war, merkt es erst, wenn er es entfernt.

Deshalb: 'unsafe-inline' streichen, nicht danebenstehen lassen.

Was 'unsafe-inline' bei Styles bedeutet#

Bei style-src ist die Lage entschärft, aber nicht harmlos. Über eingeschleustes CSS lassen sich Inhalte verdecken, Schaltflächen verschieben und in manchen Konstellationen Daten abgreifen. Die Schutzwirkung ist geringer als bei Skripten, der Aufwand für die Umstellung aber auch: Sobald die letzten style=-Attribute weg sind, kommt eine Seite bei Styles meist ohne 'unsafe-inline' aus.

Reihenfolge: erst script-src, dann style-src. Der Ertrag liegt bei den Skripten.

Und wenn es nicht geht#

Manche Baukästen und Plugins erzeugen Inline-Skripte, an die man nicht herankommt. Dann ist 'unsafe-inline' bei script-src eine bewusste Entscheidung und keine Nachlässigkeit. Sie sollte nur so dokumentiert sein, dass beim nächsten Sicherheitscheck niemand denkt, hier sei etwas übersehen worden. In eigener Sache: Diese Seite selbst trägt 'unsafe-inline' in script-src, solange ihre Werkzeugseiten Inline-Skripte brauchen; die Begründung steht offen in Security-Header einrichten, zusammen mit den übrigen Kopfzeilen, die eine Seite neben der CSP braucht.

Der Weg zum Scharfschalten#

Der Weg dauert Tage, nicht Minuten. Nicht wegen der Arbeit, sondern weil die Berichte Zeit brauchen, um alle Seiten und alle Browser abzudecken.

1. Endpunkt aufsetzen und mit curl -X POST prüfen, dass er 204 antwortet.
2. Reporting-Endpoints setzen und die neue Richtlinie in Content-Security-Policy-Report-Only, mit report-to, report-uri und 'report-sample'. Die alte scharfe Richtlinie bleibt unverändert.
3. Prüfen, dass die Kopfzeilen ankommen. Nicht im Browser, der zwischenspeichert, sondern mit einem Abruf direkt beim Server (curl -sI). Der Security-Scan zeigt, welche Schutzkopfzeilen der Server tatsächlich mitschickt.
4. Einige Tage sammeln. Nicht eine Stunde. Unterseiten, die selten aufgerufen werden, melden sich erst spät.
5. Rauschen aussortieren: alle Berichte mit Schema statt Adresse in blockedURL weg.
6. Den Rest gruppieren nach effectiveDirective und blockedURL. Was übrig bleibt, ist die Liste der Dinge, die die neue Richtlinie brechen würde: eigene Inline-Skripte, Plugin-Skripte, fremde Dienste.
7. Aufräumen, nicht erlauben. Jedes Inline-Skript, das in eine eigene Datei kann, kommt in eine eigene Datei; das hält die Zahl der Nonces und Hashes klein. Den Rest per Nonce oder Hash freigeben, fremde Dienste einzeln. Welche der beiden Methoden passt, steht oben.
8. Neue Fassung wieder in Report-Only, bis die Berichte für die eigene Seite auf null sind.
9. Tauschen: Die Richtlinie aus Content-Security-Policy-Report-Only wandert nach Content-Security-Policy, das Berichtsziel bleibt drin. Auch eine scharfe Richtlinie soll melden, denn erst dann sieht man, wenn ein Plugin-Update etwas Neues einschleust.

Schritt 8 ist der, den man gern überspringt. Wer nach dem Aufräumen direkt scharf schaltet, verlässt sich darauf, dass alle Änderungen richtig waren. Der Berichtsmodus kann das prüfen, und er kostet nur Wartezeit.

Fünf Wege, auf denen die Berichte ausbleiben#

Report-Only als Dauerzustand. Die Kopfzeile schützt nicht. Eine Seite, die seit einem Jahr nur beobachtet, hat keine CSP, sondern ein Protokoll.

Nur report-to, weil es das neue ist. Damit fehlen alle Berichte aus Browsern, die es noch nicht können, bei Firefox alles vor Version 149. Beide Direktiven setzen, bis die eigenen Zugriffszahlen zeigen, dass der alte Weg leer bleibt.

Berichte an eine http-Adresse. Reporting-Endpoints verwirft sie stillschweigend. Es kommt nichts an, und nichts sagt einem, warum.

Ein <meta>-Tag im Theme. Funktioniert für die scharfe Richtlinie, für die beobachtende nicht.

Die Berichte nach einem Nachmittag auswerten, und dann erlauben, was gemeldet wurde. Die Reporting-API liefert verzögert und gebündelt, und die Zugriffe auf selten besuchte Seiten kommen erst nach Tagen. Und der Reflex, jede gemeldete Quelle in die Richtlinie zu schreiben, endet bei einer Liste von dreißig Hosts und 'unsafe-inline' obendrauf. Die Berichte zeigen, was aufzuräumen ist, nicht, was freizugeben ist.

Der Berichtsmodus ist der einzige Weg, eine CSP auf einer laufenden Seite zu verschärfen, ohne sie abzuschießen. Er ist aber nur so gut wie die Stelle, an der die Berichte landen, und wie die Geduld, sie ein paar Tage liegen zu lassen. Was am Ende in der scharfen Richtlinie steht, entscheidet über den Schutz: mit 'unsafe-inline' bleibt es ein Protokoll. Welche Kopfzeilen neben der CSP noch fehlen und in welcher Reihenfolge man sie setzt, steht in Security-Header einrichten; was deine Seite heute ausliefert, zeigt der Security-Scan.

Häufige Fragen#

Stand 05.10.2026. An diesem Tag hat der Beitrag den bisherigen Beitrag „Content-Security-Policy: unsafe-inline loswerden“ aufgenommen; dessen Adresse leitet hierher. Quellen abgerufen am 03.10.2026; die Header-Zählung der 131 Tiroler Startseiten und die Werkzeug-Screenshots stammen vom selben Tag.