Clés API exposées : comment protéger votre application vibe codée ?

Parmi les failles que nous rencontrons dans les applications créées avec l’IA, celle-ci est à la fois l’une des plus fréquentes et l’une des plus coûteuses : une clé secrète visible par n’importe qui. En quelques minutes, une personne mal intentionnée peut l’utiliser pour faire exploser votre facture d’IA, envoyer des milliers d’e-mails en votre nom ou accéder à toute votre base de données.

La bonne nouvelle, c’est que ce problème se repère et se corrige assez facilement. Voyons ce qu’est une clé API, comment elle se retrouve exposée, et comment protéger votre application.

Une clé API, c’est quoi ?

Quand votre application utilise un service extérieur, comme Stripe pour les paiements, un service d’envoi d’e-mails, une IA comme celle d’OpenAI ou d’Anthropic, ou encore votre base de données, elle doit prouver qu’elle en a le droit. Elle présente pour cela une clé, une longue suite de caractères fournie par le service. C’est un badge d’accès : quiconque le possède peut agir comme s’il était votre application, et c’est vous qui payez.

Si ces notions sont encore floues, notre article sur ce que l’IA a construit pour vous explique le rôle des API dans une application.

Clés publiques et clés secrètes

Toutes les clés ne se valent pas. Certains services fournissent deux types de clés :

• des clés publiques, prévues pour être visibles dans l’interface, avec des droits très limités. C’est le cas de la clé « publishable » de Stripe ou de la clé « anon » de Supabase ;
• des clés secrètes, qui donnent un accès complet à votre compte. C’est le cas de la clé « secret » de Stripe, de la clé « service_role » de Supabase ou des clés des services d’IA.

Le nom de la clé donne souvent un indice : chez Stripe, les clés secrètes commencent par « sk_ », et les clés publiques par « pk_ ». En cas de doute, considérez la clé comme secrète.

Comment une clé se retrouve exposée

Dans les applications créées avec l’IA, les fuites suivent presque toujours les mêmes chemins.

Directement dans le code de l’interface

Vous demandez à l’IA de connecter un service, vous collez la clé dans la conversation, et l’IA l’insère là où c’est le plus simple : dans le code qui s’exécute dans le navigateur. L’application fonctionne, mais la clé est lisible par toute personne qui ouvre les outils de développement de son navigateur.

Dans une variable « publique »

Certaines technologies distinguent les variables d’environnement destinées au navigateur par un préfixe, comme « VITE_ » ou « NEXT_PUBLIC_ ». Une clé secrète rangée sous ce préfixe semble protégée, mais elle est en réalité envoyée à chaque visiteur.

Dans un dépôt de code

Une clé écrite dans un fichier de code finit dans GitHub, avec tout l’historique du projet. Même supprimée ensuite, elle reste lisible dans les anciennes versions. Des robots parcourent en permanence les dépôts publics à la recherche de clés, et les exploitent en quelques minutes.

Dans une conversation ou une capture d’écran

Une clé collée dans un message à un prestataire, dans un ticket de support ou visible sur une capture d’écran partagée est, elle aussi, une clé exposée.

Ce que coûte une clé exposée

Les conséquences dépendent du service concerné :

• une clé d’IA permet de générer du contenu à vos frais, parfois des milliers d’euros en quelques heures ;
• une clé d’envoi d’e-mails permet d’envoyer du spam en votre nom, ce qui peut faire bloquer votre domaine ;
• une clé de paiement donne accès à vos transactions et aux informations de vos clients ;
• la clé « service_role » de Supabase contourne toutes les règles d’accès : c’est votre base de données entière qui est ouverte.

Dans ce dernier cas, s’il s’agit de données personnelles, la fuite peut devoir être déclarée à la CNIL dans les 72 heures. Nous en parlons dans notre article sur le RGPD.

Vérifier votre application

Vous pouvez faire un premier contrôle sans compétence technique :

1. listez les services extérieurs utilisés par votre application, en le demandant à l’IA de votre outil et en précisant de ne rien modifier ;

2. pour chacun, demandez-lui où est rangée la clé et si elle est accessible depuis le navigateur ;

3. ouvrez votre application, puis les outils de développement de votre navigateur, et recherchez dans les fichiers des mots comme « sk_ », « secret » ou « service_role » ;

4. si votre code est sur GitHub, vérifiez que les alertes de détection de secrets sont activées ;

5. consultez la consommation de chaque service : une hausse inexpliquée est souvent le premier signe d’une fuite.

Protéger vos clés durablement

La bonne organisation est toujours la même : l’interface demande une action au serveur, et c’est le serveur qui appelle le service extérieur avec la clé secrète. Avec Supabase, cela passe par exemple par des « Edge Functions » ; avec d’autres outils, par une fonction côté serveur. Ensuite :

• rangez les clés dans les variables d’environnement ou l’espace « secrets » de votre outil et de votre hébergement, jamais dans le code ;
• donnez à chaque clé uniquement les droits dont elle a besoin ;
• fixez des plafonds de dépenses et des alertes chez les fournisseurs qui le permettent ;
• utilisez des clés différentes pour vos tests et pour la version en ligne ;
• renouvelez les clés quand un prestataire ou un collaborateur quitte le projet.

Que faire en cas de fuite

Si vous découvrez qu’une clé secrète a été exposée, agissez dans cet ordre :

1. désactivez immédiatement la clé dans le tableau de bord du fournisseur, et créez-en une nouvelle ;

2. mettez à jour votre application avec la nouvelle clé, rangée au bon endroit cette fois ;

3. consultez l’historique d’utilisation du service pour repérer toute activité anormale ;

4. si des données personnelles ont pu être consultées, évaluez la situation rapidement : une violation de données doit être signalée à la CNIL dans les 72 heures quand elle présente un risque pour les personnes ;

5. corrigez la cause, pour que la prochaine clé ne prenne pas le même chemin.

Pas besoin de paniquer : une fuite détectée et traitée vite a généralement des conséquences limitées.

En résumé

Une clé API est un badge d’accès à un service. Les clés publiques peuvent être visibles, mais les clés secrètes doivent rester sur le serveur, dans des variables d’environnement, et jamais dans l’interface, un dépôt de code ou une conversation. Vérifiez où sont rangées les vôtres, limitez leurs droits et fixez des plafonds de dépenses. En cas de fuite, désactivez la clé, remplacez-la et contrôlez ce qui s’est passé. Si vous préférez qu’un développeur vérifie tout cela pour vous, c’est l’un des premiers points que nous contrôlons lors d’une relecture. Dans le prochain article, nous verrons si votre application est conforme au RGPD.