GitHub Pages tools

Gratis Reporting API Header Generator

Genereer Report-To en Reporting-Endpoints HTTP-headers voor browserrapporten, CSP-schendingen en Network Error Logging.

Tool laden...

Wat is Reporting API Header Generator?

The Reporting API is a browser API that collects reports about various issues — CSP violations, Network Error Logging events, deprecation warnings, browser interventions, and crash reports — and sends them to a configurable endpoint. It uses HTTP headers (Report-To or Reporting-Endpoints) to tell the browser where to send reports. The Reporting-Endpoints header is the newer standard, replacing the legacy Report-To header. Browsers batch reports and send them periodically to minimize network overhead.

Snel antwoord

Generate Report-To and Reporting-Endpoints HTTP headers for Nginx and Apache. Choose between legacy Report-To and newer Reporting-Endpoints syntax. Optionally configure CSP report-uri/report-to directives and Network Error Logging (NEL) headers. The Reporting API (Chrome 69+, Safari 16.4+, Edge 79+) collects CSP violations, NEL events, deprecation warnings, browser interventions, and crash reports at a central endpoint.

Beperkingen

Reporting-Endpoints header support varies by browser. Chrome supports it from version 69+, Safari from 16.4+, and Edge from 79+. Firefox support for Reporting-Endpoints is limited. The legacy Report-To header is still needed for broader browser compatibility.
Reports are not guaranteed to be delivered. Browsers batch reports and send them on their own schedule. If the user closes the tab before the batch is sent, reports may be lost. Do not rely on the Reporting API for critical monitoring — use it as a supplemental data source alongside server-side logging.
The reporting endpoint must be accessible via HTTPS. Browsers refuse to send reports to HTTP endpoints for sites served over HTTPS. GitHub Pages sites using a custom reporting collector must ensure the collector has a valid TLS certificate.

Zo gebruik je deze tool

Choose the header version: legacy Report-To for broader compatibility or the newer Reporting-Endpoints standard header. Reporting-Endpoints is simpler but has newer browser support.
Select your server type (Nginx or Apache) and copy the generated header configuration into your server config, virtual host block, or .htaccess file.
Optionally enable CSP Reporting by selecting a CSP directive type (report-uri, report-to, or both). The generated snippet includes the appropriate CSP reporting directives.
Optionally configure Network Error Logging (NEL) with your reporting endpoint URL, cache duration, and success/failure sampling rates.

Waarvoor je het kunt gebruiken

Collect CSP violation reports at a central endpoint to monitor and fine-tune your Content Security Policy without blocking legitimate content.
Monitor Network Error Logging reports to detect and diagnose network failures, DNS issues, TLS errors, and connectivity problems experienced by real users.
Receive deprecation warnings and browser intervention reports to identify features on your site that need updating before browsers remove support.

Gebruik

Praktische voorbeelden

Voorbeeld

GitHub Pages site with CSP monitoring

A GitHub Pages site sets a strict Content Security Policy and wants to receive violation reports. Configure a Reporting-Endpoints header with a CSP-endpoint, add Content-Security-Policy with report-to: CSP-endpoint, and enable NEL to detect any network issues affecting asset loading. Reports POST to a small server endpoint that logs and aggregates them.

Voorbeeld

Nginx reverse proxy with full reporting suite

A production Nginx reverse proxy in front of a Node.js app configures both Reporting-Endpoints and Content-Security-Policy-Report-Only headers. CSP violations, NEL events, and deprecation warnings all POST to a single reporting endpoint at /_reports. NEL is configured with max_age 86400 and a 0.1 failure sampling rate to collect representative network error data without overwhelming the endpoint.

Veelgemaakte fouten

Using both Report-To and Reporting-Endpoints headers simultaneously — browsers may send duplicate reports if both headers are present. Migrate from Report-To to Reporting-Endpoints by removing the old header once Reporting-Endpoints is configured and tested.
Setting a CSP report-uri without a corresponding reporting endpoint — report-uri sends reports to an arbitrary URL via GET requests with query parameters, which may exceed URL length limits for large violation reports. Always pair report-uri or report-to with a properly configured receiving endpoint that can handle POST requests.
Forgetting to configure CORS on the reporting endpoint — reports are sent from the origin where the headers are served, but if your reporting endpoint is on a different origin, it needs to accept cross-origin POST requests. This is especially important for sites hosted on GitHub Pages using an external reporting collector.

Verificatie

Deploy the headers to your server and verify they are present using curl -I or browser DevTools Network panel. Check that Reporting-Endpoints (or Report-To) appears in the response headers for HTML pages.
Trigger a CSP violation by loading an inline script on a CSP-protected page, then check your reporting endpoint for the received violation report. The report should include the blocked URI, violated directive, and source file with line number.

FAQ

Vragen over Reporting API Header Generator

What is the difference between Report-To and Reporting-Endpoints headers?

Report-To is the legacy header format that uses a JSON configuration with endpoint groups and priorities. Reporting-Endpoints is the newer, simpler format that maps endpoint names directly to URLs in a comma-separated list. Reporting-Endpoints is preferred for new deployments as it reduces header complexity. Chrome supports both, while Safari and Firefox support Reporting-Endpoints. For maximum compatibility, some sites include both during migration, though this can cause duplicate report delivery.

How does Network Error Logging (NEL) work with the Reporting API?

NEL is configured via a NEL HTTP header that specifies a reporting endpoint group, a max_age for the policy, and optional sampling rates. When the browser attempts a network request and encounters an error (DNS failure, TLS error, timeout, etc.), it generates a NEL report and sends it to the configured reporting endpoint. The browser only generates reports for the origin that served the NEL header. NEL does not require any server-side instrumentation — the reports come directly from the browser's network stack.

What types of reports can the Reporting API collect?

The Reporting API can collect CSP violation reports (when a resource violates your Content Security Policy), Network Error Logging reports (network errors like DNS failures, TCP timeouts, TLS errors), deprecation reports (when your site uses a deprecated browser API), intervention reports (when the browser blocks or modifies behavior on your site), and crash reports (when a page crashes). Each report type is configured via its own HTTP header or meta tag, but all can send to the same reporting endpoint.

Gerelateerde tools