Un endpoint integrado de informes CSP para cada monitor

Si tiene una Content-Security-Policy en producción, tiene un problema de telemetría. Los navegadores bloquean silenciosamente los scripts, imágenes y estilos que infringen su política — pero, a menos que configure report-uri o Reporting-Endpoints, nunca se entera. Y si lo configura, necesita un endpoint que acepte los informes, deduplique las avalanchas y le muestre la señal real.

Montar un endpoint propio es factible pero no trivial: parseo de peticiones, deduplicación, retención, protección contra abusos, UI. La mayoría de los equipos delegan esta parte a un servicio especializado.

A partir de la v1.12, cada monitor de SiteGuardian puede convertirse en su propio endpoint de informes CSP — incluido en el plan que ya tiene, alojado íntegramente en la UE, y conectado a las mismas reglas de alerta que ya utiliza.

Qué obtiene

1. Una URL firmada con HMAC por monitor — https://reports.siteguardian.io/r/{monitor_id}/{token}. Péguela en su cabecera Content-Security-Policy: report-uri … (o en el par moderno Reporting-Endpoints / Report-To). Aceptamos ambos formatos en paralelo.
2. Agregación en lugar de una manguera. Una CSP mal configurada puede inundarle con millones de informes desde una única pestaña del navegador. Nosotros agrupamos por (directiva, blocked_uri, source_file) y guardamos buckets: 1 M de informes brutos se convierten en una fila con un contador, tres muestras y un desglose por navegador.
3. Privacidad por diseño. Las IP de los clientes se hashean con una sal de rotación diaria (nunca se almacenan en claro). Las query strings y fragmentos se eliminan de document_uri y source_file antes del almacenamiento. Conservamos la familia del User-Agent (chrome/firefox/safari), nunca la cadena completa.
4. Filtrado de ruido. Las violaciones de extensiones de navegador (chrome-extension://, moz-extension://), inyecciones de antivirus y URIs data:/blob: se cuentan y se descartan. Verá lo que importa, no lo que el usuario tenga instalado en su máquina.
5. Reglas de alerta que ya conoce. Añada csp_new_violation_type_count o csp_report_volume a una regla de alerta y reciba un aviso cuando aparezca un nuevo tipo de violación (la clásica detección de deriva de CSP) o cuando el volumen se dispare (un despliegue roto).
6. Recomendaciones de política. Tras una semana de informes, le sugerimos adiciones a la allowlist, ordenadas por cuántos usuarios corregiría cada propuesta.

Cómo activarlo

En la página de detalle de cualquier monitor hay ahora una pestaña CSP Reports. Un clic aprovisiona el endpoint; generamos una sal, firmamos la URL y le entregamos un fragmento listo para pegar:

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

Despliegue esa cabecera. Segundos después del primer tráfico real, la pestaña se ilumina con el primer bucket. Ordene por recuento, haga clic para profundizar en las muestras y empiece a afinar su política.

Límites de tasa y seguridad

Una única CSP mal configurada en una página popular puede enviarnos 10 000 informes/seg desde un solo navegador. nginx limita el tráfico en el borde (200 r/s por IP con ráfagas de 400), y cuotas por monitor pausan automáticamente la ingesta durante una hora si un monitor supera tres minutos consecutivos por encima del límite. Nunca se le cobrará por un bucle de crawler sobre su propia web.

¿Por qué molestarse?

Porque CSP sin reporte es CSP a ciegas. No sabe qué sesiones de clientes se rompen cada vez que el equipo de marketing despliega un nuevo tag manager. No sabe cuándo la CDN de un proveedor ha añadido un nuevo tracker que su política no permite. Y, con toda seguridad, no sabe cuándo alguien intenta cargar scripts de un atacante.

Ahora lo sabe. Y está incluido en el plan que ya tiene.

— Günter Weber, SiteGuardian