Um endpoint integrado de relatórios CSP para cada monitor

Se tem uma Content-Security-Policy em produção, tem um problema de telemetria. Os navegadores bloqueiam silenciosamente scripts, imagens e estilos que violam a sua política — mas, sem report-uri ou Reporting-Endpoints configurados, nunca fica a saber. E mesmo que configure, precisa de um endpoint que aceite os relatórios, desduplice os picos e lhe mostre o sinal.

Manter um endpoint próprio é viável, mas não trivial: parsing de pedidos, desduplicação, retenção, proteção contra abusos, UI. A maioria das equipas delega esta parte a um serviço especializado.

A partir da v1.12, cada monitor SiteGuardian pode ser o seu próprio endpoint de relatórios CSP — incluído no plano que já tem, totalmente alojado na UE e ligado às mesmas regras de alerta que já utiliza.

O que obtém

1. Um URL assinado por HMAC, por monitor — https://reports.siteguardian.io/r/{monitor_id}/{token}. Cole-o no cabeçalho Content-Security-Policy: report-uri … (ou no par moderno Reporting-Endpoints / Report-To). Ambos os formatos são suportados em paralelo.
2. Agregação em vez de torrente. Uma CSP mal configurada pode enviar-lhe milhões de relatórios a partir de um único separador do navegador. Agrupamos por (diretiva, blocked_uri, source_file) e guardamos buckets: 1 M de relatórios brutos tornam-se uma linha com contador, três amostras e desagregação por navegador.
3. Privacidade por design. Os IPs dos clientes são hashados com um salt de rotação diária (nunca guardados em claro). Query strings e fragmentos são removidos de document_uri e source_file antes do armazenamento. Mantemos a família do User-Agent (chrome/firefox/safari), nunca a string completa.
4. Filtro de ruído. Violações de extensões do navegador (chrome-extension://, moz-extension://), injeções de antivírus e URIs data:/blob: são contadas e descartadas. Vê o que importa — não o que alguém instalou na sua máquina.
5. Regras de alerta que já conhece. Adicione csp_new_violation_type_count ou csp_report_volume a uma regra de alerta e receba uma notificação quando surgir um novo tipo de violação (a clássica deteção de drift CSP) ou quando o volume disparar (deploy partido).
6. Recomendações de política. Após uma semana de relatórios, sugerimos adições à allowlist, ordenadas por quantos utilizadores cada sugestão voltaria a permitir.

Como ativar

Em cada página de detalhe de monitor existe agora um separador CSP Reports. Um clique provisiona o endpoint; geramos um salt, assinamos o URL e entregamos um snippet pronto a colar:

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

Implante esse cabeçalho. Segundos após o primeiro tráfego real, o separador acende com o primeiro bucket. Ordene por contagem, clique para explorar as amostras e comece a apertar a política.

Limites de taxa e proteção

Uma única CSP mal configurada numa página muito acedida pode enviar-nos 10 000 relatórios/s a partir de um só navegador. O nginx limita no edge (200 r/s por IP de origem com burst de 400), e quotas por monitor pausam automaticamente a ingestão durante uma hora se um monitor exceder três minutos consecutivos acima do limite. Nunca é cobrado por um crawl loop no seu próprio site.

Porquê o esforço?

Porque CSP sem relatórios é CSP às cegas. Não sabe quantas sessões de clientes partem sempre que a equipa de marketing lança um novo tag manager. Não sabe quando o CDN de um fornecedor adiciona um novo tracker que a sua política não permite. E, sobretudo, não dá por isso quando alguém tenta carregar um script controlado por um atacante.

Agora dá. E está incluído no plano que já paga.

— Günter Weber, SiteGuardian