Warum sich Report-Only von Enforced bei Content Security Policy unterscheidet

Von Mirko Peters · 2026-04-23

Wenn Ihnen Websicherheit wirklich wichtig ist, ist das Verständnis des Unterschieds zwischen den Modi ‚Report-Only‘ und ‚Enforced‘ in der Content Security Policy (CSP) …

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

Wenn Ihnen Websicherheit wirklich wichtig ist, ist das Verständnis des Unterschieds zwischen den Modi „Report-Only“ und „Enforced“ in der Content Security Policy (CSP) mehr als nur ein Detail – es entscheidet über alles. Der Report-Only-Modus zeigt Ihnen, was durch Ihre Richtlinie blockiert würde, ohne tatsächlich etwas zu stoppen. Ihre Website wird damit zu einer Art Testumgebung für Sicherheit. Der Enforced-Modus hingegen lässt nichts durchgehen: Er blockiert alles, was Ihrer Richtlinie widerspricht, und sichert Ihre Website in Echtzeit ab.

Dieser Artikel erklärt, warum diese Modi wichtig sind, welche Auswirkungen sie auf Browser und Benutzererfahrung haben und wie Sie von einfachem Monitoring zu echtem Schutz gelangen. Er richtet sich gezielt an Microsoft-affine Sicherheitsexperten und Entwickler, die ihre CSP-Konfiguration richtig aufsetzen möchten. Behandelt werden Begriffsdefinitionen, praktische Techniken und Best Practices für einen sicheren Rollout sowie eine effiziente Compliance.

Die CSP-Modi und ihre Auswirkungen verstehen

Bevor Sie CSP-Header setzen, 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 schützen oder lediglich beobachten. Ihre Wahl beeinflusst unmittelbar das Risikoniveau Ihrer Website, die Prüfbarkeit und den reibungslosen Ablauf des Rollouts, insbesondere in großen Microsoft-Umgebungen oder Multi-Cloud-Szenarien.

Die CSP-Modi wurden entwickelt, um Webteams Flexibilität zu geben. Der Report-Only-Modus ist der sanfte Einstieg: Sie überwachen Probleme, ohne befürchten zu müssen, Benutzern versehentlich etwas zu beeinträchtigen. Er unterstützt die Risikobewertung, hilft dabei, Lücken in der Richtlinie aufzuspüren, und kann Altcode oder unerwartetes Verhalten von Drittanbieter-Skripten sichtbar machen – und das alles, während Ihre Anwendung vollständig betriebsbereit bleibt.

Der Enforced-Modus ist der eigentliche Ernstfall: Er weist den Browser an, Ihre Vorgaben tatsächlich umzusetzen. Entspricht ein Inhalt nicht Ihrer Richtlinie, wird er blockiert. Das reduziert die Angriffsfläche sofort, etwa bei Cross-Site-Scripting oder schädlichen Drittanbieter-Skripten. Allerdings kann es Ihre Anwendung unterbrechen, wenn Richtlinien fehlerhaft oder unvollständig sind und Sie Tests und Einführung nicht sorgfältig durchführen.

Die Idee hinter beiden CSP-Modi ist einfach: Entwickler und Sicherheitsteams sollen ihre Regeln unter realen Bedingungen verfeinern, bevor sie den Schalter umlegen. Betrachten Sie es als Stützräder für die Sicherheit Ihrer Anwendung – mit einer Ziellinie, an der Sie zur vollständigen Durchsetzung wechseln. Als Nächstes zeigen wir Ihnen genau, wie Report-Only Ihnen dieses Feedback aus dem Betrieb 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, zuzuschauen, bevor Sie selbst aufs Spielfeld 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 sie lediglich zu melden. So erhalten Sie einen kontinuierlichen Strom von Verstoßberichten an den von Ihnen angegebenen Endpunkt und eine vollständige Übersicht darüber, was bei Durchsetzung der Richtlinie blockiert würde.

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

Dieser Modus ist für Risikobewertungen und sicheres Testen unbezahlbar. Sie können neue Regeln über eine Reihe von Webanwendungen ausrollen, beobachten, was ausgelöst wird, und die Richtlinie auf Basis echter Daten anpassen statt auf Grundlage von Vermutungen. Betreiben Sie Altsysteme oder geschäftskritische Workflows, riskieren Sie keine Ausfälle und keinen Support-Aufwand, weil Sie zu schnell vorgehen.

Report-Only unterstützt außerdem schrittweise Rollouts. Starten Sie offen, prüfen Sie, was angepasst werden muss, und gehen Sie Schritt für Schritt zu einer strengeren Absicherung über. So lassen sich Probleme mit Drittanbieter-Skripten, CDN-Inhalten oder verschleiertem JavaScript finden, die sonst erst bei der Durchsetzung einen gravierenden Ausfall verursachen würden. Außerdem ist der Modus ein Compliance-Gewinn: Sie können belegen, dass Sie aktiv überwachen, was bei Audits hilft, wenn Ihre Organisation nachweisen muss, dass sie die gebotene Sorgfalt walten lässt.

Wie der Enforced-Modus die Sicherheit erhöht

Der Enforced-Modus bedeutet, dass Ihre CSP-Richtlinie keine bloße Empfehlung mehr ist, sondern zur verbindlichen Regel wird. Wenn Sie den Header Content-Security-Policy verwenden, blockieren Browser tatsächlich alle Inhalte, die nicht zu Ihren Direktiven passen. Es gibt dann keine bloßen Warnungen, sondern konkrete Maßnahmen.

Dieser Modus härtet Ihre Web-App deutlich gegen Angriffe wie XSS und das Einschleusen unautorisierter Skripte. Seien Sie aber vorsichtig: Ist Ihre Richtlinie noch nicht ausgereift, können Sie versehentlich notwendige Ressourcen blockieren und die Funktionalität der Website beeinträchtigen. Der kluge Weg führt deshalb zuerst über den Report-Only-Modus zum Testen. Letztlich macht der Enforced-Modus aus einer theoretischen Richtlinie einen praktischen Schutz und gilt damit als Goldstandard für starke Websicherheit.

Berichterstattung mit Report-URI und Report-To-Endpunkten einrichten

Die Einrichtung der Berichterstattung verleiht Ihrer CSP-Richtlinie echte Wirkkraft und zusätzlich ein wachsames Auge. Mit CSP können Sie einen oder mehrere Endpunkte festlegen (über report-uri oder report-to), an die Browser Verstoßberichte senden sollen. Tritt ein Verstoß auf, bündelt der Browser Details wie die blockierte Ressource und die fehlgeschlagene Richtlinie in einer JSON- oder HTTP-POST-Nachricht und übermittelt sie an Ihren Endpunkt.

Die Direktive report-uri ist die ältere Methode: Sie hinterlegen eine URL, und Browser senden 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 verschiedene Berichtstypen verarbeiten kann, und bietet eine bessere Filterkontrolle.

Beim Konfigurieren dieser Endpunkte sollten Sie diese absichern: HTTPS, Zugriffskontrollen und Überwachung auf ungewöhnliche Anstiege, 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 Berichte speichern oder weitergeben, und dabei Vorgaben wie die DSGVO und den CCPA im Blick behalten.

Der eigentliche Nutzen liegt in der Transparenz. Mit richtig konfigurierter Berichterstattung erhalten Sie einen Live-Überblick darüber, wo Ihre Richtlinie Verstöße erkennt. So können Sie nachjustieren, feinabstimmen und schließlich ohne böse Überraschungen sicher in den Enforced-Modus wechseln. Diese Überwachung ist unverzichtbar, egal ob Sie eine einzelne App oder eine weitläufige 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, besonders wenn komplexe Anwendungen und Microsoft-Cloud-Integrationen zusammenspielen. Im Kern ist eine CSP-Richtlinie eine strukturierte Liste von Direktiven, die jeweils festlegen, was Browser erlauben und was nicht. Sie übermitteln diese Richtlinien über HTTP-Header, typischerweise als Content-Security-Policy oder Content-Security-Policy-Report-Only, formatiert als Zeichenketten 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 richten sich gezielt auf Skripte und Bilder und ermöglichen es Ihnen, vertrauenswürdige Quellen streng zu kontrollieren, etwa Ihre eigenen Domains, vertrauenswürdige CDNs und vielleicht einen 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 (manchmal für Altcode erforderlich), benötigen Sie möglicherweise ‘unsafe-inline’. Seien Sie hierbei vorsichtig, denn das schwächt Ihren Schutz, es sei denn, Sie verwenden Skript-Hashes oder Nonces zur zusätzlichen Validierung.

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 deshalb ein Gleichgewicht finden: streng genug für die Sicherheit, aber flexibel genug, damit die Anwendung funktioniert. Wenn Sie die Grundlagen von Anfang an richtig setzen, verläuft das Testen später deutlich reibungsloser.

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

Der klügste Schritt bei CSP ist, 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. Behandeln Sie sie stattdessen als phasenweises Projekt, bei dem Sie überwachen, nachjustieren und Richtlinien schrittweise verschärfen, um keine Funktionen für Endnutzer oder geschäftskritische Abläufe zu beeinträchtigen.

Beginnen Sie mit einer breit angelegten, aber sinnvollen Richtlinie im Nur-Bericht-Modus. Sammeln Sie die Verstoßberichte und fassen Sie sie idealerweise mit Dashboards oder Analysetools zusammen, damit wiederkehrende Verursacher sichtbar werden. So filtern Sie das Rauschen heraus, erkennen Fehlalarme und konzentrieren sich auf echte Risiken. Wenn Sie viele routinemäßige oder redundante Berichte finden (was häufig vorkommt), passen Sie Ihre Log-Analyse an oder filtern Sie per Skript nach User-Agent oder Ressourcentyp.

Sobald die Zahl der Verstöße deutlich sinkt und die meisten Probleme behoben sind, erzwingen Sie die Regeln schrittweise und beobachten weiterhin neue Fehlerfälle. Setzen Sie zuerst Bereiche mit hohem Risiko und geringem Datenverkehr durch und überwachen Sie sie. Läuft alles reibungslos, weiten Sie die Durchsetzung auf den Rest des Projekts 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 für bedingten Zugriff zusätzliche Herausforderungen mitbringen. Für ergänzende Strategien und Rollout-Pläne lohnt sich ein Blick auf diesen Leitfaden zu Vertrauensproblemen bei bedingtem Zugriff und diese Episode zur Identitätssicherheit.

Unterschätzen Sie das Testen nie. Verwenden Sie Browser-Entwicklertools, CSP-Statusprüfer und sogar automatisierte CI/CD-Scans, um zu bestätigen, 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 realen Betrieb bewährt hat und nicht auf Wunschdenken beruht.

Praxisbeispiele für CSP im Nur-Bericht- und im Erzwungenen Modus

Nichts macht CSP greifbarer als reale Beispiele. Im Nur-Bericht-Modus 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 Benutzer jedoch unbeeinträchtigt arbeiten. Das macht sie ideal, um Tests im Produktivbetrieb ohne Risiko durchzuführen.

Im Gegensatz dazu steht 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 jede Grafik, die nicht zu den Regeln passt, und schützt Ihre Benutzer so sofort vor nicht genehmigten Inhalten.

In der Praxis beginnen Organisationen im Nur-Bericht-Modus, um herauszufinden, welche Anbieter, Skripte oder Geschäftsfunktionen bei einem geplanten Lockdown ausfallen würden. Ein Behördenportal könnte beispielsweise veraltete Skripte oder ein CDN für Marketing-Analysen entdecken, das wiederholt Verstöße auslöst. Die Teams passen die Richtlinie iterativ an, setzen vertrauenswürdige Anbieter auf die Positivliste und erzwingen die fertige Richtlinie anschließend in Stufen, um Störungen so gering wie möglich zu halten.

Der Wechsel vom Nur-Bericht-Modus zur Durchsetzung kann versteckte Stolperfallen zutage fördern, 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. Mithilfe der Livedaten aus der Berichtsphase passen sie die Richtlinie so lange an, bis die Durchsetzung nicht nur sicher, sondern für alle Beteiligten stabil ist.

Die wichtigsten Unterschiede zwischen dem Nur-Bericht- und dem erzwungenen Modus

• Verhalten: Der Nur-Bericht-Modus meldet nur Richtlinienverstöße, es wird nichts blockiert. Der erzwungene Modus blockiert alles, was gegen Ihre CSP-Richtlinie verstößt.
• Zweck: Der Nur-Bericht-Modus ermöglicht es, Richtlinien ohne Risiko für Benutzer zu testen und anzupassen. Der erzwungene Modus dient dem tatsächlichen Schutz und macht Sicherheitsregeln wirksam.
• Auswirkungen auf Benutzer: Der Nur-Bericht-Modus ist unsichtbar, Benutzer bemerken ihn nicht. Der erzwungene Modus kann Funktionen oder Inhalte stören, wenn Ihre Regeln nicht vorab getestet wurden.
• Anwendungsfälle: Der Nur-Bericht-Modus eignet sich ideal für schrittweise Einführungen, Risikoanalysen und Prüfungen der Kompatibilität mit Altsystemen. Der erzwungene Modus ist der letzte Schritt, um eine robuste, konforme Sicherheit zu erreichen.
• Compliance & Risiko: Der Nur-Bericht-Modus unterstützt Überwachung und Dokumentation bei Audits, während der erzwungene Modus Sicherheitsverletzungen in Echtzeit direkt verhindert.