Un endpoint integrato di report CSP per ogni monitor

Se hai una Content-Security-Policy in produzione, hai un problema di telemetria. I browser bloccano silenziosamente script, immagini e stili che violano la tua policy — ma senza configurare report-uri o Reporting-Endpoints, non te ne accorgi mai. E anche se li configuri, serve un endpoint che accetti i report, deduplichi i picchi e ti mostri il segnale.

Gestire un endpoint in proprio è fattibile, ma non banale: parsing delle richieste, deduplicazione, retention, protezione anti-abuso, UI. La maggior parte dei team delega questa parte a un servizio specializzato.

Dalla versione v1.12 ogni monitor SiteGuardian può essere il proprio endpoint di report CSP — incluso nel piano che hai già, completamente ospitato nell'UE e collegato alle stesse regole di alert che usi già.

Cosa ottieni

1. Un URL firmato HMAC per monitor — https://reports.siteguardian.io/r/{monitor_id}/{token}. Incollalo nell'header Content-Security-Policy: report-uri … (o nella coppia moderna Reporting-Endpoints / Report-To). Supportiamo entrambi i formati in parallelo.
2. Aggregazione al posto del torrente. Una CSP mal configurata può inondarti di milioni di report da una singola tab del browser. Raggruppiamo per (direttiva, blocked_uri, source_file) e salviamo bucket: 1 M di report grezzi diventano una riga con contatore, tre campioni e breakdown per browser.
3. Privacy by design. Gli IP dei client vengono hashati con un salt a rotazione giornaliera (mai memorizzati in chiaro). Query string e fragment vengono rimossi da document_uri e source_file prima della memorizzazione. Conserviamo la famiglia dello User-Agent (chrome/firefox/safari), mai la stringa completa.
4. Filtro del rumore. Le violazioni da estensioni del browser (chrome-extension://, moz-extension://), iniezioni di antivirus e URI data:/blob: vengono conteggiate e scartate. Vedi ciò che conta — non ciò che l'utente ha installato sulla sua macchina.
5. Regole di alert che già conosci. Aggiungi csp_new_violation_type_count o csp_report_volume a una regola di alert e vieni avvisato quando compare un nuovo tipo di violazione (il classico rilevamento del drift CSP) o quando il volume esplode (deploy sbagliato).
6. Raccomandazioni di policy. Dopo una settimana di report, ti suggeriamo aggiunte all'allowlist, ordinate per numero di utenti che ciascuna correzione sbloccherebbe.

Come attivarlo

Nella pagina di dettaglio di qualunque monitor c'è ora una tab CSP Reports. Un clic provisiona l'endpoint; generiamo un salt, firmiamo l'URL e ti consegniamo uno snippet pronto da incollare:

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"}]}

Distribuisci quell'header. Pochi secondi dopo il primo traffico reale, la tab si accende con il primo bucket. Ordina per conteggio, clicca per aprire i sample e inizia a stringere la policy.

Rate-limit e protezioni

Una singola CSP mal configurata su una pagina molto visitata può inviarci 10 000 report/s da un solo browser. nginx limita al bordo (200 r/s per IP con burst di 400) e le quote per monitor mettono automaticamente in pausa l'ingest per un'ora se un monitor supera tre minuti consecutivi oltre la soglia. Non verrai mai fatturato per un crawl loop sul tuo stesso sito.

Perché preoccuparsene?

Perché CSP senza reporting è CSP alla cieca. Non sai quante sessioni dei tuoi clienti si rompono ogni volta che il team marketing fa uscire un nuovo tag manager. Non sai quando la CDN di un vendor aggiunge un nuovo tracker che la tua policy non permette. E di sicuro non ti accorgi quando qualcuno prova a caricare uno script controllato da un attaccante.

Ora lo sai. Ed è incluso nel piano che paghi già.

— Günter Weber, SiteGuardian