Secrets dans le code : quels risques, quelles règles ?
En bref
Un secret est une valeur qui autorise un accès : mot de passe de base de données, clé d'API, jeton de service. Écrit dans le code, il se retrouve dans l'historique du projet, dans les copies et parfois en ligne. Il doit être stocké hors du code, dans un coffre ou une variable d'environnement, avec des valeurs différentes par environnement et un renouvellement possible à tout moment.
Pour fonctionner, une application a besoin de s'authentifier auprès d'autres systèmes : sa base de données, un service d'envoi d'e-mails, une plateforme de paiement. Chacun de ces accès repose sur un secret, c'est-à-dire une valeur qui vaut autorisation. La tentation est grande de l'écrire directement dans le code, là où il sera commodément disponible. C'est précisément ce qu'il faut éviter.
Pourquoi un secret dans le code est un problème
- Il se duplique : chaque copie du projet, chaque sauvegarde et chaque poste de développeur en contient un exemplaire.
- Il reste dans l'historique : supprimer la ligne ne suffit pas, la version précédente demeure consultable dans l'outil de gestion de versions.
- Il suit le code partout : envoyé à un prestataire pour une expertise, publié par erreur dans un dépôt accessible, joint à un ticket d'assistance.
- Il devient impossible à changer sereinement : personne ne sait combien d'endroits utilisent la même valeur.
- Il est parfois exposé directement : un fichier de configuration placé dans un répertoire public se télécharge d'un simple clic.
Où ranger les secrets
| Solution | Fonctionnement | Quand l'utiliser |
|---|---|---|
| Variables d'environnement | La valeur est fournie au programme au démarrage, sans figurer dans les fichiers du projet. | Cas courant, simple à mettre en place sur un hébergement. |
| Fichier de configuration hors du dépôt | Un fichier local, exclu de la gestion de versions et placé hors du répertoire public. | Applications simples, si les droits sur le fichier sont restreints. |
| Coffre à secrets | Un service dédié distribue les valeurs aux applications autorisées et journalise les accès. | Plusieurs applications, plusieurs environnements, renouvellement fréquent. |
| Coffre d'équipe | Les secrets partagés entre personnes sont conservés dans un gestionnaire de mots de passe. | Pour l'usage humain, jamais pour l'accès automatique d'un programme. |
Les règles à tenir
- Un secret différent par environnement : préproduction et production ne partagent aucune valeur.
- Un secret par usage, pour pouvoir en révoquer un sans tout interrompre.
- Des droits limités : une clé qui sert à lire n'a pas besoin d'autoriser la suppression.
- Un renouvellement prévu : la procédure de remplacement doit exister et avoir été testée avant l'urgence.
- Aucun secret dans un message : ni e-mail, ni messagerie instantanée, ni ticket. Passez par le coffre partagé.
- Une détection automatique : des outils analysent le code déposé et signalent les valeurs ressemblant à une clé.
Un secret a fuité : que faire
Considérez-le comme compromis dès qu'il a pu être vu, même brièvement. L'ordre des opérations est simple : créer une nouvelle valeur, la déployer, puis révoquer l'ancienne pour éviter une coupure. Vérifiez ensuite dans les journaux du service concerné si la clé a été utilisée depuis une origine inhabituelle, et retirez la valeur des endroits où elle traîne encore. Si des données personnelles ont pu être atteintes, appliquez la procédure décrite dans notre article sur la violation de données personnelles.
Le cas des applications mobiles et du code envoyé au navigateur
Tout ce qui est livré au visiteur peut être lu par lui, y compris le code d'une application installée sur un téléphone. Une clé qui autorise une opération sensible ne doit donc jamais s'y trouver : l'appel passe par votre serveur, qui détient le secret et vérifie les droits. Les clés publiques prévues pour cet usage par certains services font exception, à condition d'être restreintes à votre domaine.
NexSecure applique ces règles dans ses projets de développement web sur mesure.
Questions fréquentes
Suffit-il de retirer le secret du code ?
Non. S'il a été enregistré dans l'outil de gestion de versions, il reste lisible dans l'historique. Changez la valeur, puis nettoyez l'historique si le dépôt a été partagé. Le remplacement est la seule mesure réellement efficace.
Une variable d'environnement est-elle sûre ?
Elle est nettement préférable au code, mais reste lisible par les processus de la machine et peut apparaître dans des messages d'erreur. Pour des secrets nombreux ou très sensibles, un coffre dédié apporte en plus la journalisation des accès.
À quelle fréquence renouveler une clé ?
Systématiquement au départ d'une personne qui y avait accès, après tout soupçon d'exposition, et à intervalle régulier pour les accès les plus sensibles. L'essentiel est que la procédure soit rodée, pas qu'elle suive un calendrier précis.
Comment partager un secret avec un prestataire ?
Par un coffre partagé donnant un accès nominatif et révocable, ou par un lien à usage unique et à durée limitée. Évitez l'e-mail et la messagerie instantanée, qui conservent la valeur dans des historiques nombreux.
Sources
Service lié
Articles liés
Rédigé par l'équipe NexSecure. Responsable de la publication : Yohann Toumine. Dernière mise à jour le 11 septembre 2026.
Une question sur votre situation ? Parler de votre projet