Warum sich Report-Only und Enforced bei Content Security Policy unterscheiden

Von Mirko Peters · 2026-04-23

Wenn Ihnen Websicherheit wirklich wichtig ist, ist der Unterschied zwischen den Modi „Report-Only“ und „Enforced“ in der Content Security Policy (CSP) kein Detail, sondern entscheidend. Der Report-Only-Modus zeigt Ihnen, was Ihre Richtlinie blockieren würde, ohne tatsächlich etwas zu stoppen. Ihre Website wird so zu einer Art Testumgebung für Sicherheitsmaßnahmen. Der Enforced-Modus dagegen lässt

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Cover: Fix Conditional Access Loopholes in Microsoft 365

Dieser Artikel erläutert, warum diese Modi wichtig sind, welche Auswirkungen sie auf Browser und Nutzererlebnis haben und wie Sie den Weg vom reinen Monitoring zu echtem Schutz gehen. Er richtet sich gezielt an Sicherheitsexperten und Entwickler mit Microsoft-Fokus, die ihre CSP-Konfiguration richtig aufsetzen wollen. Behandelt werden Begriffsdefinitionen, praktische Vorgehensweisen sowie Best Practices für einen sicheren Rollout und eine effiziente Compliance.

Die CSP-Modi und ihre Auswirkungen verstehen

Bevor Sie CSP-Header einsetzen, sollten Sie die beiden Hauptmodi der CSP verstehen: Report-Only und Enforced. Diese Modi sind mehr als bloße Einstellungen. Sie bestimmen, wie moderne Browser die Sicherheitsgrenzen Ihrer Webanwendung durchsetzen oder lediglich beobachten. Ihre Wahl wirkt sich direkt auf das Risikoniveau Ihrer Website, die Prüfbarkeit und den reibungslosen Ablauf des Rollouts aus, insbesondere in großen Microsoft-Umgebungen oder Multi-Cloud-Szenarien.

CSP-Modi wurden entwickelt, um Webteams Flexibilität zu bieten. Der Report-Only-Modus ist der sanfte Einstieg: Sie überwachen Probleme, ohne Nutzer versehentlich zu beeinträchtigen. Er unterstützt die Risikobewertung, hilft, Lücken in der Richtlinie aufzuspüren, und kann Altcode oder unerwartetes Verhalten von Drittanbieter-Skripten sichtbar machen, während Ihre Anwendung vollständig funktionsfähig bleibt.

Der Enforced-Modus ist der eigentliche Ernstfall: Er weist den Browser an, Ihre Vorgaben tatsächlich umzusetzen. Entspricht Inhalt nicht Ihrer Richtlinie, wird er sofort blockiert. So verringert sich die Angriffsfläche etwa für Cross-Site-Scripting oder schädliche Drittanbieter-Skripte unmittelbar. Allerdings bedeutet das auch: Fehler oder unvollständige Richtlinien können Ihre Anwendung unterbrechen, wenn Sie beim Testen und bei der Einführung nicht sorgfältig vorgehen.

Die Idee hinter beiden CSP-Modi ist einfach: Entwickler und Sicherheitsteams sollen ihre Regeln unter realen Bedingungen verfeinern, bevor sie scharf geschaltet werden. Man kann es sich wie Stützräder für die Sicherheit Ihrer Anwendung vorstellen, mit einem klaren Ziel, ab dem Sie zur vollständigen Durchsetzung übergehen. Als Nächstes zeigen wir, wie Report-Only Ihnen dieses Feedback aus der Praxis liefert und was sich ändert, sobald die Durchsetzung ins Spiel kommt.

Wie Content-Security-Policy-Report-Only Verstöße meldet

Der Report-Only-Modus ermöglicht es Ihnen, das Geschehen vom Spielfeldrand aus zu beobachten, bevor Sie selbst aufs Feld treten. Wenn Sie den HTTP-Header Content-Security-Policy-Report-Only verwenden, weisen Sie den Browser an, Verstöße zu beobachten, aber nichts zu blockieren, sondern nur zu melden. So erhalten Sie einen Strom von Verstoßberichten an Ihren festgelegten Endpunkt und damit einen vollständigen Überblick darüber, was blockiert würde, wenn die Richtlinie durchgesetzt wäre.

Browser senden diese Verstoßberichte (häufig als JSON-Payload), sobald eine Ressource gegen Ihre CSP-Regeln verstößt. Versucht eine Seite beispielsweise, ein Skript von einer nicht freigegebenen Quelle zu laden, wird im Report-Only-Modus kein Skript blockiert. Sie erhalten jedoch eine Meldung mit Details wie der betroffenen URL, der verletzten Direktive und manchmal auch einem Ausschnitt des verdächtigen Codes.

Dieser Modus ist für Risikobewertungen und sicheres Testen unbezahlbar. Sie können neue Regeln über eine Vielzahl von Webanwendungen ausrollen, beobachten, was ausgelöst wird, und die Richtlinie anhand tatsächlicher Daten statt bloßer Vermutungen anpassen. Betreiben Sie Altsysteme oder geschäftskritische Workflows, riskieren Sie durch ein zu schnelles Vorgehen weder Ausfälle noch Supportanfragen.

Report-Only unterstützt außerdem schrittweise Rollouts. Starten Sie offen, prüfen Sie, was angepasst werden muss, und ziehen Sie die Sicherheit Schritt für Schritt an. So lassen sich Probleme mit Drittanbieter-Skripten, CDN-Inhalten oder verschleiertem JavaScript erkennen, die sonst erst bei der Durchsetzung als massiver Ausfall sichtbar würden. Zudem ist das ein Compliance-Gewinn: Sie können belegen, dass Sie aktiv überwachen, was bei Audits hilfreich ist, wenn Ihre Organisation die gebotene Sorgfalt nachweisen muss.

Wie der Enforced-Modus die Sicherheit erhöht

Der Enforced-Modus bedeutet, dass Ihre CSP-Richtlinie keine bloße Empfehlung mehr ist, sondern verbindliche Regel wird. Wenn Sie den Header Content-Security-Policy verwenden, blockieren Browser tatsächlich jeden Inhalt, der nicht zu Ihren Direktiven passt – ohne Warnung, sondern mit konkreter Aktion.

Dieser Modus härtet Ihre Web-App deutlich gegen Angriffe wie XSS und das unautorisierte Einschleusen von Skripten. Seien Sie jedoch vorsichtig: Ist Ihre Richtlinie noch nicht ausgereift, können Sie versehentlich notwendige Ressourcen blockieren und die Funktionalität der Website beeinträchtigen. Der klügere Weg ist, die Richtlinie zuerst im Report-Only-Modus zu testen. Letztlich macht der Enforced-Modus aus einer theoretischen Richtlinie einen praktischen Schutz und gilt damit als Goldstandard für starke Websicherheit.

Reporting mit report-uri und report-to Endpoints einrichten

Mit einem eingerichteten Reporting gewinnt Ihre CSP-Richtlinie echte Schlagkraft – und zusätzlich eine Art Aufsicht. CSP erlaubt es Ihnen, einen oder mehrere Endpoints anzugeben (über report-uri oder report-to), an die Browser Verletzungsberichte senden sollen. Tritt eine Verletzung auf, bündelt der Browser Details wie die blockierte Ressource und die fehlgeschlagene Richtlinie in einer JSON- oder HTTP-POST-Nachricht und sendet sie an Ihren Endpoint.

Die Direktive report-uri ist die ältere Methode: Sie hinterlegen eine URL, und Browser senden die Berichte direkt dorthin. Für moderne Flexibilität und umfangreichere Berichte ist report-to die neuere, robustere Option – insbesondere, da Browser die Reporting API zunehmend unterstützen. report-to arbeitet mit einer benannten Gruppe, die unterschiedliche Berichtstypen verarbeiten kann, und bietet eine bessere Filterkontrolle.

Beim Konfigurieren dieser Endpoints sollten Sie diese absichern: HTTPS, Zugriffskontrollen und Monitoring auf ungewöhnliche Spitzen, die auf einen Angriff oder eine fehlerhafte Richtlinie hindeuten können. Denken Sie außerdem an den Datenschutz: Berichte können URLs oder sogar Ausschnitte des beanstandeten Skripts enthalten. Daher müssen Sie sensible Informationen bereinigen, bevor Sie die Berichte speichern oder weitergeben, und dabei Vorgaben wie die DSGVO und den CCPA beachten.

Der eigentliche Nutzen liegt in der Transparenz. Mit einem korrekt konfigurierten Reporting erhalten Sie einen Live-Überblick darüber, wo Ihre Richtlinie Verstöße abfängt. So können Sie nachjustieren, feinabstimmen und schließlich ohne böse Überraschungen sicher in den Enforced-Modus wechseln. Diese Form der Überwachung ist unverzichtbar, egal ob Sie eine einzelne App oder eine umfangreiche Microsoft 365-Umgebung betreuen.

CSP-Syntax und Direktiven für einen wirksamen Richtlinienentwurf verstehen

Einen soliden CSP-Header zu schreiben ist keine Raketenwissenschaft, erfordert aber Sorgfalt – vor allem, wenn komplexe Apps und Microsoft-Cloud-Integrationen zusammenspielen. Im Kern ist eine CSP-Richtlinie eine strukturierte Liste von Direktiven, die jeweils festlegen, was Browser zulassen und was nicht. Sie übermitteln diese Richtlinien über HTTP-Header, typischerweise als Content-Security-Policy oder Content-Security-Policy-Report-Only, formatiert als Zeichenfolgen mit durch Semikolons getrennten Regeln.

Das Herzstück Ihrer Richtlinie bilden zentrale Direktiven wie default-src, script-src und img-src. default-src dient als Fallback: Hat ein bestimmter Inhaltstyp keine eigene Regel, prüft der Browser diese. script-src und img-src steuern gezielt Skripte und Bilder und erlauben Ihnen, vertrauenswürdige Quellen streng zu kontrollieren – etwa Ihre eigenen Domains, vertrauenswürdige CDNs und vielleicht ein Microsoft-Azure-Blob-Speicher.

Die Syntax ist entscheidend. Jede Direktive listet erlaubte Werte auf: URLs, Schemata wie ‘https:’ oder Schlüsselwörter wie ‘self’. Wenn Sie Inline-Skripte erlauben (was bei älterem Code manchmal nötig ist), benötigen Sie unter Umständen ‘unsafe-inline’. Seien Sie dabei vorsichtig, denn das schwächt Ihren Schutz – es sei denn, Sie setzen Skript-Hashes oder Nonces für zusätzliche Validierung ein.

Für Microsoft-Profis gilt: Achten Sie darauf, wie Cloud-Dienste Abhängigkeiten einbinden. Komplexe Unternehmensanwendungen laden Ressourcen oft dynamisch, nutzen Service Worker oder binden Drittanbieter ein. Ihre Richtlinie muss ein Gleichgewicht finden zwischen Strenge (für die Sicherheit) und ausreichender Flexibilität, damit die Anwendung funktioniert. Wenn Sie die Grundlagen von Anfang an richtig umsetzen, verläuft das Testen später deutlich reibungsloser.

Best Practices für den Wechsel vom Report-Only- zum Enforced-Modus

Der klügste Weg mit CSP besteht darin, im Report-Only-Modus zu starten, Daten zu sammeln und die Durchsetzung erst danach zu aktivieren. Betrachten Sie die CSP-Einführung nicht als einmalige Checkliste. Gehen Sie stattdessen phasenweise vor: Überwachen, nachjustieren und Richtlinien schrittweise verschärfen, damit weder Endbenutzer noch geschäftskritische Abläufe beeinträchtigt werden.

Beginnen Sie mit einer breit angelegten, aber vernünftigen Richtlinie im Nur-Berichtsmodus. Sammeln Sie die Verstoßmeldungen und aggregieren Sie sie möglichst mithilfe von Dashboards oder Analysetools, um wiederkehrende Verursacher sichtbar zu machen. So filtern Sie das Grundrauschen heraus, erkennen falsch positive Treffer und konzentrieren sich auf die tatsächlichen Risiken. Wenn Sie viele routinemäßige oder redundante Meldungen finden (was häufig vorkommt), passen Sie Ihre Log-Analyse an oder richten Filter per Skript nach User-Agent oder Ressourcentyp ein.

Sobald die Zahl der Verstöße sinkt und die meisten Probleme behoben sind, erzwingen Sie die Regeln schrittweise und behalten dabei neue Fehlfunktionen im Blick. Nehmen Sie zuerst die Bereiche mit hohem Risiko und geringem Datenverkehr in den erzwungenen Modus und überwachen Sie sie. Läuft alles reibungslos, weiten Sie das Vorgehen auf das restliche Projekt aus. Dokumentieren Sie Änderungen und holen Sie während des gesamten Prozesses Feedback von Entwicklern und Stakeholdern ein – besonders bei komplexen Microsoft 365- oder Azure-Apps, in denen Ebenen des bedingten Zugriffs zusätzliche Herausforderungen mit sich bringen. Für ergänzende Strategien und Rollout-Pläne lohnt sich ein Blick auf diesen Leitfaden zu Vertrauensproblemen bei Conditional Access und diese Episode zur Identitätssicherheit.

Unterschätzen Sie das Testen nie. Verwenden Sie die Entwicklertools des Browsers, CSP-Statusprüfer und sogar automatisierte CI/CD-Scans, um sicherzustellen, dass Ihre Richtlinien wie erwartet funktionieren. Das Ziel? Eine abgesicherte, konforme und widerstandsfähige Anwendung, die durch eine Richtlinie geschützt wird, die sich im Praxisbetrieb bewährt hat – und nicht auf frommen Wünschen beruht.

Praxisbeispiele für CSP im Nur-Berichtsmodus und im erzwungenen Modus

Nichts macht CSP greifbarer als konkrete Beispiele. Im Nur-Berichtsmodus könnten Sie einen Header wie diesen verwenden: Content-Security-Policy-Report-Only: default-src 'self'; report-uri https://csp-report.example.com. Diese Konfiguration protokolliert jeden Verstoß, lässt Ihre Nutzer aber unbehelligt. Das macht sie ideal, um im Produktivbetrieb ohne Risiko zu testen.

Im Vergleich dazu eine erzwungene Richtlinie: Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com; img-src 'self'; report-uri https://csp-report.example.com. Jetzt blockiert der Browser aktiv jedes Skript und jedes Bild, das nicht den Regeln entspricht, und schützt Ihre Nutzer sofort vor nicht freigegebenen Inhalten.

In der Praxis beginnen Organisationen im Nur-Berichtsmodus, um herauszufinden, welche Anbieter, Skripte oder Geschäftsfunktionen unter einem Mimic-Lockdown ausfallen würden. Ein Behördenportal könnte beispielsweise veraltete Skripte oder ein CDN für Marketing-Analysen entdecken, die wiederholt Verstöße auslösen. Sie passen die Richtlinie an, setzen vertrauenswürdige Anbieter auf die Positivliste und erzwingen die fertige Richtlinie anschließend schrittweise, um Störungen möglichst gering zu halten.

Der Wechsel vom Nur-Berichtsmodus in den erzwungenen Modus kann versteckte Stolpersteine offenlegen – besonders bei Drittanbieter-Skripten oder dynamischen Inhalten. Teams stoßen häufig auf „Phantom“-Verstöße, die nur in bestimmten Browsern oder unter bestimmten Bedingungen auftreten. Anhand der Live-Daten aus der Berichtsphase passen sie die Richtlinie so lange an, bis die Durchsetzung nicht nur sicher, sondern für alle Beteiligten auch stabil ist.

Zusammenfassung der wesentlichen Unterschiede zwischen Nur-Berichtsmodus und erzwungenem Modus

Verhalten: Der Nur-Berichtsmodus meldet ausschließlich Richtlinienverstöße – es wird nichts blockiert. Der erzwungene Modus blockiert alles, was gegen Ihre CSP-Richtlinie verstößt.
Zweck: Der Nur-Berichtsmodus ermöglicht das Testen und Feinjustieren von Richtlinien ohne Risiko für Nutzer. Der erzwungene Modus dient dem tatsächlichen Schutz und setzt Sicherheitsregeln wirksam durch.
Auswirkung auf Nutzer: Der Nur-Berichtsmodus ist unsichtbar – Nutzer bemerken ihn nie. Der erzwungene Modus kann Funktionen oder Inhalte beeinträchtigen, wenn Sie Ihre Regeln nicht vorab getestet haben.
Anwendungsfälle: Der Nur-Berichtsmodus eignet sich ideal für schrittweise Rollouts, Risikoanalysen und Kompatibilitätsprüfungen für Altsysteme. Der erzwungene Modus ist der letzte Schritt zu robuster, konformer Sicherheit.
Compliance & Risiko: Der Nur-Berichtsmodus unterstützt Monitoring und Dokumentation bei Audits, während der erzwungene Modus Sicherheitsverletzungen in Echtzeit direkt verhindert.