Note A statt A+: warum unsafe-inline in der CSP bleibt

Würdigung — eine gesetzte CSP ist schon viel mehr als der Durchschnitt#

Wer überhaupt eine Content-Security-Policy ausliefert, ist den meisten Websites bereits voraus. Eine Standard-Installation ohne bewusste Konfiguration liefert oft gar keinen einzigen Sicherheits-Header — der Insight zu den Security-Headern zeigt, wie groß der Unterschied zwischen „nichts gesetzt" und „bewusst konfiguriert" ist. Die CSP ist dabei der anspruchsvollste Header, weil sie eine ganze Regelsammlung ist: Welche Quellen dürfen Skripte liefern, welche Bilder, welche Stile.

Genau deshalb gibt es bei der CSP eine Stelle, an der eine reflexhafte Entscheidung schaden kann. Eine gesetzte CSP, die unsafe-inline erlaubt, bekommt ein A statt eines A+. Der erste Impuls ist, das zu „reparieren" und auf die Bestnote zu stellen. Bei einer statisch ausgelieferten Website ist dieser Impuls aber gefährlich — weil der Weg zum A+ einen Preis hat, der den Gewinn überschreitet.

Warum unsafe-inline der Knackpunkt ist#

Der Sinn einer CSP ist, dem Browser eine Liste erlaubter Skript-Quellen zu geben. Findet sich auf der Seite ein Skript, das nicht auf dieser Liste steht — etwa weil es über eine Lücke eingeschleust wurde —, führt der Browser es nicht aus. Das ist der eigentliche Schutz gegen Cross-Site-Scripting.

unsafe-inline erlaubt jedes direkt im HTML stehende Skript ohne Prüfung. Das hebelt diesen Schutz für eine ganze Kategorie aus — und genau dafür ziehen die strengen Prüfdienste die Note von A+ auf A herab. Der reflexhafte Schluss lautet: weg damit. Die ehrliche Frage lautet: zu welchem Preis?

Warum Nonces hier die Falle sind#

Der lehrbuchmäßige Weg, unsafe-inline zu ersetzen, sind Nonces — bei jedem Seitenaufruf frisch erzeugte Zufallswerte, die im CSP-Header und an jedem erlaubten Inline-Skript stehen. Das funktioniert hervorragend bei Seiten, die ohnehin pro Anfrage frisch auf einem Server entstehen. Bei einer statisch ausgelieferten Website ist es eine Falle.

Der Grund liegt in der Bauweise moderner Frameworks. Eine App-Router-Seite bringt pro Aufruf rund drei Dutzend kleiner Inline-Skripte mit, über die der Browser den fertig gerenderten Zustand übernimmt. Ein einzelner, für alle Seiten gleicher statischer Header kann diese vielen, sich ständig ändernden Inline-Skripte weder über einen festen Hash noch über andere statische Mittel abdecken. Der einzige Weg, hier auf Nonces umzustellen, ist eine Zwischenschicht, die jede Seite bei jedem Aufruf frisch mit einem neuen Zufallswert versieht — also dynamisches Rendering pro Anfrage.

Und damit kippt das ganze Modell. Eine statisch vorgebaute Seite wird einmal erzeugt und blitzschnell aus dem Zwischenspeicher des CDNCDN · zum GlossarContent Delivery Network — globales Netzwerk an Edge-Servern, das statische Inhalte ortsnah ausliefert. ausgeliefert — das ist der Geschwindigkeits- und Sicherheits-Vorteil, der eine moderne Kanzlei-Site von einer datenbankgetriebenen unterscheidet, ausführlich im Insight zum statischen Rendering. Erzwingt man für die Nonce-CSP dynamisches Rendering, fällt genau dieses CDN-Caching weg. Man tauscht den realen Architektur-Vorteil gegen ein Buchstaben-Plus in einem Prüfbericht. Das ist kein guter Tausch.

Auch style-src ist load-bearing#

Dasselbe gilt auf der Stil-Seite, nur aus einem anderen Grund. Das unsafe-inline in der Stil-Direktive trägt bei uns die direkt im Markup gesetzten Akzentfarben — die clusterspezifischen Farbtöne, mit denen jede Insight-Rubrik ihre eigene visuelle Handschrift bekommt. Diese Inline-Stile zu entfernen wäre ein größerer Umbau mit eigenem Risiko und ebenfalls fragwürdigem Nutzen, weil der Sicherheitsgewinn bei Stilen deutlich kleiner ist als bei Skripten. Beide unsafe-inline sind damit nicht Nachlässigkeit, sondern tragende Bestandteile der Architektur.

Messen lohnt sich trotzdem — um zu verstehen, nicht um zu schärfen#

Bevor man eine solche Entscheidung trifft, sollte man die Lage kennen statt sie zu vermuten. Dafür gibt es den Reporting-Mechanismus: Über die report-to-Direktive bekommt die CSP einen Endpunkt genannt, an den der Browser jeden Verstoß meldet, ohne ihn zu blockieren. Man kann die Policy also im Beobachtungsmodus fahren und über echten Verkehr genau sehen, welche Inline-Skripte und -Stile real vorkommen.

Der Unterschied zur reflexhaften Härtung ist die Schlussfolgerung. Wer misst, trifft die Entscheidung mit offenen Augen — und in unserem Fall bestätigt die Messung, dass die Inline-Bestandteile tragend sind und der Weg zum A+ den Architektur-Preis nicht wert ist. Dieselbe Disziplin, die Realität zu messen statt anzunehmen, trägt auch unseren wöchentlichen Security-Sweep.

Die ehrliche Entscheidung — und warum sie im Code festgehalten ist#

Auf fahoch2.de bleiben wir deshalb bewusst bei Note A. Wir behaupten öffentlich auch genau das — Note A, nicht A+ —, es gibt also keinen Unterschied zwischen dem, was wir sagen, und dem, was die Seite liefert. Eine Bestnote, die man nur durch den Verlust des eigentlichen Architektur-Vorteils bekäme, ist keine, die man anstreben sollte.

Wichtig ist, dass eine solche bewusste Entscheidung nicht in Vergessenheit gerät und später versehentlich „nachgeholt" wird, weil jemand nur die Note sieht und nicht den Grund. Deshalb ist die Begründung bei uns als Kommentar direkt in der Konfigurationsdatei eingebrannt: Wer dort das unsafe-inline anfasst, liest zuerst, warum es da steht. Das ist dieselbe Mechanik-vor-Aufmerksamkeit-Haltung, die das ganze Projekt prägt — eine Entscheidung wird nicht nur getroffen, sondern an der Stelle festgehalten, an der man sie sonst rückgängig machen würde.

Was Kanzleien davon haben#

• Architektur vor Buchstaben: Der statische, CDN-gecachte Aufbau ist mehr wert als ein A+, das ihn zerstören würde — Geschwindigkeit und Robustheit bleiben erhalten.
• Keine Schein-Optimierung: Eine Bestnote, die durch dynamisches Rendering teuer erkauft ist, verbessert die Sicherheit real kaum — der Aufwand fließt dorthin, wo er wirkt.
• Ehrliche Kommunikation: Note A wird offen so benannt — kein Unterschied zwischen Anspruch und Auslieferung.
• Entscheidung, die hält: Die Begründung steht im Code, wo man sie sonst versehentlich rückgängig machen würde — eine bewusste Wahl wird nicht still „nachgeholt".

Für eine strukturierte Bewertung Ihres Header-Stands und der sinnvollen — und der bewusst unterlassenen — Härtungsschritte empfehlen wir den Hebel-Audit (890 €, bei Mandanten-Boost-Beauftragung innerhalb von 60 Tagen voll anrechenbar).

Zusammenfassung#

Eine gesetzte CSP ist viel wert, bleibt aber bei Note A stehen, solange sie unsafe-inline erlaubt — denn damit kann ein eingeschleustes Inline-Skript die Schutzwirkung umgehen. Der reflexhafte Weg zum A+ führt über Nonces, und genau der ist auf einer statisch ausgelieferten Website eine Falle: App-Router-Seiten bringen pro Aufruf rund drei Dutzend Inline-Skripte mit, die ein statischer Header nicht abdecken kann; der einzige Nonce-Weg erzwingt dynamisches Rendering und kostet damit das CDN-Caching, das den eigentlichen Architektur-Vorteil ausmacht. Auch das unsafe-inline bei den Stilen ist tragend — es trägt die Cluster-Akzentfarben. Ein Reporting-Endpunkt hilft, diese Lage zu verstehen, bevor man entscheidet. Auf fahoch2.de bleiben wir deshalb bewusst und ehrlich bei Note A: Eine Bestnote, die nur durch den Verlust der statischen Auslieferung zu haben wäre, ist keinen Tausch wert — und die Begründung ist im Code festgehalten, damit sie nicht versehentlich kippt.

Quellen#

• MDN — CSP report-to-Direktive — abgerufen 2026-06-13
• W3C — Reporting API — abgerufen 2026-06-13
• BSI TR-02102 — Kryptographische Verfahren: Empfehlungen und Schlüssellängen — abgerufen 2026-06-13

Disclaimer: Allgemeine fachliche Information zum Zeitpunkt der Veröffentlichung, keine Rechtsberatung. Der beschriebene Stand — Note A mit bewusst behaltenem unsafe-inline — bildet die dokumentierte Architektur-Entscheidung von fahoch2.de zum Veröffentlichungszeitpunkt ab; die richtige Wahl hängt vom eingesetzten Rendering-Modell ab.