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?

De Reporting API is een browser-API die rapporten verzamelt over verschillende problemen —CSP-schendingen, Network Error Logging-gebeurtenissen, verouderingswaarschuwingen, browserinterventies en crashrapporten —en deze naar een configureerbaar eindpunt stuurt. Het gebruikt HTTP-headers (Report-To of Reporting-Endpoints) om de browser te vertellen waarheen rapporten moeten worden gestuurd. De Reporting-Endpoints-header is de nieuwere standaard en vervangt de verouderde Report-To-header. Browsers batchrapporten en verzenden ze periodiek om de netwerkoverhead te minimaliseren.

Snel antwoord

Genereer Report-To en Reporting-Endpoints HTTP-headers voor Nginx en Apache. Kies tussen verouderde Report-To en nieuwere Reporting-Endpoints-syntax. Configureer optioneel CSP report-uri/report-to-richtlijnen en Network Error Logging (NEL)-headers. De Reporting API (Chrome 69+, Safari 16.4+, Edge 79+) verzamelt CSP-schendingen, NEL-gebeurtenissen, verouderingswaarschuwingen, browserinterventies en crashrapporten op een centraal eindpunt.

Last updated: 2026-05-31

Beperkingen

Ondersteuning voor Reporting-Endpoints-header varieert per browser. Chrome ondersteunt het vanaf versie 69+, Safari vanaf 16.4+ en Edge vanaf 79+. Firefox-ondersteuning voor Reporting-Endpoints is beperkt. De verouderde Report-To-header is nog steeds nodig voor bredere browsercompatibiliteit.
Rapporten zijn niet gegarandeerd te worden afgeleverd. Browsers batchrapporten en verzenden ze op hun eigen schema. Als de gebruiker het tabblad sluit voordat de batch is verzonden, kunnen rapporten verloren gaan. Vertrouw niet op de Reporting API voor kritieke monitoring —gebruik het als aanvullende gegevensbron naast server-side logging.
Het rapportage-eindpunt moet via HTTPS toegankelijk zijn. Browsers weigeren rapporten naar HTTP-eindpunten te sturen voor sites die via HTTPS worden bediend. GitHub Pages-sites die een aangepaste rapportagecollector gebruiken, moeten ervoor zorgen dat de collector een geldig TLS-certificaat heeft.

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

Zo gebruik je deze tool

Kies de headerversie: verouderde Report-To voor bredere compatibiliteit of de nieuwere Reporting-Endpoints-standaardheader. Reporting-Endpoints is eenvoudiger maar heeft nieuwere browserondersteuning.
Selecteer uw servertype (Nginx of Apache) en kopieer de gegenereerde headerconfiguratie naar uw serverconfig, virtual host-blok of .htaccess-bestand.
Schakel optioneel CSP-rapportage in door een CSP-richtlijn type te selecteren (report-uri, report-to of beide). Het gegenereerde fragment bevat de juiste CSP-rapportagerichtlijnen.
Configureer optioneel Network Error Logging (NEL) met uw rapportage-eindpunt-URL, cacheduur en succes-/foutmonsterfrequenties.

Waarvoor je het kunt gebruiken

Verzamel CSP-schendingsrapporten op een centraal eindpunt om uw Content Security Policy te monitoren en te verfijnen zonder legitieme content te blokkeren.
Monitor Network Error Logging-rapporten om netwerkfouten, DNS-problemen, TLS-fouten en connectiviteitsproblemen van echte gebruikers te detecteren en diagnosticeren.
Ontvang verouderingswaarschuwingen en browserinterventierapporten om functies op uw site te identificeren die moeten worden bijgewerkt voordat browsers de ondersteuning verwijderen.

Gebruik

Praktische voorbeelden

Voorbeeld

GitHub Pages-site met CSP-monitoring

Een GitHub Pages-site stelt een strikt Content Security Policy in en wil schendingsrapporten ontvangen. Configureer een Reporting-Endpoints-header met een CSP-eindpunt, voeg Content-Security-Policy met report-to: CSP-endpoint toe en schakel NEL in om netwerkproblemen te detecteren die het laden van assets be茂nvloeden. Rapportens worden naar een klein servereindpunt gestuurd dat ze logt en aggregeert.

Voorbeeld

Nginx reverse proxy met volledige rapportagesuite

Een productie-Nginx reverse proxy voor een Node.js-app configureert zowel Reporting-Endpoints als Content-Security-Policy-Report-Only-headers. CSP-schendingen, NEL-gebeurtenissen en verouderingswaarschuwingen worden allemaal naar een enkel rapportage-eindpunt op /_reports gestuurd. NEL is geconfigureerd met max_age 86400 en een 0,1 foutmonsterfrequentie om representatieve netwerkfoutgegevens te verzamelen zonder het eindpunt te overweldigen.

Veelgemaakte fouten

Gelijktijdig gebruik van zowel Report-To als Reporting-Endpoints-headers —browsers kunnen dubbele rapporten verzenden als beide headers aanwezig zijn. Migreer van Report-To naar Reporting-Endpoints door de oude header te verwijderen zodra Reporting-Endpoints is geconfigureerd en getest.
Een CSP report-uri instellen zonder een bijbehorend rapportage-eindpunt —report-uri stuurt rapporten naar een willekeurige URL via GET-verzoeken met queryparameters, wat de URL-lengtebeperkingen kan overschrijden voor grote schendingsrapporten. Koppel report-uri of report-to altijd aan een correct geconfigureerd ontvangend eindpunt dat POST-verzoeken kan verwerken.
Vergeten CORS te configureren op het rapportage-eindpunt —rapporten worden verzonden vanaf de oorsprong waar de headers worden bediend, maar als uw rapportage-eindpunt op een andere oorsprong staat, moet het cross-origin POST-verzoeken accepteren. Dit is vooral belangrijk voor sites die op GitHub Pages worden gehost met een externe rapportagecollector.

Verificatie

Implementeer de headers op uw server en controleer of ze aanwezig zijn met curl -I of browser DevTools Network-panel. Controleer of Reporting-Endpoints (of Report-To) verschijnt in de response-headers voor HTML-pagina's.
Activeer een CSP-schending door een inline script te laden op een CSP-beschermde pagina en controleer vervolgens uw rapportage-eindpunt op het ontvangen schendingsrapport. Het rapport moet de geblokkeerde URI, de geschonden richtlijn en het bronbestand met regelnummer bevatten.

FAQ

Vragen over Reporting API Header Generator

Wat is het verschil tussen Report-To en Reporting-Endpoints-headers?

Report-To is de verouderde headerindeling die een JSON-configuratie met eindpuntgroepen en prioriteiten gebruikt. Reporting-Endpoints is de nieuwere, eenvoudigere indeling die eindpuntnamen direct aan URL's koppelt in een komma-gescheiden lijst. Reporting-Endpoints heeft de voorkeur voor nieuwe implementaties omdat het de headercomplexiteit vermindert. Chrome ondersteunt beide, terwijl Safari en Firefox Reporting-Endpoints ondersteunen. Voor maximale compatibiliteit nemen sommige sites beide op tijdens migratie, hoewel dit dubbele rapportlevering kan veroorzaken.

Hoe werkt Network Error Logging (NEL) met de Reporting API?

NEL wordt geconfigureerd via een NEL HTTP-header die een rapportage-eindpuntgroep, een max_age voor het beleid en optionele monsterfrequenties specificeert. Wanneer de browser een netwerkverzoek probeert en een fout tegenkomt (DNS-fout, TLS-fout, timeout, etc.), genereert het een NEL-rapport en stuurt dit naar het geconfigureerde rapportage-eindpunt. De browser genereert alleen rapporten voor de oorsprong die de NEL-header bediende. NEL vereist geen server-side instrumentatie —de rapporten komen rechtstreeks van de netwerkstack van de browser.

Welke typen rapporten kan de Reporting API verzamelen?

De Reporting API kan CSP-schendingsrapporten verzamelen (wanneer een resource uw Content Security Policy schendt), Network Error Logging-rapporten (netwerkfouten zoals DNS-fouten, TCP-timeouts, TLS-fouten), verouderingsrapporten (wanneer uw site een verouderde browser-API gebruikt), interventierapporten (wanneer de browser gedrag op uw site blokkeert of wijzigt) en crashrapporten (wanneer een pagina crasht). Elk rapporttype wordt geconfigureerd via zijn eigen HTTP-header of meta-tag, maar alle kunnen naar hetzelfde rapportage-eindpunt worden gestuurd.

Gerelateerde tools