Protéger ses clés d'API

Votre clé d'API autorise tout ce que ses permissions couvrent — et une clé créée avec tous les droits peut créer des liens, lire vos transactions, émettre des remboursements. Il n'y a ni second facteur ni confirmation. C'est un secret au sens plein du terme. Première protection, avant même le coffre : n'accordez à chaque clé que les permissions que votre intégration appelle réellement.

Les cinq règles

Une clé vit sur un serveur, jamais dans un navigateur. Pas dans du JavaScript côté client, pas dans une application mobile — un fichier .apk se décompile en quelques secondes. Si votre front a besoin de déclencher un paiement, il appelle *votre* backend, qui appelle le nôtre.

Une clé vit dans une variable d'environnement ou un coffre, jamais dans le code. Même dans un dépôt privé : les dépôts changent de statut, les collaborateurs changent d'employeur, les sauvegardes se copient.

Une clé de test et une clé de production sont deux choses différentes. Le préfixe le dit — chari_sk_test_ contre chari_sk_live_ — et l'environnement est déterminé par la clé elle-même. C'est précisément ce qui rend impossible d'envoyer par erreur un test en production.

Une clé ne s'écrit pas dans un journal. Attention aux traceurs d'erreurs et aux outils d'observabilité qui capturent les en-têtes HTTP : c'est la fuite la plus courante, et la plus discrète, car le secret se retrouve chez un tiers sans que personne ne l'ait décidé.

Une clé ne se partage pas par messagerie. Ni par e-mail, ni sur Slack, ni par WhatsApp. Ces canaux conservent, indexent et sauvegardent.

Ce qui arrive vraiment

Le scénario que nous voyons le plus n'est pas une attaque. C'est un développeur pressé qui met la clé dans un fichier de configuration « juste pour tester », qui oublie, et qui pousse. Le dépôt est privé, donc « ce n'est pas grave ». Six mois plus tard il devient public, ou un prestataire y accède, ou une sauvegarde atterrit ailleurs.

Le second scénario le plus courant est le fichier .env committé le premier jour du projet, quand personne n'avait encore écrit le .gitignore.

Si une clé a fuité

Dans l'ordre, et sans attendre :

1. 1Révoquez-la. Une clé compromise n'est pas une clé à surveiller, c'est une clé à supprimer. Créez la remplaçante d'abord si vous voulez éviter une coupure, mais ne différez pas la révocation.
2. 2Considérez tout l'historique comme exposé. Retirer le fichier du dépôt ne suffit pas : il reste dans l'historique git, et l'historique se clone.
3. 3Regardez ce qui a été fait avec. Le journal des opérations vous dit ce qui a été créé, lu et remboursé, et à quel moment.
4. 4Corrigez la cause. Un .gitignore, un scan de secrets à la validation, un coffre — sinon cela recommencera.

La rotation planifiée

La rotation d'une clé ne devrait jamais être un événement — c'est un entretien. Une clé qu'on n'a jamais fait tourner est une clé qu'on ne sait pas faire tourner, et ce savoir-faire se découvre toujours au pire moment : pendant une fuite.

Le geste est simple parce que deux clés peuvent coexister le temps de la bascule : créez la nouvelle, déployez-la, vérifiez que le trafic passe, révoquez l'ancienne. Aucune interruption. Faites-le une première fois sans urgence, notez la procédure — quel secret, dans quel gestionnaire, déployé comment — et mettez une échéance au calendrier. Deux fois par an suffit ; l'important n'est pas la fréquence, c'est que le muscle existe.

La rotation force aussi une découverte utile : la liste réelle des endroits où la clé vit. Si la bascule casse un service dont personne ne se souvenait, vous venez d'apprendre quelque chose qui aurait coûté bien plus cher pendant un incident.

Les clés dans une équipe

À deux développeurs, la clé se partage de la main à la main. À dix, elle finit dans un canal Slack, un wiki, un fichier « temporaire » — et chacun de ces endroits est une fuite en préparation.

Trois règles tiennent une équipe :

• Un seul lieu de vérité : le gestionnaire de secrets. Une clé qui circule ailleurs est considérée comme compromise, par principe.
• La CI a sa propre clé. Les tests d'intégration continue tournent sur la sandbox, avec une clé dédiée que la rotation peut sacrifier sans toucher à la production.
• Le départ d'un membre déclenche une rotation. Non par défiance — parce qu'un poste de travail rendu, un portable personnel, un gestionnaire de mots de passe individuel sont autant d'endroits que vous ne contrôlez plus.

Et une habitude qui ne coûte rien : les clés de production ne s'affichent jamais à l'écran en entier. Le portail les tronque après création ; vos outils internes devraient faire pareil.

Le bon réflexe au démarrage

Avant même votre premier appel, ajoutez .env et .env.local à votre .gitignore, et vérifiez qu'aucun n'est déjà suivi par git. C'est trente secondes au démarrage d'un projet, et cela évite la seule catégorie d'incident de sécurité qui soit à la fois banale et coûteuse.

Le portail affiche la clé complète une seule fois, à sa création — copiez-la immédiatement dans un coffre. Elle n'est jamais réaffichée ensuite, ni envoyée par e-mail. Cette contrainte est volontaire : une clé qu'on peut relire est une clé qu'on finit par relire dans un endroit qu'on ne contrôle pas.