Monitor uw webapplicatie met de Reporting API

Gebruik de rapportage-API om beveiligingsschendingen, verouderde API-aanroepen en meer te monitoren.

Maud Nalpas

Voorzichtigheid:

Dit is een API-handleiding met gedetailleerde gebruiksvoorbeelden voor de Reporting API (v1) , die gebruikmaakt van de Reporting-Endpoints header.

Als u de oude rapportage-API (met de header Report-To ) gebruikt, lees dan meer over API-migratie .

Zoekt u documentatie over het loggen van netwerkfouten ? Ga dan naar Netwerkfoutregistratie.

Sommige fouten doen zich alleen voor in de productieomgeving. Je ziet ze niet lokaal of tijdens de ontwikkeling, omdat echte gebruikers , echte netwerken en echte apparaten de situatie veranderen. De Reporting API helpt bij het opsporen van een aantal van deze fouten, zoals beveiligingsschendingen of verouderde en binnenkort te vervallen API-aanroepen op je site, en stuurt ze door naar een door jou opgegeven eindpunt.

Hiermee kun je via HTTP-headers aangeven wat je wilt monitoren, en het wordt door de browser uitgevoerd.

Door de rapportage-API in te stellen, weet u zeker dat u op de hoogte bent wanneer gebruikers dit soort fouten tegenkomen, zodat u ze kunt verhelpen.

In dit artikel wordt uitgelegd wat deze API kan doen en hoe je hem kunt gebruiken. Laten we beginnen!

Overzicht

Hoe rapporten worden gegenereerd en verzonden.

Laten we ervan uitgaan dat uw site, site.example , een Content-Security-Policy en een Document-Policy heeft. Weet u niet wat deze doen? Geen probleem, u zult dit voorbeeld nog steeds begrijpen.

Je besluit je site te monitoren om te weten wanneer deze beleidsregels worden overtreden, maar ook omdat je wilt controleren of je codebase verouderde of binnenkort verouderde API's gebruikt.

Om dit te doen, configureert u een Reporting-Endpoints header en koppelt u deze eindpuntnamen waar nodig met behulp van de report-to richtlijn in uw beleid.

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0; report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the `default` endpoint

Er gebeurt iets onvoorziens, waardoor sommige gebruikers deze regels overtreden.

Voorbeelden van overtredingen

index.html

<script src="script.js"></script>
<!-- CSP VIOLATION: Try to load a script that's forbidden as per the Content-Security-Policy -->
<script src="https://example.com/script.js"></script>

script.js , geladen door index.html

// DOCUMENT-POLICY VIOLATION: Attempt to use document.write despite the document policy
try {
  document.write('<h1>hi</h1>');
} catch (e) {
  console.log(e);
}
// DEPRECATION: Call a deprecated API
const webkitStorageInfo = window.webkitStorageInfo;

De browser genereert een rapport over schendingen van het CSP, een rapport over schendingen van het documentbeleid en een rapport over verouderde functionaliteit, waarin deze problemen worden vastgelegd.

Met een korte vertraging – tot maximaal een minuut – stuurt de browser de rapporten vervolgens naar het eindpunt dat is geconfigureerd voor dit type overtreding. De rapporten worden door de browser zelf verzonden (niet door uw server of uw website).

Het/de eindpunt(en) ontvangt/ontvangen deze rapporten.

Je hebt nu toegang tot de rapporten over deze eindpunten en kunt zien wat er mis is gegaan. Je bent klaar om het probleem op te lossen dat je gebruikers treft.

Voorbeeldrapport

{
  "age": 2,
  "body": {
    "blockedURL": "https://site2.example/script.js",
    "disposition": "enforce",
    "documentURL": "https://site.example",
    "effectiveDirective": "script-src-elem",
    "originalPolicy": "script-src 'self'; object-src 'none'; report-to main-endpoint;",
    "referrer": "https://site.example",
    "sample": "",
    "statusCode": 200
  },
  "type": "csp-violation",
  "url": "https://site.example",
  "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
}

Gebruiksscenario's en rapporttypen

De rapportage-API kan worden geconfigureerd om u te helpen bij het monitoren van allerlei interessante waarschuwingen of problemen die zich op uw site voordoen:

Let op: Netwerkfoutregistratie wordt niet weergegeven omdat dit niet wordt ondersteund in de nieuwe versie van de API. Raadpleeg de migratiehandleiding voor meer informatie.

Rapporttype	Voorbeeld van een situatie waarin een rapport zou worden gegenereerd.
CSP- schending (alleen niveau 3)	Je hebt een Content-Security-Policy (CSP) ingesteld voor een van je pagina's, maar de pagina probeert een script te laden dat niet is toegestaan ​​door je CSP.
COOP- schending	Je hebt een Cross-Origin-Opener-Policy ingesteld voor een pagina, maar een venster van een andere oorsprong probeert rechtstreeks met het document te communiceren.
COEP- schending	Je hebt een Cross-Origin-Embedder-Policy ingesteld voor een pagina, maar het document bevat een cross-origin iframe dat er niet voor heeft gekozen om te worden geladen door cross-origin documenten.
Schending van het documentbeleid	De pagina heeft een documentbeleid dat het gebruik van document.write verhindert, maar een script probeert document.write toch aan te roepen.
Schending van het toestemmingsbeleid	De pagina heeft een toegangsbeleid dat het gebruik van de microfoon blokkeert, en een script dat audio-invoer vereist.
Waarschuwing voor verouderde functionaliteit	De pagina maakt gebruik van een API die verouderd is of binnenkort verouderd zal zijn; de API wordt rechtstreeks aangeroepen of via een script van een externe partij op het hoogste niveau.
Interventie	De pagina probeert iets te doen wat de browser om veiligheids-, prestatie- of gebruikerservaringsredenen niet toestaat. Bijvoorbeeld in Chrome: de pagina gebruikt document.write op trage netwerken of roept navigator.vibrate aan in een frame van een andere oorsprong waarmee de gebruiker nog niet heeft gecommuniceerd.
Botsing	De browser loopt vast terwijl uw site geopend is.

Rapporten

Hoe zien rapporten eruit?

De browser stuurt rapporten naar het door u geconfigureerde eindpunt. De verzonden verzoeken zien er als volgt uit:

POST
Content-Type: application/reports+json

De inhoud van deze verzoeken is een lijst met rapporten.

Voorbeeldlijst met rapporten

[
  {
    "age": 420,
    "body": {
      "columnNumber": 12,
      "disposition": "enforce",
      "lineNumber": 11,
      "message": "Document policy violation: document-write is not allowed in this document.",
      "policyId": "document-write",
      "sourceFile": "https://site.example/script.js"
    },
    "type": "document-policy-violation",
    "url": "https://site.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  },
  {
    "age": 510,
    "body": {
      "blockedURL": "https://site.example/img.jpg",
      "destination": "image",
      "disposition": "enforce",
      "type": "corp"
    },
    "type": "coep",
    "url": "https://dummy.example/",
    "user_agent": "Mozilla/5.0... Chrome/92.0.4504.0"
  }
]

Hieronder vindt u de gegevens die in elk van deze rapporten te vinden zijn:

Veld	Beschrijving
age	Het aantal milliseconden tussen de tijdstempel van het rapport en de huidige tijd.
body	De daadwerkelijke rapportgegevens, geserialiseerd naar een JSON-string. De velden in de body worden bepaald door het type . ⚠️ Rapporten van verschillende typen hebben verschillende body's .
type	Een rapporttype, bijvoorbeeld csp-violation of coep .
url	Het adres van het document of de medewerker van wie het rapport afkomstig is. Gevoelige gegevens zoals gebruikersnaam, wachtwoord en fragmenten worden uit deze URL verwijderd .
user_agent	De User-Agent header van het verzoek waarmee het rapport is gegenereerd.

Gecertificeerde rapporten

Rapportage-eindpunten met dezelfde oorsprong als de pagina die het rapport genereert, ontvangen de inloggegevens (cookies) in de verzoeken die de rapporten bevatten.

Inloggegevens kunnen nuttige extra context bieden over het rapport; bijvoorbeeld of het account van een bepaalde gebruiker consequent fouten veroorzaakt, of dat een bepaalde reeks acties op andere pagina's een rapport op deze pagina activeert.

Let op: Cross-origin- eindpunten ontvangen geen inloggegevens. Dit is een beveiligingsmaatregel en kan niet worden gewijzigd.

Wanneer en hoe verzendt de browser rapporten?

Rapporten worden buiten de normale communicatiekanalen van uw website verzonden : de browser bepaalt wanneer ze naar de geconfigureerde eindpunten worden gestuurd. Er is ook geen manier om te bepalen wanneer de browser rapporten verzendt; deze verzamelt, plaatst in een wachtrij en verzendt ze automatisch op een geschikt moment.

Dit betekent dat er bij gebruik van de rapportage-API nauwelijks tot geen prestatieproblemen zijn.

Rapporten worden met een vertraging van maximaal een minuut verzonden om de kans te vergroten dat rapporten in batches worden verzonden. Dit bespaart bandbreedte en ontziet de netwerkverbinding van de gebruiker, wat vooral belangrijk is op mobiele apparaten. De browser kan de verzending ook vertragen als deze bezig is met het verwerken van taken met een hogere prioriteit, of als de gebruiker op dat moment een trage of overbelaste netwerkverbinding heeft.

Opmerking: Wanneer u lokaal debugt, kunt u deze vertraging voor het gemak uitschakelen. Zie hoe .

Derden- en eerste-partijkwesties

Rapporten die worden gegenereerd vanwege overtredingen of verouderde functionaliteit op uw pagina, worden verzonden naar de door u geconfigureerde eindpunten. Dit omvat ook overtredingen begaan door scripts van derden die op uw pagina worden uitgevoerd.

Schendingen of verouderde functionaliteit die plaatsvinden in een cross-origin iframe dat in uw pagina is ingesloten, worden niet aan uw endpoint(s) gerapporteerd (althans niet standaard). Een iframe kan zijn eigen rapportage instellen en zelfs rapporteren aan de rapportageservice van uw site – dat wil zeggen, de first-party service; maar dat is de verantwoordelijkheid van de site waarin het iframe is ingesloten. Houd er ook rekening mee dat de meeste rapporten alleen worden gegenereerd als het beleid van een pagina wordt geschonden, en dat het beleid van uw pagina en het beleid van het iframe verschillen.

Belangrijk punt: In Chrome DevTools zie je een foutmelding of waarschuwing in de console voor overtredingen die worden begaan door scripts van derden en cross-origin iframes. Niet al deze meldingen leiden tot het verzenden van rapporten naar je endpoint: de eerste wel, de laatste niet.

Voorbeeld met verouderde functies

Als de header Reporting-Endpoints op uw pagina is ingesteld: worden verouderde API-aanroepen door scripts van derden die op uw pagina worden uitgevoerd, gerapporteerd aan uw endpoint. Verouderde API-aanroepen door een iframe dat in uw pagina is ingesloten, worden niet gerapporteerd aan uw endpoint. Een rapport over verouderde API's wordt alleen gegenereerd als de iframe-server Reporting-Endpoints heeft ingesteld, en dit rapport wordt verzonden naar het endpoint dat de iframe-server heeft ingesteld.

Browserondersteuning

De volgende tabel geeft een overzicht van de browserondersteuning voor de Reporting API v1 , oftewel met de Reporting-Endpoints header. De browserondersteuning voor de Reporting API v0 ( Report-To header) is hetzelfde, met uitzondering van één rapporttype: het loggen van netwerkfouten wordt niet ondersteund in de nieuwe Reporting API. Raadpleeg de migratiehandleiding voor meer informatie.

Rapporttype	Chrome	Chrome iOS	Safari	Firefox	Rand
CSP-schending (alleen niveau 3)*	✔ Ja	✔ Ja	✔ Ja	✘ Nee	✔ Ja
Netwerkfoutregistratie	✘ Nee	✘ Nee	✘ Nee	✘ Nee	✘ Nee
COOP/COEP-schending	✔ Ja	✘ Nee	✔ Ja	✘ Nee	✔ Ja
Alle andere typen: Schending van documentbeleid, Afschrijving, Interventie, Crash	✔ Ja	✘ Nee	✘ Nee	✘ Nee	✔ Ja

Voorzichtigheid:

Browserondersteuning voor CSP-rapportage verschilt van andere rapportagetypen, omdat CSP al langer bestaat. CSP-rapporten kunnen worden gegenereerd met behulp van:

• De verouderde report-uri richtlijn die niet afhankelijk is van de Reporting API.
• De nieuwere report-to richtlijn maakt gebruik van de Reporting API (en de headers Reporting-To of de nieuwere Reporting-Endpoints ).

Deze tabel geeft alleen een overzicht van de ondersteuning voor report-to met de nieuwe koptekst Reporting-Endpoints . Lees de migratietips voor CSP-rapportage als u wilt migreren naar Reporting-Endpoints .

De rapportage-API gebruiken

Bepaal waar de rapporten naartoe moeten worden gestuurd.

Je hebt twee opties:

• Rapporten verzenden naar een bestaande rapportageservice.
• Stuur rapporten naar een rapportagesysteem dat u zelf bouwt en beheert.

Optie 1: Gebruik een bestaande rapportverzamelservice

Enkele voorbeelden van diensten voor het verzamelen van rapporten zijn:

• rapport-uri
• uriports

Als je andere oplossingen kent, open dan een issue om ons dit te laten weten, dan werken we dit bericht bij!

Naast de prijs zijn de volgende punten belangrijk bij het kiezen van een rapportverzamelaar: 🧐

• Ondersteunt deze collector alle rapporttypen? Niet alle oplossingen voor rapportage-endpoints ondersteunen bijvoorbeeld COOP/COEP-rapporten.
• Vindt u het verantwoord om URL's van uw applicatie te delen met een externe partij die rapporten verzamelt? Zelfs als de browser gevoelige informatie uit deze URL's verwijdert, kan gevoelige informatie op deze manier alsnog uitlekken . Als dit te riskant lijkt voor uw applicatie, kunt u beter uw eigen rapportage-eindpunt beheren.

Optie 2: Bouw en beheer uw eigen rapportverzamelaar.

Het bouwen van een eigen server die rapporten ontvangt, is niet zo eenvoudig. Om te beginnen kun je onze lichte boilerplate forken. Deze is gebouwd met Express en kan rapporten ontvangen en weergeven.

Wanneer u uw eigen rapportverzamelaar bouwt:

• Controleer op POST verzoeken met een Content-Type van application/reports+json om rapportverzoeken te herkennen die door de browser naar uw eindpunt worden verzonden.
• Als uw eindpunt zich op een andere oorsprong bevindt dan uw site, zorg er dan voor dat het CORS-preflightverzoeken ondersteunt.

Belangrijk punt: Zorg ervoor dat uw eindpunt CORS-preflightverzoeken ondersteunt.

Optie 3: Combineer optie 1 en 2.

U kunt ervoor kiezen om bepaalde soorten rapporten door een specifieke leverancier te laten genereren, terwijl u voor andere rapporten een interne oplossing hebt.

Stel in dit geval meerdere eindpunten als volgt in:

Reporting-Endpoints: endpoint-1="https://reports-collector.example", endpoint-2="https://my-custom-endpoint.example"

Configureer de Reporting-Endpoints header

Stel een Reporting-Endpoints -antwoordheader in. De waarde ervan moet bestaan ​​uit één of meerdere door komma's gescheiden sleutel-waardeparen:

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"

Als u migreert van de oude Reporting API naar de nieuwe Reporting API, is het wellicht verstandig om zowel Reporting-Endpoints als Report-To in te stellen. Zie de migratiehandleiding voor meer informatie. Als u met name rapportage gebruikt voor schendingen van Content-Security-Policy met alleen de report-uri richtlijn, raadpleeg dan de migratiestappen voor CSP-rapportage .

Reporting-Endpoints: main-endpoint="https://reports.example/main", default="https://reports.example/default"
Report-To: ...

Sleutels (eindpuntnamen)

Elke sleutel kan een naam naar keuze zijn, zoals main-endpoint of endpoint-1 . U kunt ervoor kiezen om verschillende benoemde eindpunten in te stellen voor verschillende rapporttypen, bijvoorbeeld my-coop-endpoint , my-csp-endpoint . Hiermee kunt u rapporten naar verschillende eindpunten routeren, afhankelijk van hun type.

Als u meldingen wilt ontvangen over interventies , afschrijvingen , crashes of een combinatie hiervan, stelt u een eindpunt in met de naam default .

Als de header Reporting-Endpoints geen default eindpunt definieert, worden rapporten van dit type niet verzonden (hoewel ze wel worden gegenereerd).

Belangrijk punt: Ondanks de naam is default geen fallback-eindpunt. Als u bijvoorbeeld report-to my-endpoint instelt voor Document-Policy en my-endpoint niet definieert in Reporting-Endpoints , worden rapporten over schendingen van Document-Policy wel gegenereerd, maar niet verzonden omdat de browser niet weet waar ze naartoe moeten worden gestuurd.

Waarden (URL's)

Elke waarde is een URL naar keuze, waarnaar de rapporten worden verzonden. De URL die u hier instelt, is afhankelijk van uw keuze in stap 1.

Een eindpunt-URL:

• Moet beginnen met een schuine streep ( / ). Relatieve paden worden niet ondersteund.
• Het kan om een ​​verbinding tussen verschillende bronnen gaan; in dat geval worden de inloggegevens echter niet met de rapporten meegestuurd .

Voorbeelden

Reporting-Endpoints: my-coop-endpoint="https://reports.example/coop", my-csp-endpoint="https://reports.example/csp", default="https://reports.example/default"

Je kunt vervolgens elk benoemd eindpunt in het juiste beleid gebruiken, of één enkel eindpunt in alle beleidsregels gebruiken.

Waar moet de koptekst worden geplaatst?

In de nieuwe Reporting API – die in dit artikel wordt besproken – zijn rapporten gekoppeld aan documenten . Dit betekent dat voor één bepaalde oorsprong verschillende documenten, zoals site.example/page1 en site.example/page2 , rapporten naar verschillende eindpunten kunnen sturen.

Om meldingen te ontvangen over overtredingen of verouderde functionaliteiten op een willekeurige pagina van uw site, stelt u de header in als middleware voor alle reacties.

Hier is een voorbeeld in Express:

const REPORTING_ENDPOINT_BASE = 'https://report.example';
const REPORTING_ENDPOINT_MAIN = `${REPORTING_ENDPOINT_BASE}/main`;
const REPORTING_ENDPOINT_DEFAULT = `${REPORTING_ENDPOINT_BASE}/default`;

app.use(function (request, response, next) {
  // Set up the Reporting API
  response.set(
    'Reporting-Endpoints',
    `main-endpoint="${REPORTING_ENDPOINT_MAIN}", default="${REPORTING_ENDPOINT_DEFAULT}"`,
  );
  next();
});

Let op: dit is anders dan de oude Reporting API ( Report-To header), waar je een 'ambient' eindpunt voor één pagina kon instellen en automatisch rapporten kon ophalen voor elke pagina op dezelfde oorsprong. Als je migreert van de oude Reporting API naar de nieuwe Reporting API, raadpleeg dan de migratiehandleiding .

Bewerk uw beleid

Nu de Reporting-Endpoints header is geconfigureerd, voegt u een report-to richtlijn toe aan elke beleidsheader waarvoor u overtredingsrapporten wilt ontvangen. De waarde van report-to moet een van de benoemde eindpunten zijn die u hebt geconfigureerd.

Je kunt meerdere eindpunten gebruiken voor meerdere beleidsregels, of verschillende eindpunten gebruiken voor verschillende beleidsregels.

report-to is niet nodig voor rapporten over verouderde functionaliteit , interventies en crashes . Deze rapporten zijn niet gebonden aan een specifiek beleid. Ze worden gegenereerd zolang er een default eindpunt is ingesteld en worden naar dit default eindpunt verzonden.

Voorbeeld

# Content-Security-Policy violations and Document-Policy violations
# will be sent to main-endpoint
Content-Security-Policy: script-src 'self'; object-src 'none'; report-to main-endpoint;
Document-Policy: document-write=?0;report-to=main-endpoint;
# Deprecation reports don't need an explicit endpoint because
# these reports are always sent to the default endpoint

Waarschuwing: Het correct gebruiken van de report-to syntaxis kan lastig zijn, omdat niet alle beleidsregels dezelfde headerstructuur gebruiken. Afhankelijk van het beleid kan de juiste syntaxis report-to=main-endpoint of report-to main-endpoint zijn.

Debug uw rapportage-instellingen.

Rapporten opzettelijk genereren

Bij het configureren van de rapportage-API moet u waarschijnlijk opzettelijk uw beleid overtreden om te controleren of rapporten naar verwachting worden gegenereerd en verzonden.

Bespaar tijd

Rapporten kunnen met een vertraging worden verzonden – ongeveer een minuut, wat lang is tijdens het debuggen. 😴 Gelukkig kun je in Chrome de vlag --short-reporting-delay gebruiken om rapporten te ontvangen zodra ze worden gegenereerd.

Voer dit commando in je terminal uit om deze vlag in te schakelen:

YOUR_PATH/TO/EXECUTABLE/Chrome --short-reporting-delay

Belangrijk om te weten: deze vlag is niet beschikbaar via de Chrome-interface, het is alleen een vlag die via de commandoregel kan worden ingesteld. Lees hoe je Chromium met vlaggen kunt uitvoeren .

Gebruik DevTools

Gebruik in Chrome de ontwikkelaarstools om de rapporten te bekijken die zijn verzonden of nog zullen worden verzonden.

Deze functie is vanaf oktober 2021 experimenteel. Volg deze stappen om de functie te gebruiken:

1. Gebruik Chrome versie 96 of nieuwer (controleer dit door chrome://version in je browser te typen).
2. Typ of chrome://flags/#enable-experimental-web-platform-features in de adresbalk van Chrome.
3. Klik op Ingeschakeld .
4. Start je browser opnieuw op.
5. Open Chrome DevTools.
6. Open de Chrome DevTools en vervolgens de instellingen. Klik onder Experimenten op 'API-rapportagepaneel inschakelen' in het toepassingspaneel .
7. Herlaad de ontwikkelaarstools.
8. Vernieuw de pagina. Rapporten die zijn gegenereerd door de pagina waarin DevTools is geopend, worden weergegeven in het toepassingspaneel van Chrome DevTools, onder Rapportage-API .

Chrome DevTools toont de rapporten die op uw pagina zijn gegenereerd en hun status.

Rapportstatus

De kolom 'Status' geeft aan of een rapport succesvol is verzonden.

Status	Beschrijving
Success	De browser heeft het rapport verzonden en het eindpunt heeft gereageerd met een succescode ( 200 of een andere succesresponscode 2xx ).
Pending	De browser probeert het rapport te verzenden.
Queued	Het rapport is gegenereerd, maar de browser probeert het niet te verzenden. Een rapport wordt in één van deze twee gevallen als Queued weergegeven: Het rapport is nieuw en de browser wacht af of er meer rapporten binnenkomen voordat het wordt verzonden. Het rapport is niet nieuw; de browser heeft al eerder geprobeerd dit rapport te verzenden, maar dat is mislukt. De browser wacht nu voordat hij het opnieuw probeert.
MarkedForRemoval	Na een tijdje opnieuw geprobeerd te hebben ( Queued ), is de browser gestopt met het verzenden van het rapport en zal het binnenkort uit de lijst met te verzenden rapporten verwijderen.

Rapporten worden na verloop van tijd verwijderd, ongeacht of ze succesvol zijn verzonden.

Belangrijk punt: De status Queued is niet altijd informatief, omdat deze niet precies aangeeft of het verzenden is mislukt of nog niet is geprobeerd. Het gebruik van korte rapportagevertragingen helpt: een rapport dat in dat geval Queued blijft staan, geeft waarschijnlijk aan dat het verzenden mislukt.

Probleemoplossing

Worden rapporten niet gegenereerd of niet zoals verwacht naar uw eindpunt verzonden? Hier zijn een paar tips om dit probleem op te lossen.

Er worden geen rapporten gegenereerd.

De rapporten die in DevTools worden weergegeven, zijn correct gegenereerd. Als het rapport dat u verwacht niet in deze lijst verschijnt:

• Controleer report-to in uw beleid. Als deze onjuist is geconfigureerd, wordt er geen rapport gegenereerd. Ga naar 'Uw beleid bewerken' om dit te corrigeren. Een andere manier om dit probleem op te lossen is door de ontwikkelaarstools in Chrome te raadplegen: als er een foutmelding verschijnt voor de verwachte overtreding, betekent dit dat uw beleid waarschijnlijk correct is geconfigureerd.
• Houd er rekening mee dat alleen de rapporten die zijn gegenereerd voor het document waarin DevTools is geopend, in deze lijst worden weergegeven. Een voorbeeld: als uw site site1.example een iframe site2.example bevat dat een beleid schendt en daarom een ​​rapport genereert, wordt dit rapport alleen in DevTools weergegeven als u het iframe in een eigen venster opent en DevTools voor dat venster opent.

Rapporten worden gegenereerd, maar niet verzonden of ontvangen.

Wat als je een rapport wel in DevTools ziet, maar je endpoint het niet ontvangt?

Belangrijk punt: Omdat het rapport buiten de normale communicatiekanalen om door de browser zelf wordt verzonden en niet door een specifieke website, worden de POST verzoeken met de rapporten niet weergegeven in het netwerkpaneel van uw ontwikkelaarstools.

• Zorg ervoor dat je korte vertragingen gebruikt. Misschien zie je een rapport niet omdat het nog niet verzonden is!

• Controleer de configuratie van de Reporting-Endpoints header. Als er een probleem mee is, wordt een correct gegenereerd rapport niet verzonden. In DevTools blijft de status van het rapport in dit geval ' Queued (de status kan naar Pending springen en vervolgens snel weer terug naar Queued wanneer een verzendpoging wordt gedaan). Enkele veelvoorkomende fouten die dit kunnen veroorzaken:

• Het eindpunt wordt gebruikt, maar is niet geconfigureerd. Voorbeeld:

Code met een fout

 Document-Policy: document-write=?0;report-to=endpoint-1;
 Reporting-Endpoints: default="https://reports.example/default"

Rapporten over schendingen van het documentbeleid moeten naar endpoint-1 worden verzonden, maar deze endpointnaam is niet geconfigureerd in Reporting-Endpoints .

• Het default eindpunt ontbreekt. Sommige rapporttypen, zoals rapporten over verouderde functionaliteit en interventies, worden alleen naar het eindpunt met de naam default verzonden. Lees meer in de sectie 'De rapporteringseindpunten configureren' .

• Zoek naar fouten in de syntaxis van uw beleidsheaders, zoals ontbrekende aanhalingstekens. Zie details .

• Controleer of uw eindpunt inkomende verzoeken kan verwerken.

  • Zorg ervoor dat uw eindpunt CORS-preflightverzoeken ondersteunt. Zo niet, dan kan het geen rapporten ontvangen.

  • Test het gedrag van je endpoint. In plaats van handmatig rapporten te genereren, kun je hiervoor de browser emuleren door verzoeken naar je endpoint te sturen die lijken op wat de browser zou versturen. Voer het volgende uit:

  curl --header "Content-Type: application/reports+json" \
    --request POST \
    --data '[{"age":420,"body":{"columnNumber":12,"disposition":"enforce","lineNumber":11,"message":"Document policy violation: document-write is not allowed in this document.","policyId":"document-write","sourceFile":"https://dummy.example/script.js"},"type":"document-policy-violation","url":"https://dummy.example/","user_agent":"xxx"},{"age":510,"body":{"blockedURL":"https://dummy.example/img.jpg","destination":"image","disposition":"enforce","type":"corp"},"type":"coep","url":"https://dummy.example/","user_agent":"xxx"}]' \
    YOUR_ENDPOINT
  

  Uw eindpunt moet reageren met een succescode ( 200 of een andere succesresponscode 2xx ). Als dit niet het geval is, is er een probleem met de configuratie.

Gerelateerde rapportagemechanismen

Alleen rapport

-Report-Only beleidsheaders en de Reporting-Endpoints werken samen.

Eindpunten die zijn geconfigureerd in Reporting-Endpoints en die zijn opgegeven in het report-to veld van Content-Security-Policy , Cross-Origin-Embedder-Policy en Cross-Origin-Opener-Policy , ontvangen rapporten wanneer deze beleidsregels worden overtreden.

Eindpunten die zijn geconfigureerd in Reporting-Endpoints kunnen ook worden opgegeven in het veld report-to van Content-Security-Policy-Report-Only , Cross-Origin-Embedder-Policy-Report-Only en Cross-Origin-Opener-Policy-Report-Only . Zij ontvangen ook rapporten wanneer deze beleidsregels worden overtreden.

Hoewel er in beide gevallen rapporten worden verzonden, -Report-Only -headers het beleid niet af: er zal niets kapotgaan of daadwerkelijk worden geblokkeerd, maar u ontvangt wel rapporten over wat er kapot zou zijn gegaan of geblokkeerd zou zijn.

Opmerking: Als u een -Report-Only -header gebruikt en uw rapportage-eindpunten hebt geconfigureerd met de oude Report-To header, migreer dan indien mogelijk naar Reporting-Endpoints . Lees meer in de migratiehandleiding .

ReportingObserver

De ReportingObserver JavaScript API kan u helpen bij het observeren van waarschuwingen aan de clientzijde.

ReportingObserver en de Reporting-Endpoints header genereren rapporten die er hetzelfde uitzien, maar die enigszins verschillende gebruiksscenario's mogelijk maken.

Gebruik ReportingObserver als:

• Je wilt alleen waarschuwingen voor verouderde functies of browserinterventies monitoren. ReportingObserver toont waarschuwingen aan de clientzijde, zoals waarschuwingen voor verouderde functies en browserinterventies, maar in tegenstelling tot Reporting-Endpoints registreert het geen andere soorten rapporten, zoals CSP- of COOP/COEP-schendingen.
• Je moet in realtime reageren op deze overtredingen. ReportingObserver maakt het mogelijk om een ​​callback aan een overtredingsgebeurtenis te koppelen .
• Je wilt extra informatie aan een rapport toevoegen om het debuggen te vergemakkelijken, met behulp van de aangepaste callback .

Een ander verschil is dat ReportingObserver alleen aan de clientzijde wordt geconfigureerd: u kunt het gebruiken, zelfs als u geen controle hebt over de headers aan de serverzijde en geen Reporting-Endpoints kunt instellen.

Verder lezen

• Migratiehandleiding van Reporting API v0 naar v1
• ReportingObserver
• Specificatie: legacy Reporting API (v0)
• Specificatie: nieuwe rapportage-API (v1)

Hoofdafbeelding door Nine Koepfer / @enka80 op Unsplash , bewerkt. Hartelijk dank aan Ian Clelland, Eiji Kitamura en Milica Mihajlija voor hun feedback en suggesties op dit document.