L'erreur à ne surtout pas faire dans un dépôt Git public

Récemment, j'ai aidé un développeur débutant qui ne comprenait pas pourquoi son hébergeur avait bloqué ses accès SMTP et pourquoi il recevait des dizaines d'e-mails avec "échec de l'envoi, mauvais destinataire" pour des messages qu'il n'avait pas envoyé.

Après avoir éliminé quelques possibilités, je lui ai fait comprendre qu'il avait envoyé son fichier de configuration par erreur sur son dépôt Git public, lequel contenait les identifiants de connexion à son serveur SMTP.

Si vous pensez que cette pratique est rare, laissez-moi vous dire que je l'ai vu bien des fois se produire, que ce soit chez des débutants par manque de compréhension, ou chez des développeurs plus expérimentés par une faute d’inattention.

C'est une erreur si fréquente que de nombreux robots malveillants parcourent sans cesse les dépôts publics Github à la recherche d'une clé d'API, d'un identifiant ou d'un mot de passe dans les fichiers de configuration ou directement dans le code.

Pour contrer ces robots, certains hébergeurs cloud (notamment AWS) utilisent leur propre bot pour traquer ces clés misent en publique pour les désactiver afin d'éviter tout mauvaise surprise à leur utilisateur.

Les bonnes pratiques

La solution pour éviter toute mésaventure avec ses données de configuration s'appelle les "variables d'environnement".

Les variables d'environnement sont des variables classiques, comme dans la programmation, mais au lieu d'être accessible par un seul logiciel, elles sont disponibles globalement pour tout le système d'exploitation.

L'idée derrière tout ça est de ne jamais partager ces variables de configuration entre vos différents environnements (local, dev, production,...), et surtout pas dans votre dépôt Git.

L'accès à une variable d'environnement va dépendre du langage que vous allez utiliser, par exemple en Javascript (NodeJS), vous devrez faire "process.env.MY_VARIABLE" alors qu'en PHP vous ferez "getenv('MY_VARIABLE')".

Mais avant d'utiliser une variable d'environnement, il va falloir l'initialiser, et pour celà nous avons deux solutions :

Configuration de l'hébergeur

De plus en plus d'hébergeurs cloud proposent de configurer les variables d'environnement directement depuis le panneau d'administration de l'application, c'est notamment le cas pour AWS, Heroku, Clever Cloud et bien d'autres...

Si votre hébergeur propose cette solution, je vous recommande fortement de l'utiliser, car c'est la manière la plus sécurisée. Aucun fichier à déplacer ou à copier, et une fois que ces variables sont définies, vous n'avez plus à y toucher, elles seront toujours là pour tous vos déploiements.

La bibliothèque dotenv

Je recommande l'utilisation de cette bibliothèque soit pour votre environnement de développement local, soit si votre hébergeur ne propose pas la gestion des variables d'environnement dans l'administration.

"dotenv" permet d'injecter les variables d'environnement directement à partir d'un fichier de déclaration normalisé (.env), ce qui permet de faire abstraction du système d'exploitation (Windows a une syntaxe différente pour initialiser une variable d'environnement).

• dotenv en php : https://github.com/vlucas/phpdotenv
• dotenv en javascript : https://www.npmjs.com/package/dotenv

Mais alors il n'y a pas de risque d'ajouter ce fichier dans le dépôt Github ?

Effectivement ce fichier doit absolument rester en dehors de vos commits, même si votre dépôt est privé (c'est plus sûr) et l'idéal est de le déposer vous-même sur chacun des environnements de déploiement sans passer par Git.

Pour être sûr de l'exclure du dépôt Git je vous invite à ajouter simplement .env à votre fichier .gitignore, de cette façon Git ne verra même pas que ce fichier existe !