Comment protéger vos clés API dans votre app

Pour protéger vos clés API, conservez-les comme secrets ou variables d’environnement chez votre hébergeur, utilisez-les seulement dans le code serveur, et ne les collez jamais dans le clavardage, les fichiers de code, les captures d’écran ou un dépôt Git. Accordez à chaque clé le minimum de permissions dont elle a besoin, fixez des plafonds de dépenses chez le fournisseur et, si une clé fuit, changez-la (créez-en une nouvelle et supprimez l’ancienne) plutôt que de simplement la cacher là où elle est apparue.

Une clé API est un mot de passe pour un service. Votre clé OpenAI permet à quelqu’un de dépenser votre argent en IA; votre clé secrète Stripe permet d’émettre des remboursements; votre clé de fournisseur de courriel permet d’envoyer des messages en votre nom. Les créateurs d’apps IA savent bien intégrer ces clés, mais ne font pas toujours attention à l’endroit où elles finissent. Ce guide explique comment les protéger et comment vérifier.

Clés publiques et clés secrètes

Toutes les clés ne sont pas secrètes. Savoir faire la différence vous évite de paniquer pour la mauvaise et de négliger la bonne.

Si vous ne savez pas à quel type appartient une clé, consultez la documentation du fournisseur. En cas de doute, traitez-la comme secrète.

Étape 1 : Conservez les clés comme secrets, pas dans le code

Les clés doivent se trouver dans les variables d’environnement ou les paramètres de secrets de votre hébergeur. Votre code les lit par leur nom à l’exécution (par exemple process.env.OPENAI_API_KEY), si bien que la valeur n’apparaît jamais dans vos fichiers. Pour le contexte, consultez ce que sont les variables d’environnement et les secrets.

Déplace chaque clé API hors du code vers des variables d’environnement. Liste chaque clé trouvée, le fichier où elle se trouvait et le nom de variable utilisé. N’affiche pas les valeurs.

Vérifiez ensuite qu’il n’en reste aucune :

Cherche dans tout le projet, y compris les fichiers de configuration et tout fichier .env, quoi que ce soit qui ressemble à une clé API ou à un mot de passe. Indique le fichier et la ligne, pas la valeur.

Étape 2 : Utilisez les clés secrètes seulement côté serveur

C’est la règle la plus importante. Tout ce que reçoit le navigateur peut être lu par un visiteur : le code source de la page et les fichiers JavaScript sont visibles dans les outils de développement.

Ainsi, si l’app doit appeler OpenAI, le navigateur doit appeler votre serveur, et votre serveur appelle OpenAI avec la clé. La clé ne quitte jamais le serveur.

La fonction de clavardage appelle OpenAI directement depuis le navigateur. Déplace cet appel vers une route d’API serveur qui lit OPENAI_API_KEY depuis l’environnement. Le navigateur doit seulement appeler notre route. Exige une connexion pour la route.

Surveillez un piège fréquent dans les cadres frontaux : les variables avec un préfixe public (VITE_ dans Vite, NEXT_PUBLIC_ dans Next.js) sont intégrées au code du navigateur, volontairement. Une clé secrète avec l’un de ces préfixes est exposée, même si elle se trouve « dans une variable d’environnement ».

Étape 3 : Testez qu’aucune fuite n’existe

Ne présumez pas que cela a fonctionné : vérifiez le site en ligne.

1. Ouvrez l’app publiée dans un navigateur.
2. Ouvrez les outils de développement, puis l’onglet Sources ou Réseau.
3. Cherchez dans les fichiers les premiers caractères de chaque clé secrète (par exemple sk_ ou sk-).
4. Vérifiez les requêtes réseau de l’app. Une requête qui va directement du navigateur vers un fournisseur d’IA payant est un signal d’alarme.

Si vous trouvez une clé secrète, déplacez-la côté serveur (étape 2) et changez-la (étape 6), car elle était déjà publique.

Étape 4 : Restreignez ce que chaque clé peut faire

Beaucoup de fournisseurs permettent de limiter une clé :

• Des clés à portée ou restreintes, qui ne peuvent faire que ce dont votre app a besoin. Stripe, par exemple, prend en charge les clés restreintes avec des permissions précises.
• Des restrictions de domaine ou d’adresse IP pour les clés qui doivent être publiques, comme les clés de carte.
• Des clés distinctes par app et par environnement, pour qu’une fuite n’expose pas tout et que la révocation d’une clé n’affecte pas les autres.
• Des clés de test pendant la construction, et des clés réelles seulement dans l’app publiée.

Étape 5 : Limitez les dégâts possibles

Même une clé bien protégée peut être mal utilisée à travers votre propre app : quelqu’un pourrait, par exemple, lancer des milliers d’appels à votre fonction d’IA par script.

• Fixez des plafonds de dépenses ou des alertes chez chaque fournisseur payant.
• Exigez une connexion pour toute fonction qui coûte de l’argent à chaque appel.
• Ajoutez une limite de requêtes par utilisateur. Consultez ce qu’est la limitation de débit.

Ajoute une limite de 30 requêtes d’IA par utilisateur et par heure à /api/chat. Renvoie un message clair lorsque la limite est atteinte. Rejette les requêtes des utilisateurs non connectés.

Étape 6 : Changez les clés qui fuient

Si une clé secrète apparaît à un endroit où elle ne devrait pas être (message de clavardage, commit, capture d’écran, billet de soutien, code du navigateur), considérez-la comme compromise.

1. Créez une nouvelle clé chez le fournisseur.
2. Mettez à jour le secret dans les paramètres de votre app.
3. Redéployez ou publiez de nouveau pour que l’app en ligne utilise la nouvelle clé.
4. Supprimez l’ancienne clé chez le fournisseur.
5. Vérifiez les journaux d’utilisation du fournisseur pour détecter toute activité que vous ne reconnaissez pas.

Supprimer le message de clavardage ou le commit Git ne suffit pas. L’historique Git conserve les anciennes versions, et tout ce qui était public a pu être copié.

Erreurs courantes

• Coller une clé dans la consigne. Elle se retrouve maintenant dans l’historique du clavardage. Utilisez plutôt un formulaire de secrets.
• Un préfixe public sur une variable secrète. VITE_OPENAI_API_KEY envoie la clé à chaque visiteur.
• Committer un fichier .env. Assurez-vous qu’il figure dans .gitignore avant le premier envoi.
• Une seule clé partout. Utilisez des clés distinctes pour les tests et la production, et pour chaque app.
• Aucun plafond de dépenses. Une clé divulguée ou mal utilisée, sans plafond, peut générer une grosse facture avant que vous ne la remarquiez.
• Cacher au lieu de changer. Une fois qu’une clé a été exposée, seule une nouvelle clé règle le problème.
• Des clés dans les captures d’écran. Recadrez ou floutez les pages de paramètres avant de les partager pour obtenir de l’aide.

Liste de vérification

• Chaque clé est conservée comme secret ou variable d’environnement, pas dans le code.
• Aucun fichier .env ni aucune clé n’est committé dans Git.
• Les clés secrètes ne sont utilisées que dans le code serveur.
• Aucune variable secrète n’utilise un préfixe public comme VITE_ ou NEXT_PUBLIC_.
• J’ai cherché dans le JavaScript du site en ligne le préfixe de chaque clé et je n’ai rien trouvé.
• Les clés sont restreintes ou limitées là où le fournisseur le permet.
• Les clés de test et les clés réelles sont séparées.
• Les fonctions payantes exigent une connexion et ont des limites par utilisateur.
• Chaque fournisseur payant a un plafond ou une alerte de dépenses.
• Je sais comment changer chaque clé, et toute clé qui a déjà été exposée a été changée.

Protéger vos clés dans Mythex

Mythex garde les clés hors de votre code et du clavardage de deux façons :

• Carte de demande de secrets. Lorsque l’agent a besoin d’une clé, il affiche une carte dans le clavardage où vous saisissez la valeur dans des champs de formulaire, et non dans la zone de message; elle est alors conservée comme secret du projet. Consultez Secrets dans le clavardage.
• Paramètres du projet → Secrets, ou /secrets dans le clavardage, pour ajouter ou modifier des clés vous-même. Consultez Variables d’environnement et secrets.

Après avoir modifié un secret d’une app publiée, publiez de nouveau pour que l’app en ligne le prenne en compte. Les projets exportés ne contiennent pas les secrets; ajoutez-les de nouveau là où vous exécutez le code la prochaine fois. Si une clé apparaît jamais dans le clavardage, changez-la chez le fournisseur.

Pour le reste de la vérification de sécurité avant lancement, suivez la liste de contrôle de sécurité pour les apps créées par IA. Si vous ajoutez des fonctions d’IA, comment utiliser les API de LLM couvre plus en détail les clés et les coûts.

Questions