Accueil / Sécurité et données

Secrets : ne jamais les faire transiter, ne jamais les afficher en clair

Un secret collé dans une conversation, même brièvement, reste ensuite présent dans les journaux et dans toute relecture automatique de l'historique, et une commande de configuration lancée pour un motif précis peut afficher un secret voisin en clair si son filtre est trop large.

Un secret collé dans une conversation ne disparaît jamais vraiment. Il reste dans les journaux du service qui a reçu le message, et toute relecture automatique de cet historique, la vôtre ou celle d'un outil tiers, peut le réafficher des mois plus tard. La règle la plus simple reste donc la première : un mot de passe, une clé d'API ou un jeton d'accès ne se colle jamais dans une conversation, même pour une question rapide ou une correction ponctuelle.

Le moindre privilège, avant tout le reste

Le moindre privilège est le principe qui consiste à ne donner à un outil, un agent ou une personne que l'accès minimum nécessaire à la tâche en cours, jamais un accès plus large par confort. Un agent chargé de renommer des fichiers dans un dossier n'a besoin d'aucun droit sur une base de données voisine, même si cette base est techniquement accessible depuis le même poste. Restreindre l'accès dès le départ coûte moins cher que de découvrir, après coup, tout ce qu'un accès trop large a permis de lire.

Le filtre trop large, un canal de fuite discret

Une commande qui liste des variables ou interroge une table de configuration pour un motif précis peut afficher, à côté de la valeur cherchée, tout ce qui se trouve juste à côté. Le risque tient à la largeur du filtre. L'exemple suivant crée ses propres données de démonstration, sans toucher à rien de réel sur votre poste :

echo "CLE_API=ax92kQ" > fixture.txt
echo "NOM_SERVEUR=serveur-principal" >> fixture.txt
grep NOM fixture.txt
grep -i "e" fixture.txt

La première commande, filtrée sur NOM, ne renvoie que la ligne attendue. La seconde, filtrée sur la seule lettre e, renvoie les deux lignes, y compris la clé. Rien dans l'intention n'a changé entre les deux commandes, seule la précision du filtre a changé le résultat affiché à l'écran.

La commande nue est un filtre absent

Un filtre trop large n'est pas le seul piège : une commande sans argument, comme env, printenv ou set seul, affiche toutes les variables avec leurs valeurs, secrets compris, et cet affichage entre dans la transcription. Le cas typique naît d'un changement de shell : une commande écrite avec des guillemets pour un shell les perd en passant à un autre, qui exécute alors un set nu. Pour vérifier une variable, mesurez-la au lieu de l'afficher :

CLE_API=ax92kQ sh -c 'echo "longueur : ${#CLE_API}"'

longueur : 6

La longueur suffit à savoir que la variable est posée, sans que sa valeur apparaisse. Dans Claude Code, les transcriptions locales enregistrent désormais aussi le prompt système, les outils et les paramètres de chaque requête : traitez une transcription comme sensible avant de la partager. La rédaction automatique des secrets couvre plus de cas depuis octobre, mais elle vaut pour les transcriptions partagées et les journaux de débogage, pas comme garantie générale.

Filtrer sur ce qui est attendu, jamais sur un motif générique

Avant de lancer une commande qui affiche une configuration, demandez-vous ce que la commande affiche réellement à l'écran. Filtrer sur les noms attendus, ou sur une longueur précise, réduit ce risque bien mieux qu'un filtre par une seule lettre ou un motif trop court. Ce réflexe vaut pour une commande locale comme pour une requête confiée à un agent : demandez lui de filtrer sur des noms précis, jamais sur un motif large qui ratisse tout un ensemble de colonnes ou de variables. La leçon suivante traite ce qui se passe quand un secret finit malgré tout par être écrit dans un dépôt suivi par un outil de version.