Cent breadcrumbs : c’est, par défaut, le nombre d’événements que le SDK JavaScript de Sentry conserve avant de les attacher au prochain rapport d’erreur. Chaque clic, chaque requête fetch, chaque log console y figure, avec son URL complète et parfois ses en-têtes.
Sur un site WordPress qui appelle une API tierce depuis le navigateur (paiement, recherche, CRM), ce mécanisme transforme silencieusement un outil de diagnostic en collecteur de secrets. La checklist qui suit permet de garder le monitoring sans exposer ce qu’il ne devrait jamais voir.
Comprendre ce qu’un breadcrumb capture
Un breadcrumb Sentry n’est pas un simple message de log : selon sa catégorie, il embarque la méthode HTTP, l’URL complète (avec query string), le code de statut et, pour les intégrations XHR ou fetch instrumentées automatiquement, une partie des en-têtes de la requête. Si une clé d’API ou un jeton de session transite en paramètre d’URL ou en en-tête Authorization, il se retrouve donc dans l’historique attaché au rapport d’erreur suivant, même si l’erreur elle-même n’a rien à voir avec cet appel.
C’est particulièrement vrai pour les intégrations qui suivent la navigation (tracingOrigins) et les appels vers des services comme un CRM ou une plateforme de paiement, dont les endpoints portent souvent le jeton directement dans l’URL pour simplifier l’implémentation côté client.
La checklist avant mise en production
- Auditer les intégrations activées : dans la configuration
Sentry.init(), lister précisément les intégrations par défaut (Breadcrumbs,Http,TryCatch) et celles ajoutées manuellement, plutôt que de garder la configuration générée par un tutoriel. - Passer par
beforeBreadcrumb: ce hook reçoit chaque breadcrumb avant stockage et permet de retournernullpour l’ignorer, ou de retourner une version expurgée de son champdata. - Filtrer aussi
beforeSend: ce second filtre s’applique à l’événement complet juste avant l’envoi réseau, en dernier recours si un breadcrumb sensible est passé au travers. - Bannir les jetons en query string : côté intégration tierce, préférer un en-tête dédié à un paramètre d’URL, plus facile à repérer et à filtrer par un pattern générique.
- Vérifier côté serveur aussi : le SDK PHP de Sentry capture les superglobales
$_SERVERet parfois$_POSTselon la configuration ; les mêmes règles de filtrage s’y appliquent viabefore_send.
Un exemple de filtrage réutilisable
Plutôt que de traiter chaque intégration tierce au cas par cas, un filtre générique basé sur des motifs reconnaît les paramètres sensibles quel que soit le service appelé :
Sentry.init({
dsn: SENTRY_DSN,
beforeBreadcrumb(breadcrumb) {
if (breadcrumb.category === 'fetch' || breadcrumb.category === 'xhr') {
const url = breadcrumb.data && breadcrumb.data.url;
if (url && /(token|api_key|apikey|auth)=/i.test(url)) {
breadcrumb.data.url = url.replace(/([?&])(token|api_key|apikey|auth)=[^&]+/gi, '$1$2=%5Bfiltré%5D');
}
}
return breadcrumb;
},
});Ce filtre ne bloque rien : il neutralise la valeur sensible tout en conservant la trace de l’appel, ce qui reste utile pour comprendre la séquence d’événements ayant mené à l’erreur.
Vérifier que le filtrage fonctionne vraiment
Une règle de filtrage non testée est une fausse sécurité. La vérification la plus fiable consiste à déclencher volontairement une erreur après un appel contenant un jeton factice, puis à ouvrir l’événement dans le tableau de bord Sentry pour inspecter chaque breadcrumb un par un. Il faut également vérifier le comportement en environnement de développement : certains projets laissent le DSN de développement pointer vers le même projet Sentry que la production, ce qui multiplie les occasions de fuite pendant les tests.
Sur les projets suivis avec ce filtrage systématique, les rapports d’erreur ne perdent aucune information utile au diagnostic : seule la donnée d’authentification disparaît, remplacée par un marqueur explicite qui indique qu’un filtrage a eu lieu, ce qui évite aussi de se demander si l’absence de paramètre est un bug applicatif.
Ce que cela change en pratique
La différence entre un projet Sentry bien configuré et un projet qui fuit ne se voit jamais dans le tableau de bord tant que personne ne cherche : le rapport d’erreur a la même forme, le message est identique, la stack trace ne change pas. C’est justement pour cela que le filtrage doit être une étape de mise en production au même titre que la configuration du DSN, et non une réaction à un incident déjà survenu.
Sur nos projets, la règle appliquée est simple : aucune intégration de monitoring ne part en production sans qu’un jeton factice ait été volontairement envoyé pour vérifier qu’il n’apparaît nulle part dans le tableau de bord.
En résumé
Un outil de suivi d’erreurs bien réglé raconte l’histoire d’un bug sans raconter en même temps les secrets qui ont transité pendant cette histoire. Les hooks beforeBreadcrumb et beforeSend suffisent à obtenir ce résultat, à condition de les considérer comme une étape obligatoire du déploiement, testée avec autant de rigueur que le reste de l’intégration.
