Een ingebouwde CSP-rapport-endpoint voor elke monitor

Wie een Content-Security-Policy in productie draait, heeft een telemetrieprobleem. Browsers blokkeren stilzwijgend scripts, afbeeldingen en stijlen die uw CSP schenden — maar zonder report-uri of Reporting-Endpoints hoort u er niets van. En als u het wél instelt, hebt u een endpoint nodig dat de rapporten aanneemt, dubbele meldingen samenvat en u het signaal laat zien.

Zelf een endpoint draaien is haalbaar, maar niet triviaal: request-parsing, deduplicatie, retentie, misbruikbescherming, UI. De meeste teams besteden dat uit aan een gespecialiseerde dienst.

Vanaf v1.12 kan elke SiteGuardian-monitor zijn eigen CSP-rapport-endpoint zijn — inbegrepen in het abonnement dat u al hebt, volledig EU-gehost en gekoppeld aan dezelfde alertregels die u al gebruikt.

Wat u krijgt

1. Een HMAC-ondertekende URL per monitor — https://reports.siteguardian.io/r/{monitor_id}/{token}. Plak die in uw Content-Security-Policy: report-uri …-header (of in het moderne duo Reporting-Endpoints / Report-To). Beide formaten worden parallel ondersteund.
2. Aggregatie in plaats van een stortvloed. Een slecht geconfigureerde CSP kan u miljoenen rapporten sturen vanuit één browser-tab. Wij groeperen op (directive, blocked_uri, source_file) en slaan buckets op: 1 M ruwe rapporten worden één rij met teller, drie samples en een browser-breakdown.
3. AVG by design. Client-IP's worden gehashed met een dagelijks roterend salt (nooit in klare tekst opgeslagen). Query strings en fragmenten worden uit document_uri en source_file verwijderd vóór opslag. We bewaren de User-Agent-familie (chrome/firefox/safari), nooit de volledige string.
4. Ruisfilter. Schendingen door browserextensies (chrome-extension://, moz-extension://), antivirus-injecties en data:/blob:-URIs worden geteld en weggefilterd. U ziet wat ertoe doet — niet wat iemand op zijn eigen machine heeft geïnstalleerd.
5. Alertregels die u al kent. Voeg csp_new_violation_type_count of csp_report_volume toe aan een alertregel en ontvang een melding zodra een nieuw schendingstype opduikt (klassieke CSP-drift-detectie) of het volume uit de hand loopt (mislukte deploy).
6. Policy-aanbevelingen. Na een week aan rapporten suggereren we aanvullingen op de allowlist, gerangschikt naar hoeveel gebruikers elke suggestie weer aan de praat zou helpen.

Hoe u het activeert

Op de detailpagina van elke monitor staat nu een tabblad CSP Reports. Eén klik provisioneert de endpoint; wij genereren een salt, signeren de URL en geven u een kant-en-klaar snippet:

Content-Security-Policy: default-src 'self';
  report-uri https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d;
  report-to sg-csp
Reporting-Endpoints: sg-csp="https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d"
Report-To: {"group":"sg-csp","max_age":10886400,"endpoints":[{"url":"https://reports.siteguardian.io/r/69a8b2f…/4e8f1c7d"}]}

Implementeer die header. Seconden na het eerste echte verkeer licht het tabblad op met de eerste bucket. Sorteer op teller, klik om naar de samples te drillen en begin uw policy aan te scherpen.

Rate-limits en bescherming

Eén slecht geconfigureerde CSP op een druk bezochte pagina kan ons 10 000 rapporten/s sturen vanuit één browser. nginx limiteert aan de rand (200 req/s per bron-IP met burst 400), en per-monitor-quota pauzeren de ingest een uur lang als een monitor drie minuten achter elkaar boven de limiet blijft. U wordt nooit gefactureerd voor een crawl-loop op uw eigen site.

Waarom de moeite?

Omdat CSP zonder rapportage CSP op goed geluk is. U weet niet hoeveel klantsessies er kapotgaan telkens wanneer marketing een nieuwe tag manager uitrolt. U weet niet wanneer de CDN van een leverancier een nieuwe tracker toevoegt die uw policy niet toestaat. En u merkt al helemaal niet wanneer iemand probeert een kwaadaardig script te laden.

Nu wel. En het zit in het abonnement dat u al hebt.

— Günter Weber, SiteGuardian