Partager des clés API en toute sécurité

Ne collez jamais une clé API dans une messagerie ou un e-mail. Envoyez-la par un lien secret à usage unique : la clé est chiffrée dans votre navigateur, la clé de déchiffrement reste dans la partie du lien située après le #, et la copie stockée est détruite dès la première ouverture. Renouvelez ensuite toute clé qui a déjà été collée en texte en clair.

La suite de ce guide entre dans le détail : pourquoi les canaux habituels ne conviennent pas, la procédure de transmission exacte, que faire quand une clé fuit malgré tout, et les cas où le lien à usage unique n’est pas le bon outil.

Pourquoi est-il risqué d’envoyer une clé API par Slack ou par e-mail ?

Parce que l’un comme l’autre conserve le message tant que quelque chose le garde, et le copie au passage sur chaque appareil et dans chaque export.

• Les deux sont consultables par recherche pour toujours. Une clé partagée en 2023 est la clé d’où partira votre prochain incident. Les attaquants qui s’introduisent dans une messagerie ou une boîte mail d’entreprise y cherchent couramment les chaînes qui ressemblent à des clés API : sk_live, AKIA, ghp_, Bearer.
• Les deux se synchronisent partout. Téléphones, ordinateurs personnels, tablettes : des appareils qui échappent à vos contrôles de sécurité et à votre politique d’effacement à distance.
• Les deux sont exportés. Audits de conformité, procédures judiciaires de communication de pièces et exports d’espace de travail produisent tous des copies de l’historique. Chaque export est un endroit de plus où la clé existe.
• Les deux survivent au départ des personnes. La mission du prestataire se termine ; le fil de messages privés qui contient votre clé Stripe, lui, reste.

Mettre un secret dans l’un de ces outils, c’est accepter qu’il vive partout où le message aboutit, aussi longtemps que quelque chose le conserve. Aucun des deux systèmes n’a été conçu pour oublier.

Avant de partager : réduire la clé

La meilleure transmission est celle où la clé transmise compte à peine. Avant de générer quoi que ce soit, appliquez le principe du moindre privilège à la source :

• Limitez son périmètre. Clés restreintes Stripe, jetons d’accès personnels à granularité fine de GitHub, politiques AWS IAM limitées à des actions et des ressources précises : la plupart des fournisseurs sérieux permettent de créer une clé qui ne fait que la seule chose dont le destinataire a besoin.
• Préférez la lecture seule, sauf si l’écriture est réellement nécessaire.
• Fixez une expiration côté fournisseur quand la plateforme le permet (jetons à granularité fine de GitHub, identifiants temporaires AWS via STS). Même une clé qui a fuité a alors une durée de vie limitée, quoi que vous fassiez ensuite.
• Nommez-la d’après le destinataire (vendor-x-readonly) : dans six mois, la décision de la révoquer se prendra d’un coup d’œil, sans travail d’archéologie.

Avec une clé limitée, en lecture seule et qui expire, la pire fuite possible n’est plus un incident mais un simple désagrément.

La procédure de transmission

1. Générez la clé dans le système d’origine (AWS, Stripe, votre propre API) avec le périmètre minimal, comme indiqué plus haut.
2. Collez-la dans un lien secret à usage unique avec la destruction après lecture activée et l’expiration la plus courte possible : 1 heure est la durée prédéfinie la plus courte, suivie de 24 heures et 7 jours, et le forfait Pro permet une date et une heure personnalisées. Juste le temps de la transmission, pas plus.
3. Ajoutez une phrase de passe, transmise par un autre canal : le lien par e-mail, la phrase de passe par SMS ou en message privé Slack. Dans LinkPilot, la phrase de passe, l’expiration personnalisée et l’historique d’audit sont des fonctions du forfait Pro, à 29 $/mois. Si l’un des canaux fuit, l’attaquant n’a toujours que la moitié du puzzle. (LinkPilot hache la phrase de passe dans le navigateur avec SHA-256 avant l’envoi ; la phrase de passe en clair n’atteint jamais la base de données ni les journaux du serveur, et les tentatives sont limitées à 5 par IP et par minute.)
4. Envoyez le lien.
5. Vérifiez par un autre canal que le destinataire l’a bien récupéré, et consultez l’historique d’audit : une seule ouverture, à l’heure prévue, depuis le lieu prévu. C’est votre accusé de réception.

Si le lien n’est pas ouvert avant l’expiration, révoquez-le et renvoyez-en un nouveau. Ne prolongez pas l’ancien et ne le réutilisez pas.

Exemple : transmettre une clé restreinte Stripe

# generate a restricted key with the minimum needed scopes
stripe api_keys create \
  --restricted \
  --display-name "vendor-x-readonly"

# pipe the resulting key into a LinkPilot secret
curl -X POST https://api.uselinkpilot.com/v1/secrets \
  -H "Authorization: Bearer $LP_KEY" \
  -d 'payload=sk_restricted_…' \
  -d 'expires_in=3600' \
  -d 'burn_after_read=true'

Ce que voit le destinataire : en ouvrant le lien, il arrive sur une page avec un bouton Afficher, pas sur la clé. Les outils d’aperçu de liens et les scanners d’e-mails qui préchargent l’URL n’obtiennent que des métadonnées, car une ouverture n’est enregistrée que sur l’action explicite d’affichage, jamais sur le GET. Quand le destinataire clique sur Afficher (et saisit la phrase de passe, s’il y en a une), il voit la clé une seule fois. Ensuite, la copie stockée est écrasée et le lien renvoie une erreur HTTP 410. Même si l’e-mail circule de transfert en transfert dans toute l’entreprise, seule la première personne à l’ouvrir a pu lire la clé, et l’historique d’audit vous dit de qui il s’agit.

Quel canal pour quelle transmission

Que faire si une clé API fuit ?

Considérez-la comme compromise et renouvelez-la chez le fournisseur ; supprimer le message ne sert à rien. Toute clé passée par un message de messagerie, le corps d’un e-mail, une capture d’écran, un commit git ou un site de partage de texte public est concernée. Dans l’ordre :

1. Émettez d’abord la clé de remplacement, si le fournisseur autorise deux clés actives en même temps. Cela évite une interruption pour les utilisateurs légitimes.
2. Révoquez la clé compromise chez le fournisseur. C’est la seule étape qui met réellement fin à l’exposition ; supprimer le message Slack ne le fait pas.
3. Transmettez la nouvelle clé correctement : lien à usage unique, phrase de passe, expiration courte, selon la procédure ci-dessus.
4. Consultez les journaux d’utilisation du fournisseur pour la clé compromise, entre son exposition et sa révocation. Des appels inattendus signifient qu’il s’agit désormais d’un incident, et plus d’un simple nettoyage.
5. Corrigez la cause du collage : placez le secret dans votre outillage de variables d’environnement exclu par .gitignore, activez l’analyse des secrets chez votre hébergeur de dépôts, ou mettez à jour la procédure qui demandait de l’envoyer en message privé.

L’ensemble doit prendre quelques minutes. Si renouveler une clé fait assez peur pour qu’on l’évite, cette fragilité est la vraie vulnérabilité : corrigez-la en premier.

Ce qu’il faut éviter

• Renvoyer le même secret. Renouvelez-le plutôt. Le renvoyer efface la garantie d’audit d’« une exposition et une seule » qui faisait l’intérêt du lien à usage unique.
• Les expirations longues. Choisissez une durée courte par défaut. La plupart des transmissions se font en quelques minutes ; une fenêtre de 8 heures n’est qu’une fuite plus longue.
• Se passer de la phrase de passe. Elle ne coûte presque rien et protège contre les fuites accidentelles d’URL : e-mails transférés, partages d’écran, regard indiscret par-dessus l’épaule devant un écran partagé.
• Les captures d’écran de clés. Elles finissent dans la galerie photo, la synchronisation des photos dans le cloud et la recherche d’images. Une capture d’écran a la permanence d’un message collé dans une messagerie, avec une recherche moins pratique pour vous et parfaitement pratique pour l’OCR.
• Utiliser l’outil de liens comme stockage. Le lien est le coursier, pas le coffre-fort. Le destinataire doit stocker la clé dans un gestionnaire de mots de passe ou son outillage de variables d’environnement dès qu’il la reçoit.

Quand le lien à usage unique n’est pas le bon outil

Soyons honnêtes, cette méthode a ses limites :

• Les identifiants de machine à machine ont leur place dans un gestionnaire de secrets ou le stockage natif de la plateforme, injectés au déploiement ou à l’exécution. Une personne qui clique sur un lien n’est pas une étape de déploiement.
• Les identifiants partagés de longue durée ont leur place dans un gestionnaire de mots de passe, avec un vrai contrôle d’accès et une révocation personne par personne.
• Le renouvellement très fréquent (des clés qui changent toutes les heures) doit être automatisé de bout en bout ; ni les personnes ni les liens n’ont leur place dans cette boucle.
• Les secrets qu’aucun tiers ne doit toucher, sous aucun prétexte : faites la transmission hors ligne. Mise à jour du 29 septembre 2026 : ce point indiquait à l’origine que LinkPilot ne revendiquait pas le chiffrement de bout en bout et conseillait d’utiliser un outil chiffré de bout en bout. LinkPilot chiffre désormais le texte dans le navigateur, ainsi que les fichiers joints, si bien qu’il ne stocke jamais que du texte chiffré. La page Architecture de sécurité indique précisément ce qui est protégé et ce qui ne l’est pas.

Pour le cas courant, une personne qui transmet un identifiant à une autre personne, une seule fois, le lien à usage unique avec phrase de passe et expiration courte est la méthode simple la plus solide qui existe.

À lire aussi

• Pourquoi les URL divulguent des informations sensibles
• Partager un mot de passe en toute sécurité : 5 méthodes comparées
• Architecture de sécurité de LinkPilot
• Comparatif des API de raccourcisseurs de liens
• Générateur de liens secrets gratuit

Références

• Stripe Docs, API keys: limit access with restricted keys.
• GitHub Docs, Managing your personal access tokens.
• AWS IAM User Guide, Temporary security credentials in IAM.