Wbudowany endpoint raportów CSP dla każdego monitora

Jeśli w produkcji masz Content-Security-Policy, masz problem z telemetrią. Przeglądarki po cichu blokują skrypty, obrazy i style naruszające Twoją politykę — ale bez skonfigurowanego report-uri lub Reporting-Endpoints nigdy się o tym nie dowiesz. A jeśli już je skonfigurujesz, potrzebny jest endpoint, który raporty przyjmie, zdedupliuje zalewy i pokaże Ci sygnał.

Postawienie własnego endpointu jest możliwe, ale nietrywialne: parsowanie żądań, deduplikacja, retencja, ochrona przed nadużyciami, UI. Większość zespołów zleca to wyspecjalizowanej usłudze.

Od wersji v1.12 każdy monitor SiteGuardian może być własnym endpointem raportów CSP — wliczony w plan, który już masz, w pełni hostowany w UE i podłączony do tych samych reguł alertów, z których już korzystasz.

Co otrzymujesz

1. URL podpisany HMAC per monitor — https://reports.siteguardian.io/r/{monitor_id}/{token}. Wklej go w nagłówek Content-Security-Policy: report-uri … (albo w nowoczesną parę Reporting-Endpoints / Report-To). Oba formaty są obsługiwane równolegle.
2. Agregacja zamiast potopu. Źle skonfigurowana CSP może wysłać miliony raportów z jednej karty przeglądarki. Grupujemy po (dyrektywa, blocked_uri, source_file) i zapisujemy zasobniki: 1 mln surowych raportów staje się jednym wierszem z licznikiem, trzema próbkami i podziałem na przeglądarki.
3. RODO od podstaw. IP klientów są haszowane z codziennie rotującym saltem (nigdy nie są przechowywane w postaci jawnej). Query stringi i fragmenty są usuwane z document_uri i source_file przed zapisem. Zachowujemy rodzinę User-Agenta (chrome/firefox/safari), nigdy całego stringa.
4. Filtr szumu. Naruszenia z rozszerzeń przeglądarek (chrome-extension://, moz-extension://), wstrzyknięcia antywirusów i URI data:/blob: są liczone i odrzucane. Widzisz to, co istotne — a nie to, co ktoś zainstalował na swojej maszynie.
5. Reguły alertów, które już znasz. Dodaj csp_new_violation_type_count lub csp_report_volume do reguły alertu i otrzymaj powiadomienie, gdy pojawi się nowy typ naruszenia (klasyczne wykrywanie dryfu CSP) albo gdy wolumen wystrzeli (zepsuty deploy).
6. Rekomendacje polityki. Po tygodniu raportów sugerujemy dodatki do allowlisty, posortowane według tego, ilu użytkowników każda sugestia naprawi.

Jak to włączyć

Na stronie szczegółów każdego monitora jest teraz zakładka CSP Reports. Jedno kliknięcie provisionuje endpoint; generujemy salt, podpisujemy URL i dajemy Ci gotowy 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"}]}

Wdróż ten nagłówek. Sekundy po pierwszym prawdziwym ruchu zakładka zapala się pierwszym zasobnikiem. Posortuj po liczniku, kliknij, aby wejść w próbki, i zacznij zaciskać politykę.

Limity i ochrona

Jedna źle skonfigurowana CSP na popularnej stronie może wysłać nam 10 000 raportów/s z jednej przeglądarki. nginx limituje na brzegu (200 r/s na IP z burstem 400), a limity per-monitor automatycznie pauzują ingest na godzinę, jeśli monitor przekroczy trzy kolejne minuty ponad limit. Nigdy nie zostaniesz obciążony za crawl loop na własnej stronie.

Po co się tym przejmować?

Bo CSP bez raportowania to CSP na wiarę. Nie wiesz, ile sesji klientów się psuje za każdym razem, gdy marketing wdraża nowego tag managera. Nie wiesz, kiedy CDN dostawcy dodaje nowy tracker, którego Twoja polityka nie dopuszcza. I na pewno nie wiesz, kiedy ktoś próbuje załadować skrypt atakującego.

Teraz wiesz. I jest to wliczone w plan, który już masz.

— Günter Weber, SiteGuardian