Si vous faites tourner une Content-Security-Policy en production, vous avez un problème de télémétrie. Les navigateurs bloquent en silence scripts, images et feuilles de style qui enfreignent votre politique — mais sans report-uri ou Reporting-Endpoints, vous ne le saurez jamais. Et si vous les configurez, encore faut-il disposer d'un endpoint qui accepte les rapports, déduplique les raz-de-marée et en extraie le signal utile.
Monter son propre endpoint reste faisable, mais pas trivial : parseur de requêtes, déduplication, rétention, protection anti-abus, UI. La plupart des équipes délèguent cela à un service spécialisé.
À partir de la v1.12, chaque monitor SiteGuardian peut devenir son propre endpoint de rapports CSP — inclus dans votre formule actuelle, entièrement hébergé dans l'UE, et branché sur les mêmes règles d'alerte que vous utilisez déjà.
Ce que vous obtenez
- Une URL signée HMAC par monitor —
https://reports.siteguardian.io/r/{monitor_id}/{token}. Collez-la dans votre en-têteContent-Security-Policy: report-uri …(ou dans le couple moderneReporting-Endpoints/Report-To). Les deux formats sont pris en charge en parallèle. - Agrégation plutôt que firehose. Une CSP mal configurée peut vous envoyer des millions de rapports depuis un seul onglet. Nous regroupons par
(directive, blocked_uri, source_file)et stockons des buckets : 1 M de rapports bruts deviennent une ligne avec compteur, trois échantillons et une répartition par navigateur. - RGPD by design. Les IP clientes sont hachées avec un sel à rotation quotidienne (jamais stockées en clair). Les query strings et fragments sont retirés de
document_urietsource_fileavant stockage. Nous gardons la famille du User-Agent (chrome/firefox/safari), jamais la chaîne complète. - Filtrage du bruit. Les violations liées aux extensions (
chrome-extension://,moz-extension://), aux antivirus et aux URIsdata:/blob:sont comptées puis écartées. Vous voyez ce qui compte — pas ce que l'utilisateur a installé sur sa machine. - Des règles d'alerte que vous connaissez déjà. Ajoutez
csp_new_violation_type_countoucsp_report_volumeà une règle d'alerte et recevez une notification lorsqu'un nouveau type de violation apparaît (la classique détection de dérive CSP) ou lorsque le volume s'envole (déploiement qui casse quelque chose). - Suggestions de politique. Après une semaine de rapports, nous proposons des ajouts à l'allowlist, classés par nombre d'utilisateurs que chacun débloquerait.
Comment l'activer
Chaque page de détail de monitor affiche désormais un onglet CSP Reports. Un clic provisionne l'endpoint ; nous générons un sel, signons l'URL et vous remettons un snippet prêt à coller :
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"}]}
Déployez cet en-tête. Quelques secondes après le premier trafic réel, l'onglet se remplit avec le premier bucket. Triez par compteur, cliquez pour explorer les échantillons, puis resserrez votre politique.
Limites de débit et protection
Une CSP mal configurée sur une page populaire peut nous envoyer 10 000 rapports/s depuis un seul navigateur. nginx limite au niveau de l'edge (200 req/s par IP avec une burst de 400), et des quotas par monitor mettent l'ingestion en pause d'une heure si un monitor dépasse trois minutes consécutives au-delà du seuil. Vous ne serez jamais facturé pour un crawl en boucle sur votre propre site.
Pourquoi s'en soucier ?
Parce que CSP sans reporting, c'est CSP à l'aveugle. Vous ne savez pas combien de sessions utilisateurs cassent chaque fois que l'équipe marketing déploie un nouveau tag manager. Vous ne savez pas quand la CDN d'un prestataire ajoute un tracker que votre politique n'autorise pas. Et vous ne savez surtout pas quand un attaquant tente de charger un script malveillant.
Maintenant, vous le savez. Et c'est inclus dans la formule que vous avez déjà.
— Günter Weber, SiteGuardian