Développeurs : masquez les secrets avant de partager logs et captures d'écran

Un fichier de log, un fichier .env ou une capture d'écran de terminal peuvent contenir un secret bien réel. Une clé API, un mot de passe ou l'adresse e-mail d'un client peuvent s'y trouver en clair. Ils sont alors prêts à être collés dans un ticket de support ou un chat avec une IA. La parade tient en deux temps : repérer le secret, et le révoquer s'il a déjà quitté votre machine.

Où se cachent les secrets dans les fichiers du quotidien ?

Un secret fuit rarement depuis un coffre-fort. Il fuit à cause d'habitudes ordinaires : un log de débogage qui affiche une requête complète, un fichier .env collé dans un rapport de bug. Claire Exemple colle une pile d'erreurs dans un ticket de support. Un mot de passe de base de données bien réel s'y trouve encore. Les captures d'écran sont tout aussi risquées. Un terminal peut afficher un jeton exporté dans un coin. Les outils de développement d'un navigateur peuvent enregistrer un en-tête d'autorisation complet dans un fichier HAR.

• Les logs applicatifs et les piles d'erreurs qui affichent des en-têtes de requête ou des variables d'environnement
• Les fichiers .env et de configuration collés dans un ticket ou un chat
• L'historique du shell, qui garde chaque commande tapée, parfois avec un mot de passe dans l'URL
• Les fichiers HAR exportés depuis les outils de développement du navigateur, qui stockent des en-têtes complets
• Les captures d'écran d'un terminal, d'un panneau d'administration ou d'un tableau de bord de supervision
• Les tickets de support et les invites de chat avec une IA, où tout un log est collé pour le contexte

Que fuit dans chaque type de fichier, et comment le partager sans risque ?

Révoquez d'abord : un secret masqué reste un secret qui a fuité

Noircir un mot de passe sur une capture d'écran n'efface pas le fait qu'il a déjà quitté votre machine. Le secret a pu rester dans un log, un ticket ou un chat avant que vous le masquiez. Quelqu'un, ou un système automatisé, a peut-être déjà pu le lire. Le masquage protège le prochain lecteur. Il ne fait rien pour le premier.

Ce n'est pas qu'une précaution. OWASP recommande de révoquer immédiatement une clé exposée, via un processus automatisé si possible. La documentation de GitHub sur la détection des secrets demande de faire tourner l'identifiant concerné dès qu'une fuite est repérée. La CNIL, de son côté, ne recommande plus le changement périodique pour un compte standard, mais le maintient pour les comptes administrateurs. Elle recommande un changement immédiat dès qu'il existe un signe de compromission, et rappelle qu'un mot de passe ne doit jamais être stocké en clair.

Les données clients dans les logs sont aussi des données personnelles

Une ligne de log ne contient rarement que du bruit technique. Elle porte souvent l'adresse e-mail d'un client, une adresse IP, ou un identifiant de session lié à une personne réelle. En droit européen, un identifiant en ligne comme une adresse IP peut compter comme une donnée personnelle. C'est le cas dès qu'il peut identifier quelqu'un, selon le considérant 30 du RGPD. Traitez cette ligne de log comme vous traiteriez un tableur de noms de clients.

• Les adresses e-mail dans un log de rebond ou une erreur d'inscription
• Les adresses IP dans un log de serveur web ou de pare-feu
• Les jetons de session et les cookies liés à un utilisateur connecté
• Les noms complets ou identifiants affichés dans un message d'erreur
• Les identifiants d'appareil ou chaînes de user agent qui isolent l'appareil d'une personne

Une check-list avant de partager un log ou une capture d'écran

1. 1Révoquez ou faites tourner tout secret réel dans le fichier, avant de le caviarder
2. 2Cherchez des motifs connus, comme key, token, password ou secret, avant de coller le texte
3. 3Caviardez les champs structurés dans la donnée, pas seulement dans un rendu visuel
4. 4Noircissez ou recadrez la capture d'écran entièrement, puis zoomez pour vérifier que rien n'a survécu
5. 5Demandez à un collègue de vérifier la version caviardée avant de la publier
6. 6Vérifiez la destination : un ticket privé n'a pas le même risque qu'un forum public

Vérifier une capture d'écran à l'œil nu prend du temps, et l'erreur arrive vite un jour chargé. ONYRI Sanitize fait cette vérification dans votre propre navigateur. En formule Pro, il détecte les secrets techniques comme les clés API, les jetons cloud et les JWT. Il les repère même dans une capture d'écran lue par OCR embarqué, et les masque avant l'export. Sa limite : il masque un secret, il ne le révoque pas, donc tout ce qui est déjà parti doit encore être révoqué à la source.

Si un secret a déjà fuité, que faire en premier ?

1. 1Révoquez ou faites tourner l'identifiant immédiatement, chez le fournisseur, pas seulement dans votre code
2. 2Vérifiez les journaux d'utilisation du fournisseur pour repérer une activité que vous ne reconnaissez pas
3. 3Retirez le secret de l'historique Git seulement après l'avoir révoqué, car réécrire l'historique seul ne neutralise pas une clé active
4. 4Prévenez votre équipe et, si des données clients ont fuité, suivez votre procédure d'incident pour informer les personnes concernées
5. 5Ajoutez une étape de détection, comme le secret scanning de GitHub ou un outil comme gitleaks, pour repérer l'erreur plus tôt

Rien de tout cela n'a besoin d'être dramatique. Une courte pause avant d'envoyer vaut mieux que dix minutes d'inquiétude plus tard. Prenez l'habitude de vérifier logs et captures d'écran comme vous vérifieriez un e-mail avant de l'envoyer.