Clustraly
Intelligence des erreurs & RGPD

Beacon de rapport de violation CSP : voyez enfin ce que votre politique bloque

Beacon de rapport de violation CSP une fonctionnalité du module Intelligence des erreurs & RGPD de Clustraly. Le Beacon de rapport de violation CSP reçoit les rapports du navigateur et regroupe chaque violation par directive et hôte bloqué.

Vos visiteurs déclenchent des violations CSP à chaque page, en silence, dans leur navigateur. Ce beacon les reçoit, les normalise et les regroupe pour que vous sachiez enfin ce que votre politique bloque et pourquoi.

Visibilité

Chaque blocage CSP devient un signal que vous pouvez lire

Votre politique de sécurité de contenu bloque scripts, styles et cadres directement dans le navigateur du visiteur sans que rien ne remonte jusqu'à vous. Ce beacon collecte ces rapports de violation pour que vous cessiez d'avancer à l'aveugle.

Une directive trop stricte qui casse une page, un tiers en contenu mixte, une tentative d'injection : vous le voyez côté serveur au lieu de le découvrir dans un ticket client.

  • Reçoit les rapports que le navigateur émet à chaque violation
  • Distingue une CSP mal réglée d'un comportement suspect
  • Plus aucune violation ne reste invisible côté serveur
Fonctionnement

Un endpoint public dédié : POST /api/csp-report

Vous pointez la directive de report de votre CSP vers /api/csp-report, et les navigateurs y postent leurs violations tout seuls. L'endpoint fonctionne sans session, dans le bucket « api » du limiteur de débit, et répond toujours 204 le visiteur n'attend jamais.

Les charges utiles au-delà de 16 Ko sont écartées, ce qui borne d'emblée ce que la route accepte.

  • Sans session : les navigateurs postent directement
  • Répond toujours 204, sans jamais ralentir le visiteur
  • Charge utile plafonnée à 16 Ko
  • Rattaché au bucket « api » du limiteur de débit
Trois formats, un évènement

Les navigateurs parlent trois langues, vous n'en lisez qu'une

Le reporting CSP s'est fragmenté au fil des années : l'ancien format « csp-report », la Reporting API moderne (tableau body) et l'objet nu. Le beacon analyse les trois sans que vous ayez à trancher lequel gérer.

Chaque violation est ensuite normalisée en un évènement CspViolation unique, de sévérité warning une seule forme à exploiter en aval.

  • Analyse le format historique « csp-report »
  • Analyse la Reporting API (tableau body)
  • Analyse aussi l'objet nu
  • Normalise tout en évènement CspViolation unique
Regroupement

Mille violations identiques, un seul groupe à traiter

Chaque violation est regroupée par directive et hôte bloqué : mille rapports identiques s'effondrent en un seul groupe clair. Vous triez le motif, pas le bruit.

Ces groupes rejoignent la console d'intelligence des erreurs dans la catégorie csp, avec le même suivi de statut, la même timeline et la même corrélation par version que n'importe quel autre incident.

  • Regroupé par directive + hôte bloqué
  • Alimente la console d'intelligence des erreurs (catégorie csp)
  • Filtrable, priorisable et suivi comme tout incident
Voir la console d'intelligence des erreurs
Garde-fous

Pensé pour absorber le bruit CSP sans vous inonder

Un endpoint CSP est réputé bruyant : extensions, robots et tiers déclenchent des rapports par milliers. Un plafond anti-flood horaire borne l'ingestion, et un plafond par source non fiable (défaut 500/heure) protège la base.

La sévérité warning tient les violations CSP hors de vos alertes « new » et « spike » par défaut, et vous coupez toute la capture d'un seul réglage quand vous le décidez.

  • Plafond anti-flood horaire sur l'ingestion
  • Plafond par source non fiable (défaut 500/heure)
  • Sévérité warning exclue des alertes bruyantes par défaut
  • Désactivable via ERROR_CAPTURE_CSP (no-op silencieux)
Pourquoi ça compte

Le beacon observe, vous décidez

Ce beacon écoute et regroupe ce que le navigateur signale ; il ne touche jamais à votre politique de sécurité. À vous d'ajuster une directive, de corriger un tiers ou d'ignorer un bruit connu. La donnée éclaire, la décision reste la vôtre.

FAQ

Questions fréquentes

Comment envoyer les rapports de violation vers ce beacon ?
Pointez la directive de report de votre en-tête CSP vers l'endpoint public POST /api/csp-report. Les navigateurs y postent alors automatiquement chaque violation, sans session requise, et l'endpoint répond toujours 204.
Quels formats de rapport CSP sont pris en charge ?
Trois : le format historique « csp-report », la Reporting API (tableau body) et l'objet nu. Le beacon les analyse tous puis normalise chaque violation en un évènement CspViolation unique de sévérité warning, regroupé par directive et hôte bloqué.
Le bruit CSP risque-t-il de saturer mon intelligence des erreurs ?
Non. Un plafond anti-flood horaire borne l'ingestion, un plafond par source non fiable (défaut 500 par heure) protège la base, la charge utile est limitée à 16 Ko, et la sévérité warning tient ces violations hors des alertes « new » et « spike » par défaut.
Peut-on désactiver la capture des violations CSP ?
Oui. L'endpoint est conditionné par ERROR_CAPTURE_CSP : désactivé, il devient un no-op silencieux qui répond 204 sans rien ingérer. Vous gardez donc la maîtrise totale de ce que vous collectez.
Prêt à commencer ?

Transformez le bruit CSP en signal exploitable

Vos violations CSP existent déjà elles restent seulement invisibles. Branchez le Beacon de rapport de violation CSP sur votre politique : les navigateurs remontent leurs blocages, le beacon les normalise et les regroupe par directive et hôte, et vous décidez quoi corriger. Une seule route, trois formats absorbés, des garde-fous anti-flood pour ne jamais vous noyer.