Clés API et secrets dans les apps générées par IA

Un secret est tout ce qui prouve que ton app ou ton serveur a le droit de faire quelque chose : une clé API, un mot de passe, un jeton, une chaîne de connexion à une base de données. Quand tu construis en écrivant des prompts, il est facile de coller une clé dans le chat pour « que ça marche », et l'outil peut l'écrire directement dans un fichier source. Ce n'est pas un défaut de caractère ; c'est le moyen le plus rapide de faire tourner une démo. Il faut simplement la nettoyer avant publication.

Ce ne sont que des conseils généraux, pas un audit de sécurité.

Pourquoi c'est important

Un package d'app peut généralement être décompressé et lu. Tout ce qui se trouve dans l'app, y compris une clé écrite dans le code, doit être considéré comme lisible par quiconque télécharge l'app. Une clé dans un dépôt de code public est lisible par quiconque trouve ce dépôt.

Ce qui se passe ensuite dépend de la clé : quelqu'un pourrait faire grimper les coûts de ton compte, lire des données ou envoyer des requêtes en ton nom.

Où chercher

Cherche dans tout le projet (fichiers cachés inclus) :

• Des mots comme key, secret, token, password, apikey, Bearer.
• De longues chaînes qui ressemblent à du hasard.
• Des fichiers comme .env, des fichiers de configuration et des fichiers « exemple » qui contiennent de vraies valeurs.
• Des URL de backend qui incluent un mot de passe ou un jeton.
• Ton historique de chat ou de prompts : si tu y as collé une clé, elle a quitté ta machine.
• L'historique du contrôle de version : une clé supprimée aujourd'hui peut encore figurer dans un ancien commit.

Ordre de correction

1. Remplace, ne te contente pas de cacher. Si une clé a jamais été dans du code que tu as partagé, dans un dépôt public ou dans un prompt, crée-en une nouvelle dans le tableau de bord du fournisseur et désactive l'ancienne.
2. Sors le secret de l'app. Le schéma habituel : l'app appelle ton propre petit serveur, et seul le serveur détient la clé. Demande à ton outil de code d'expliquer ce schéma pour ta configuration, puis vérifie toi-même le résultat avec la recherche ci-dessus.
3. Limite ce que peut faire une clé. Beaucoup de fournisseurs permettent de restreindre une clé à une seule app ou de fixer un plafond de dépense. Utilise-le.
4. Garde les fichiers secrets hors du contrôle de version avec une règle d'ignore, et vérifie l'historique.
5. Reconstruis et refais la recherche, cette fois dans le package final de l'app.

Certaines clés sont censées être publiques (par exemple les identifiants d'un service de carte ou d'analyse). Consulte la documentation du fournisseur pour savoir de quel type tu disposes.

Si une clé a déjà été publiée

• Crée une nouvelle clé et désactive d'abord l'ancienne.
• Regarde la page d'usage du fournisseur pour détecter quoi que ce soit d'inattendu.
• Publie une mise à jour de l'app qui utilise la nouvelle configuration.
• Si des données utilisateur ont pu être concernées, vérifie quelles obligations légales s'appliquent ; ce n'est pas un avis juridique.

Ce qu'il ne faut pas promettre

Ne dis pas aux utilisateurs que l'app est « sécurisée » ou « auditée », sauf si une personne qualifiée l'a auditée. Dis ce que tu fais réellement : par exemple, « nous ne stockons pas les mots de passe », seulement si c'est vrai.

Étape suivante

Un regard neuf aide. AppReviewX propose des retours privés et structurés d'autres développeurs, et tu peux demander à un testeur d'essayer des choses qu'un utilisateur normal ne ferait pas. Essaie AppReviewX.

Voir aussi : hub vibe coding, bugs que trouvent les testeurs dans les apps construites par IA, test fermé pour une app vibe-codée.