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

Pour protéger vos clés API, stockez-les comme secrets ou variables d'environnement chez votre hébergeur, utilisez-les uniquement dans du code serveur, et ne les collez jamais dans le chat, les fichiers de code, les captures d'écran ou un dépôt Git. Donnez à chaque clé le minimum de permissions nécessaire, fixez des plafonds de dépense 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 de émettre des remboursements ; votre clé de fournisseur d'e-mails permet d'envoyer des messages en votre nom. Les créateurs d'applications IA savent bien les intégrer, mais ne sont pas toujours attentifs à l'endroit où elles finissent. Ce guide explique donc comment les protéger et comment le vérifier.

Clés publiques et clés secrètes

Toutes les clés ne sont pas secrètes. Savoir les distinguer é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 : stockez les clés comme secrets, pas dans le code

Les clés doivent être dans les variables d'environnement ou les 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, voir 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 que tu as utilisé. Ne montre pas les valeurs.

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

Recherche dans tout le projet, y compris les fichiers de configuration et les fichiers .env, tout ce 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 uniquement côté serveur

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

Ainsi, si l'application 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 fonctionnalité de chat appelle OpenAI directement depuis le navigateur. Déplace cet appel vers une route API serveur qui lit OPENAI_API_KEY dans l'environnement. Le navigateur ne doit appeler que notre route. Exige une connexion pour cette route.

Attention à un piège courant avec les frameworks frontend : 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 donc exposée, même si elle est « dans une variable d'environnement ».

Étape 3 : vérifiez qu'aucune fuite ne subsiste

Ne présumez pas que cela a fonctionné : contrôlez le site en ligne.

1. Ouvrez l'application publiée dans un navigateur.
2. Ouvrez les outils de développement, puis l'onglet Sources ou Réseau.
3. Recherchez 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 que fait l'application. Une requête qui part directement du navigateur vers un fournisseur d'IA payant est un signal d'alerte.

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

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

De nombreux fournisseurs permettent de limiter une clé :

• Clés restreintes ou à portée limitée, qui ne peuvent faire que ce dont votre application a besoin. Stripe, par exemple, prend en charge des clés restreintes avec des permissions précises.
• Restrictions par domaine ou par IP pour les clés qui doivent être publiques, comme les clés de cartes.
• Des clés séparées par application et par environnement, pour qu'une fuite n'expose pas tout et que la révocation d'une clé ne casse pas les autres.
• Des clés de test pendant la construction, et des clés réelles uniquement dans l'application publiée.

Étape 5 : fixez un plafond aux dégâts

Même une clé bien protégée peut être mal utilisée via votre propre application — quelqu'un qui script votre fonctionnalité IA des milliers de fois, par exemple.

• Définissez des plafonds de dépense ou des alertes chez chaque fournisseur payant.
• Exigez une connexion pour toute fonctionnalité qui coûte de l'argent à chaque appel.
• Ajoutez une limite de débit par utilisateur. Voir ce qu'est la limitation de débit.

Ajoute une limite de 30 requêtes IA par utilisateur et par heure sur /api/chat. Renvoie un message clair quand 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 chat, commit, capture d'écran, ticket de support, 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 application.
3. Redéployez ou republiez pour que l'application en ligne utilise la nouvelle clé.
4. Supprimez l'ancienne clé chez le fournisseur.
5. Consultez les journaux d'usage du fournisseur pour repérer toute activité que vous ne reconnaissez pas.

Supprimer le message de chat ou le commit Git ne suffit pas. L'historique Git conserve les anciennes versions, et tout ce qui était public a peut-être déjà été copié.

Erreurs fréquentes

• Coller une clé dans le prompt. Elle se retrouve dans l'historique du chat. Utilisez plutôt un formulaire de secrets.
• Un préfixe public sur une variable secrète. VITE_OPENAI_API_KEY livre 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 application.
• Pas de plafond de dépense. Une clé divulguée ou abusée sans plafond peut générer une grosse facture avant que vous ne le 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 contrôle

• Chaque clé est stocké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 du code serveur.
• Aucune variable secrète ne porte de 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 à portée limitée lorsque le fournisseur le permet.
• Les clés de test et les clés réelles sont séparées.
• Les fonctionnalités payantes exigent une connexion et ont des limites par utilisateur.
• Chaque fournisseur payant a un plafond de dépense ou une alerte.
• Je sais comment changer chaque clé, et toute clé qui a jamais été exposée a été changée.

Protéger vos clés sur Mythex

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

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

Après avoir modifié un secret pour une application publiée, republiez-la pour qu'elle le prenne en compte. Les projets exportés ne contiennent pas les secrets : ajoutez-les à nouveau là où vous exécutez le code. Si une clé apparaît dans le chat, changez-la chez le fournisseur.

Pour le reste du contrôle de sécurité avant lancement, suivez la liste de contrôle de sécurité pour les applications créées par IA. Si vous ajoutez des fonctionnalités IA, comment utiliser les API LLM détaille les clés et les coûts plus en profondeur.

Questions