Clés API exposées : comment vérifier que les vôtres ne le sont pas

Une clé API exposée, c'est un mot de passe laissé à la vue de tous : n'importe qui peut l'utiliser en se faisant passer pour votre application, souvent à vos frais. Pour vérifier, on cherche trois endroits : le code envoyé au navigateur, le dépôt de code, et les messages d'erreur. Si une clé a fuité, on la remplace, on ne se contente pas de la cacher.

Une clé, c'est quoi ?

Quand votre application utilise un service extérieur (paiement, e-mail, IA, cartes), ce service doit savoir que c'est bien vous qui demandez. Vous recevez donc une clé API : une longue suite de caractères qui joue le rôle de carte d'accès. Pour comprendre ce qu'est une API, voir c'est quoi une API.

Pensez à un badge de bureau. Il ouvre les portes, et il est parfois lié à votre compte : tout ce qu'il fait est mis sur votre note. Si quelqu'un le trouve dans la rue, il ne se demande pas à qui il appartient.

Comment une clé devient visible

• Dans le code envoyé au navigateur. Tout ce que le navigateur reçoit peut être lu par n'importe quel visiteur, en quelques clics. Une clé placée dans cette partie du code n'est pas secrète, même si elle est « difficile à trouver ».
• Dans le dépôt de code. Si le projet est publié sur un site de partage de code, une clé écrite dans un fichier y reste. Et même supprimée ensuite, elle reste dans l'historique des versions.
• Dans une capture d'écran, un message ou un tutoriel partagé en confiance.
• Dans un message d'erreur qui affiche trop de détails.

Les outils de génération de code peuvent écrire une clé directement dans le fichier, parce que c'est le plus court chemin pour que « ça marche ».

Toutes les clés ne se valent pas

Certaines clés sont faites pour être publiques : elles n'identifient que votre application, et leur pouvoir est limité par des règles posées de l'autre côté. D'autres, dites secrètes, donnent tous les droits et ne doivent jamais quitter le serveur. La documentation de chaque service dit laquelle est laquelle.

Même une clé publique n'est sûre que si ces règles existent. C'est exactement le cas d'une base de données : voir les règles d'accès à une base de données.

Comment vérifier les vôtres

1. Listez vos services : paiement, e-mail, IA, stockage, cartes, statistiques. Pour chacun, notez où se trouve sa clé.
2. Regardez le code côté navigateur. Avec les outils de développement de votre navigateur, ou avec l'aide d'une personne technique, cherchez le nom de vos services ou le début de vos clés dans les fichiers reçus.
3. Vérifiez le dépôt de code, historique compris, s'il est public ou partagé avec des tiers.
4. Regardez le tableau de bord de chaque service. La plupart indiquent la dernière utilisation d'une clé, et certains envoient une alerte en cas d'usage anormal.

Si une clé a fuité

1. La révoquer et en générer une nouvelle depuis le tableau de bord du service. Seul le remplacement rend l'ancienne inutilisable.
2. Consulter l'activité récente du service pour repérer un usage inhabituel (factures, envois, accès).
3. Placer la nouvelle clé sur le serveur, dans les variables d'environnement, jamais dans le code.
4. Rechercher les autres clés au même endroit : elles ont probablement suivi le même chemin.

Les bonnes habitudes

• les clés secrètes vivent côté serveur, dans des variables d'environnement ;
• une clé par environnement (test et production), pour qu'une fuite de l'une n'ouvre pas l'autre ;
• des droits limités : une clé qui ne fait que lire ne peut pas tout supprimer ;
• un plafond de dépense, quand le service le permet.

C'est aussi l'un des points de la checklist de mise en ligne.

À retenir

Une clé visible est une clé compromise : on la remplace, on la range côté serveur, et on limite ses droits. Cacher ne suffit jamais.

Et pour votre produit ?

Un audit regarde notamment où se trouvent vos clés et ce que chacune permet de faire. Si vous avez un doute sur votre application, parlons-en lors d'un échange de 30 minutes.