Reporting API: Browserberichte sicher empfangen

Was Reporting leistet

Die Reporting API beschreibt einen gemeinsamen Weg für bestimmte Browserberichte. Sie arbeitet im Hintergrund und nach dem Best-Effort-Prinzip: Meldungen können verzögert, zusammengefasst oder verworfen werden. Sie ist kein zuverlässiger Nachrichtenkanal. Ein fehlender Bericht bedeutet deshalb nicht, dass kein Fehler oder Angriff stattgefunden hat. Reporting-Entwurf, § 1.1

Die Erzeugung eines Berichts und das Erzwingen einer Schutzregel sind getrennt. Eine durchgesetzte Content Security Policy kann eine Ressource blockieren und zusätzlich eine Meldung erzeugen. Eine Content-Security-Policy-Report-Only meldet mögliche Verstöße, setzt diese Richtlinie aber nicht durch. Umgekehrt kann eine wirksame Schutzregel bestehen, obwohl der Bericht nicht ankommt. Die fachlichen Schutzregeln stehen im CSP-Ratgeber und im Artikel zu COOP, COEP und CORP.

Berichtstyp und Unterstützung zusammen betrachten

Nicht jeder Browser erzeugt jeden Typ. Auch eine JavaScript-Schnittstelle wie ReportingObserver beobachtet nur die dafür freigegebenen Berichtstypen. Ein dort sichtbarer Eintrag ist kein Empfangsnachweis am Server. Für CSP lässt sich ein lokaler Verstoß außerdem über das Ereignis securitypolicyviolation beobachten. Das hilft bei der Fehlersuche, ersetzt aber die Prüfung der Zustellung nicht.

Drei ähnlich benannte Bausteine unterscheiden

Die aktuelle Reporting-Spezifikation ist ein W3C-Entwurf, kein IETF-RFC und keine abgeschlossene W3C Recommendation. Ihr Reporting-Endpoints ersetzt nicht automatisch jede Verwendung von Report-To: NEL gehört nicht zum dokumentzentrierten v1-Weg der dokumentierten Chromium-Implementierung. Ein pauschales „immer beide Header setzen“ ist daher ebenso unpassend wie „Report-To überall sofort entfernen“. Entscheidend sind die tatsächlich benötigten Berichtstypen und Zielbrowser. Reporting-Entwurf, Chrome-Migrationshinweise

Mit einer begrenzten CSP-Probe beginnen

Dieses Beispiel beschreibt eine Testseite über HTTPS. Die Platzhalterdomain muss durch einen von Ihnen kontrollierten und eingerichteten Empfänger ersetzt werden. Die Bildrichtlinie ist bewusst eng und kein vollständiges CSP-Konzept:

Reporting-Endpoints: csp="https://reports.example/csp"
Content-Security-Policy-Report-Only: img-src 'self'; report-to csp; report-uri https://reports.example/csp-legacy

Der Name csp muss genau zusammenpassen. Die doppelt gesetzten Anführungszeichen um die Endpunkt-URL gehören zur Header-Syntax. Die Policy meldet auf dieser Testseite ein Bild von einer anderen Origin, ohne es durch diese Report-Only-Regel zu blockieren. Vorhandene andere Schutzrichtlinien gelten weiterhin.

report-uri dient hier der Kompatibilität mit Browsern, die den neueren CSP-Meldeweg nicht unterstützen. Ein Browser, der report-to unterstützt, ignoriert die daneben stehende report-uri-Direktive. Sie ist deshalb kein automatischer Ersatz bei einem falsch benannten oder ausgefallenen report-to-Empfänger. Die beiden Routen müssen außerdem unterschiedliche Nachrichtenformate annehmen: moderne Berichte als Array mit application/reports+json, ältere CSP-Berichte als Objekt mit application/csp-report.

Konfigurieren Sie die Header an den tatsächlichen Dokumentantworten. Ein Eintrag nur auf einer Weiterleitung oder einer beliebigen Ressourcenantwort genügt nicht für sämtliche nachfolgenden Seiten. Prüfen Sie auch, ob CDN, Proxy oder Anwendung die Konfiguration überschreiben.

NEL gezielt und mit kurzer Erprobungsphase einsetzen

NEL braucht eine zuvor vom Browser angenommene Policy. Ein allererster fehlgeschlagener Aufruf kann keine Konfiguration aus einer nie empfangenen Antwort lernen. Zudem können Fehlerberichte denselben Netzausfall wie die Website erleben. Für unabhängige Verfügbarkeitsprüfungen brauchen Sie ergänzende Messungen.

Ein begrenztes Konfigurationsbeispiel für den dokumentierten Chromium-Weg:

Report-To: {"group":"network","max_age":86400,"endpoints":[{"url":"https://reports.example/network"}]}
NEL: {"report_to":"network","max_age":86400,"success_fraction":0,"failure_fraction":1}

Die Laufzeit von einem Tag ist eine bewusste Beispielwahl für die Einführung, keine allgemeine Norm. Die Gruppe muss übereinstimmen; ihre Empfängerkonfiguration darf nicht früher unbrauchbar werden als die NEL-Policy. success_fraction: 0 wählt keine erfolgreichen Anfragen aus. failure_fraction: 1 wählt grundsätzlich alle passenden Fehler aus, garantiert aber keine vollständige Zustellung. Bei viel Verkehr sind Volumen, Stichprobe und Aufbewahrung gemeinsam zu planen.

include_subdomains fehlt absichtlich: Subdomains sollen erst nach einer bewussten Entscheidung einbezogen werden. Eine solche Ausweitung verlangt passende Konfiguration auch auf der Empfängerseite und die Zuständigkeit für die betroffenen Anwendungen. Zum Entfernen einer gespeicherten NEL-Policy dient NEL: {"max_age":0} auf der betreffenden Origin; eine gesondert gespeicherte Report-To-Gruppe hat ihren eigenen Lebenszyklus. Nur den Header künftig wegzulassen entfernt bereits gespeicherte Policies nicht sofort.

NEL-Fehlertypen sind Diagnosedaten. Beispielsweise kann dns.address_changed bei mehreren Serveradressen durch eine datenschutzbedingte Reduktion der Berichtsinformation entstehen. Daraus allein lässt sich weder DNS-Manipulation noch ein Angriff ableiten. NEL-Entwurf, §§ 4–7

Browserstand: Konfiguration und Berichtstyp getrennt prüfen

Stand der ausgewerteten Browser Compatibility Data am 27. September 2026:

Diese Angaben beschreiben die jeweilige Funktion. Sie beweisen weder alle Berichtstypen noch den Betrieb eines bestimmten Endpunkts. Gerade Firefox zeigt, warum das bloße Erkennen von Reporting-Endpoints nicht mit CSP-Berichten gleichgesetzt werden darf. Für Ihre Nutzer zählen die tatsächlich eingesetzten Versionen, WebViews und Unternehmensrichtlinien. Andere Chromium-Produkte nicht allein anhand des Produktnamens als vollständig geprüft behandeln. BCD: Reporting-Endpoints, CSP, NEL

Einen Empfänger betreiben, der Berichte sicher verarbeitet

Der Endpunkt muss eingehende Daten als unvertrauenswürdig behandeln: Auch fremde Clients können erfundene Berichte senden. Begrenzen Sie Nutzlast, Anzahl, Verarbeitungskosten und gespeicherte Felder. Prüfen Sie Schema und Berichtstyp, behandeln Sie unbekannte Felder robust und zeigen Sie Zeichenketten nicht ungefiltert als HTML an. Ein funktionierender POST ohne Anmeldung ist kein Echtheitsnachweis für den Inhalt.

Moderne Berichte kommen als JSON-Array, möglicherweise mit mehreren Einträgen. Das Feld age beschreibt das Alter des Berichts in Millisekunden, keinen absoluten Zeitstempel. Antworten im Bereich 200–299 bestätigen die Annahme auf Transportebene; 410 Gone hat im Reporting-Entwurf die besondere Bedeutung, den Endpunkt zu entfernen. Ein erfolgreich quittierter Eingang muss in Ihrer Anwendung trotzdem noch zuverlässig verarbeitet werden.

Bei einem Empfänger auf anderer Origin muss auch der CORS-Preflight funktionieren. Der moderne Versandweg verwendet den Credentials-Modus same-origin: gleich-originige Empfänger können Cookies erhalten, fremde Origins erhalten über diesen Weg keine Credentials. CORS ist keine Authentifizierung des meldenden Browsers. Prüfen Sie Antwortheader und erlaubte Methoden/Header am tatsächlich verwendeten Collector. Reporting-Entwurf, § 3.5, Chrome-Betriebshinweise

Berichte können Dokument-URLs, Ressourcenadressen, Referrer, Browserangaben und je nach Typ weitere Details enthalten. Die Entfernung von Benutzername, Passwort und Fragment aus einer URL macht sie nicht anonym: Pfade und Suchparameter können weiterhin vertrauliche Daten enthalten. CSP-Samples und zusätzliche NEL-Headerfelder erhöhen den möglichen Inhalt nochmals. Vermeiden Sie solche Daten schon in URLs und nehmen Sie nur benötigte Felder auf. Legen Sie Zweck, Zugriff, Aufbewahrung, Löschung und gegebenenfalls den Umgang mit einem Dienstleister fest. Eine Frist wie „30 Tage“ ist keine allgemeine gesetzliche Vorgabe für Browserberichte.

Erzeugung, Versand und Auswertung getrennt testen

1. Eine isolierte Testseite mit bekannter Policy, benanntem Endpunkt und bewusst ausgelöstem Verstoß bereitstellen.
2. In Browserwerkzeugen beziehungsweise passenden Ereignissen kontrollieren, ob die Policy verarbeitet wurde und der Bericht entsteht.
3. Am Empfänger prüfen, ob ein echter Browserbericht mit richtigem Typ und Bezug zur Testseite eintrifft. Wartezeit, Browser und Versionsstand festhalten.
4. Einen falschen Endpunktnamen und einen nicht erreichbaren Empfänger als Gegenfälle prüfen. Ausbleibende Berichte nicht als erfolgreiche Schutzprüfung zählen.
5. Empfangene Meldungen vom Transport bis zur Auswertung verfolgen. Stichproben, Rate-Limits und Filter können die sichtbare Zahl weiter verändern.

Ein selbst gesendeter curl-POST prüft nur den Empfänger. Eine frühere lokale HTTPS-Probe mit Chromium 147 beobachtete CSP-Verstöße und moderne Berichte in der Browserwarteschlange, aber innerhalb von 90 Sekunden nur einen empfangenen Legacy-Bericht. In einer ergänzenden lokalen Diagnose am 28. September 2026 mit Chrome 153.0.8010.54 trafen dagegen echte moderne CSP-Berichte als application/reports+json am eigenen Collector ein – sowohl in einem isolierten normalen Profil als auch in einem privaten Kontext. Bei absichtlich falschem Zielnamen traf im 35-sekündigen Beobachtungsfenster kein entsprechender Bericht und kein Legacy-Ersatz ein.

Die ergänzende Probe verwendete die von Chrome dokumentierte Option --short-reporting-delay. Sie belegt den Empfang in diesem lokalen HTTPS-Aufbau mit gleich-originigem Collector, keinen normalen Zustellrhythmus und keinen geprüften Betrieb eines fremden Empfängers. Die genaue Ursache des älteren Ausbleibens ist damit nicht isoliert; insbesondere erklärt die Profilart allein den Unterschied nicht. Für Ihre eigene Probe Berichtstyp, Browserfassung, Profil und Empfänger festhalten und die tatsächlichen Eingänge prüfen. Chrome: Reporting-Konfiguration diagnostizieren

Was der Wolf-Agents-Befund aussagt

Im geprüften Produktstand berücksichtigt der Web Security Check sichtbare Werte von Report-To, NEL und Reporting-Endpoints bei der Bewertung. Er führt keinen Browser aus, erzeugt keinen passenden Richtlinienverstoß und überprüft keinen Collector. Selbst ein syntaktisch unbrauchbarer, aber nicht leerer Wert kann in dieser Auswertung als vorhandener Header zählen. Ein positiver Befund ist daher ein Hinweis auf Konfiguration, kein Nachweis funktionierender Überwachung. Ein fehlender Header ist umgekehrt keine Sicherheitslücke für sich.