GitHub-Pages-Tools

Kostenlose Reporting API Header Generator

Generieren Sie Report-To- und Reporting-Endpoints-HTTP-Header fur Browser-Berichte, CSP-Verstoße und Network Error Logging.

Tool wird geladen...

Was ist Reporting API Header Generator?

Die Reporting API ist eine Browser-API, die Berichte über verschiedene Probleme sammelt — CSP-Verstöße, Network Error Logging-Ereignisse, Veraltungswarnungen, Browser-Interventionen und Absturzberichte — und an einen konfigurierbaren Endpunkt sendet. Sie verwendet HTTP-Header (Report-To oder Reporting-Endpoints), um dem Browser mitzuteilen, wohin Berichte gesendet werden sollen. Der Reporting-Endpoints-Header ist der neuere Standard und ersetzt den älteren Report-To-Header. Browser bündeln Berichte und senden sie periodisch, um den Netzwerk-Overhead zu minimieren.

Kurze Antwort

Generieren Sie Report-To- und Reporting-Endpoints-HTTP-Header für Nginx und Apache. Wählen Sie zwischen der älteren Report-To- und der neueren Reporting-Endpoints-Syntax. Konfigurieren Sie optional CSP report-uri/report-to-Direktiven und Network Error Logging (NEL)-Header. Die Reporting API (Chrome 69+, Safari 16.4+, Edge 79+) sammelt CSP-Verstöße, NEL-Ereignisse, Veraltungswarnungen, Browser-Interventionen und Absturzberichte an einem zentralen Endpunkt.

Last updated: 2026-05-31

Einschränkungen

Die Unterstützung des Reporting-Endpoints-Headers variiert je nach Browser. Chrome unterstützt ihn ab Version 69+, Safari ab 16.4+ und Edge ab 79+. Die Firefox-Unterstützung für Reporting-Endpoints ist begrenzt. Der ältere Report-To-Header wird für eine breitere Browser-Kompatibilität noch benötigt.
Berichte werden nicht garantiert zugestellt. Browser bündeln Berichte und senden sie nach ihrem eigenen Zeitplan. Wenn der Benutzer den Tab schließt, bevor der Batch gesendet wird, können Berichte verloren gehen. Verlassen Sie sich nicht auf die Reporting API für kritisches Monitoring — verwenden Sie sie als ergänzende Datenquelle neben serverseitiger Protokollierung.
Der Reporting-Endpunkt muss über HTTPS erreichbar sein. Browser weigern sich, Berichte an HTTP-Endpunkte für Sites zu senden, die über HTTPS ausgeliefert werden. GitHub Pages-Sites, die einen benutzerdefinierten Reporting-Collector verwenden, müssen sicherstellen, dass der Collector ein gültiges TLS-Zertifikat hat.

Sources:MDN Web Docs · W3C Specifications · jquery.app on GitHub

So nutzt du dieses Tool

Wählen Sie die Header-Version: älteres Report-To für breitere Kompatibilität oder den neueren Reporting-Endpoints-Standard-Header. Reporting-Endpoints ist einfacher, hat aber neuere Browser-Unterstützung.
Wählen Sie Ihren Servertyp (Nginx oder Apache) und kopieren Sie die generierte Header-Konfiguration in Ihre Serverkonfiguration, Ihren Virtual-Host-Block oder Ihre .htaccess-Datei.
Aktivieren Sie optional die CSP-Berichterstattung durch Auswahl eines CSP-Direktiventyps (report-uri, report-to oder beide). Das generierte Snippet enthält die entsprechenden CSP-Berichterstattungsdirektiven.
Konfigurieren Sie optional Network Error Logging (NEL) mit Ihrer Reporting-Endpunkt-URL, Cache-Dauer und Erfolgs-/Fehler-Samplingraten.

Wofür du es nutzen kannst

Sammeln Sie CSP-Verstoßberichte an einem zentralen Endpunkt, um Ihre Content Security Policy zu überwachen und zu verfeinern, ohne legitime Inhalte zu blockieren.
Überwachen Sie Network Error Logging-Berichte, um Netzwerkfehler, DNS-Probleme, TLS-Fehler und Konnektivitätsprobleme zu erkennen und zu diagnostizieren, die von echten Benutzern erfahren werden.
Empfangen Sie Veraltungswarnungen und Browser-Interventionsberichte, um Funktionen auf Ihrer Site zu identifizieren, die aktualisiert werden müssen, bevor Browser die Unterstützung entfernen.

Anwendungsfalle

Praxisbeispiele

Beispiel

GitHub Pages Site mit CSP-Überwachung

Eine GitHub Pages-Site setzt eine strenge Content Security Policy und möchte Verstoßberichte erhalten. Konfigurieren Sie einen Reporting-Endpoints-Header mit einem CSP-Endpunkt, fügen Sie Content-Security-Policy mit report-to: CSP-endpoint hinzu und aktivieren Sie NEL, um Netzwerkprobleme zu erkennen, die das Laden von Assets beeinträchtigen. Berichte werden per POST an einen kleinen Server-Endpunkt gesendet, der sie protokolliert und aggregiert.

Beispiel

Nginx-Reverse-Proxy mit vollständigem Reporting-Suite

Ein Produktions-Nginx-Reverse-Proxy vor einer Node.js-App konfiguriert sowohl Reporting-Endpoints- als auch Content-Security-Policy-Report-Only-Header. CSP-Verstöße, NEL-Ereignisse und Veraltungswarnungen werden alle per POST an einen einzigen Reporting-Endpunkt unter /_reports gesendet. NEL ist mit max_age 86400 und einer Fehler-Samplingrate von 0.1 konfiguriert, um repräsentative Netzwerkfehlerdaten zu sammeln, ohne den Endpunkt zu überlasten.

Haufige Fehler

Beide Header Report-To und Reporting-Endpoints gleichzeitig zu verwenden — Browser können doppelte Berichte senden, wenn beide Header vorhanden sind. Migrieren Sie von Report-To zu Reporting-Endpoints, indem Sie den alten Header entfernen, sobald Reporting-Endpoints konfiguriert und getestet ist.
Einen CSP report-uri ohne einen entsprechenden Reporting-Endpunkt zu setzen — report-uri sendet Berichte an eine beliebige URL über GET-Anfragen mit Query-Parametern, was die URL-Längenbegrenzung für große Verstoßberichte überschreiten kann. Paaren Sie report-uri oder report-to immer mit einem ordnungsgemäß konfigurierten empfangenden Endpunkt, der POST-Anfragen verarbeiten kann.
CORS auf dem Reporting-Endpunkt nicht zu konfigurieren — Berichte werden von dem Ursprung gesendet, von dem die Header ausgeliefert werden. Wenn sich Ihr Reporting-Endpunkt auf einem anderen Ursprung befindet, muss er Cross-Origin-POST-Anfragen akzeptieren. Dies ist besonders wichtig für Sites, die auf GitHub Pages gehostet werden und einen externen Reporting-Collector verwenden.

Überprüfung

Stellen Sie die Header auf Ihrem Server bereit und überprüfen Sie deren Vorhandensein mit curl -I oder dem DevTools-Netzwerk-Panel. Prüfen Sie, ob Reporting-Endpoints (oder Report-To) in den Antwort-Headern für HTML-Seiten erscheint.
Lösen Sie einen CSP-Verstoß aus, indem Sie ein Inline-Skript auf einer CSP-geschützten Seite laden, und überprüfen Sie dann Ihren Reporting-Endpunkt auf den empfangenen Verstoßbericht. Der Bericht sollte die blockierte URI, die verletzte Direktive und die Quelldatei mit Zeilennummer enthalten.

FAQ

Fragen zu Reporting API Header Generator

Was ist der Unterschied zwischen Report-To- und Reporting-Endpoints-Headern?

Report-To ist das ältere Header-Format, das eine JSON-Konfiguration mit Endpunktgruppen und Prioritäten verwendet. Reporting-Endpoints ist das neuere, einfachere Format, das Endpunktnamen direkt URLs in einer kommagetrennten Liste zuordnet. Reporting-Endpoints wird für neue Bereitstellungen bevorzugt, da es die Headerkomplexität reduziert. Chrome unterstützt beide, während Safari und Firefox Reporting-Endpoints unterstützen. Für maximale Kompatibilität fügen einige Sites beide während der Migration ein, obwohl dies zu doppelten Berichtszustellungen führen kann.

Wie funktioniert Network Error Logging (NEL) mit der Reporting API?

NEL wird über einen NEL-HTTP-Header konfiguriert, der eine Reporting-Endpunktgruppe, eine max_age für die Richtlinie und optionale Samplingraten angibt. Wenn der Browser eine Netzwerkanfrage versucht und auf einen Fehler stößt (DNS-Fehler, TLS-Fehler, Timeout usw.), generiert er einen NEL-Bericht und sendet ihn an den konfigurierten Reporting-Endpunkt. Der Browser generiert nur Berichte für den Ursprung, der den NEL-Header ausgeliefert hat. NEL erfordert keine serverseitige Instrumentierung — die Berichte kommen direkt vom Netzwerk-Stack des Browsers.

Welche Arten von Berichten kann die Reporting API sammeln?

Die Reporting API kann CSP-Verstoßberichte (wenn eine Ressource Ihre Content Security Policy verletzt), Network Error Logging-Berichte (Netzwerkfehler wie DNS-Fehler, TCP-Timeouts, TLS-Fehler), Veraltungsberichte (wenn Ihre Site eine veraltete Browser-API verwendet), Interventionsberichte (wenn der Browser ein Verhalten auf Ihrer Site blockiert oder modifiziert) und Absturzberichte (wenn eine Seite abstürzt) sammeln. Jeder Berichtstyp wird über seinen eigenen HTTP-Header oder Meta-Tag konfiguriert, aber alle können an denselben Reporting-Endpunkt gesendet werden.

Verwandte Tools