Protéger les secrets d'une application

Un secret est une valeur qui donne un accès : mot de passe de base, clé d'API, jeton de bot, clé de session. Sa place n'est ni dans le code source, ni dans un fichier servi par le serveur web, ni dans un journal. La règle de base tient en une phrase : une valeur secrète se configure dans l'environnement et se révoque dès qu'elle a pu fuir.

1. Séparer le code de la configuration

Le code doit fonctionner avec plusieurs environnements sans modification. Lisez les secrets depuis l'environnement et échouez franchement s'ils manquent :

import os

token = os.environ.get("API_TOKEN")
if not token:
    raise SystemExit("API_TOKEN manquant")

Un démarrage refusé est préférable à une application qui tourne avec une valeur vide et échoue plus tard. Sur l'hébergement d'applications, les variables se saisissent dans le panneau. En local, utilisez un fichier .env chargé explicitement, ajouté à .gitignore, et versionnez seulement un .env.example avec des valeurs vides.

2. Éviter les fuites par les journaux

Les journaux sont la fuite la plus fréquente, parce qu'elle est discrète. Une exception de connexion peut inclure l'URL complète avec le mot de passe. Un log.info(os.environ) expose tout. Un jeton placé dans une URL apparaît dans les journaux d'accès et l'historique du navigateur.

• Ne journalisez jamais un dictionnaire d'environnement entier.
• Masquez les valeurs sensibles dans les messages d'erreur.
• Placez les jetons dans un en-tête Authorization, pas dans une query string.
• Vérifiez que les pages d'erreur publiques n'affichent pas de traceback.

3. Réduire les privilèges

Un secret doit ouvrir le minimum de portes :

• un utilisateur de base par application, avec des droits limités à sa base ;
• aucun droit GRANT ni accès aux bases voisines ;
• des portées d'API minimales, pas un jeton administrateur ;
• des jetons distincts par environnement et par service ;
• un compte de messagerie dédié pour les envois automatiques.

Si un composant n'a pas besoin d'écrire, donnez-lui un accès en lecture seule. Cette séparation limite l'impact d'une compromission.

4. Faire tourner un secret

La rotation est une opération planifiée, pas une urgence :

1. Générez une nouvelle valeur avec un gestionnaire de mots de passe ou openssl rand -base64 32.
2. Mettez-la à jour dans le panneau ou le fichier d'environnement.
3. Redémarrez l'application et vérifiez la connexion.
4. Révoquez l'ancienne valeur côté service émetteur.

Si un secret a été poussé dans Git, révoquez-le immédiatement. Réécrire l'historique avec git filter-repo ne suffit pas : des clones, des forks et des caches peuvent conserver l'ancienne valeur.

5. Vérifier

• git grep -nE "(TOKEN|SECRET|PASSWORD|API_KEY)=" ne doit rien renvoyer hors fichier d'exemple.
• .env, les dumps et les archives ne doivent pas être accessibles par HTTP : testez l'URL et attendez un 403 ou 404.
• Les journaux récents ne contiennent ni jeton ni chaîne de connexion.
• Chaque secret actif a un propriétaire, une date de création et une procédure de rotation.

Un secret partagé entre personnes ou entre projets ne peut pas être révoqué proprement : un compte par usage, c'est aussi une question de traçabilité.