Toute application web manipule des informations sensibles : le mot de passe de la base de données, la clé de l'API de paiement, les identifiants du serveur d'e-mails, les clés de chiffrement des sessions. Si ces secrets tombent entre de mauvaises mains, c'est toute l'application qui est compromise. La gestion des secrets est pourtant l'un des sujets les plus souvent négligés dans les projets que je reprends.
L'erreur la plus fréquente : les secrets dans le code
Le scénario classique est le suivant : pour aller vite, le développeur écrit le mot de passe de la base directement dans un fichier de configuration, puis ce fichier est envoyé dans le dépôt git avec le reste du code. Le secret se retrouve alors copié sur chaque poste de développement, chez chaque prestataire, dans chaque sauvegarde, et parfois même sur une plateforme publique.
Le plus piégeux, c'est que supprimer le fichier ensuite ne suffit pas : git conserve tout l'historique. Un secret qui a été versionné une fois doit être considéré comme compromis et changé.
Le principe : séparer le code et la configuration
La bonne pratique, largement adoptée, consiste à placer les secrets dans des variables d'environnement, généralement regroupées dans un fichier .env propre à chaque serveur. Le code lit ces variables au démarrage, sans jamais contenir lui-même les valeurs.
Dans le dépôt, on ne versionne qu'un modèle, souvent nommé .env.example, qui liste les variables attendues avec des valeurs vides. Le vrai fichier .env est exclu de git grâce au fichier .gitignore. Chaque environnement, développement, préproduction ou production, possède ainsi ses propres valeurs.
Les règles d'une bonne gestion des secrets
Au-delà du fichier .env, voici les règles que j'applique systématiquement :
- Jamais de secret dans git, ni dans le code, ni dans un fichier de configuration versionné ;
- Des droits d'accès stricts : le fichier de secrets n'est lisible que par l'utilisateur du site sur le serveur ;
- Des secrets différents par environnement : la clé de production ne doit jamais servir en développement ;
- Des secrets robustes et aléatoires, générés par un outil, jamais inventés à la main ;
- Une rotation régulière, et immédiate en cas de doute ou de départ d'un intervenant ;
- Une traçabilité : savoir qui a consulté ou modifié quel secret, et quand.
Les coffres de secrets
Pour les équipes plus importantes, des outils dédiés appelés coffres de secrets centralisent les valeurs, les chiffrent, gèrent les droits d'accès par personne et conservent un historique des modifications. Les secrets ne transitent plus par des messages ou des documents partagés.
J'ai d'ailleurs intégré ce type de fonctionnement dans l'outil d'administration que j'utilise pour les sites de mes clients : chaque projet a son fichier de variables géré depuis l'interface, avec des valeurs masquées par défaut, un historique des versions et un journal de chaque consultation.
Détecter les secrets qui ont fuité
Des outils analysent automatiquement les dépôts git pour repérer les clés et mots de passe qui y auraient été envoyés par erreur. Les grandes plateformes d'hébergement de code proposent cette détection, et l'OWASP publie un guide complet sur la gestion des secrets qui détaille les bonnes pratiques.
Sur les serveurs que je gère, un contrôle quotidien vérifie qu'aucun projet ne contient de secret écrit en dur dans le code ou versionné dans git, et qu'aucun fichier sensible n'est lisible par les autres comptes du serveur.
Que faire en cas de fuite
Si un secret a été exposé, la réaction doit être rapide : générer une nouvelle valeur, la déployer, révoquer l'ancienne, puis vérifier dans les journaux qu'elle n'a pas été utilisée de façon suspecte. Ensuite seulement, on nettoie le dépôt et on corrige le processus qui a permis la fuite.
Mon conseil
Faites aujourd'hui un petit audit : vos mots de passe de base de données et vos clés d'API sont-ils écrits dans votre code ou dans votre dépôt git ? Si oui, déplacez-les dans un fichier .env exclu du versionnement, puis changez-les. La gestion des secrets n'est pas un luxe réservé aux grandes entreprises : c'est une hygiène de base que tout projet web devrait respecter.
