Configuration, chiffrement et secrets

Configuration, chiffrement et secrets

1. Mauvaise configuration (A02)

   Deuxième risque du classement 2025, et le plus facile à éviter : une configuration par défaut, un mode debug actif, un en-tête manquant.

   • Environnement de production identifié clairement, avec une liste de contrôle avant mise en service.
   • Mode debug et pages d'erreur détaillés désactivés : une trace d'exécution révèle la pile d'appels, la version et les chemins.
   • Compte par défaut supprimé ou changé.
   • Répertoires sensibles (administration, phpmyadmin, console) restreints par adresse.
   • En-têtes HTTP de sécurité : politique de contenu, transport forcé, protection contre le clickjacking, référentiel de politiques.

   Le réflexe : comparer la configuration de production à celle de développement, ligne par ligne. La différence est souvent le paramètre même du problème.

2. Défaillances cryptographiques (A04)

   Le chiffrement ne sert qu'à deux choses : la confidentialité en transit et au repos, et l'intégrité. Tout le reste est du folklore.

   • En transit : TLS partout, y compris entre services internes. Le réseau interne n'est pas un réseau de confiance.
   • Au repos : base de données, sauvegardes, objet stocké.
   • Les mots de passe ne se chiffrent pas : ils se hachent, avec un algorithme lent et un sel par utilisateur.
   • Le secret ne se dérive pas du reste : une clé déduite du mot de passe est une clé faible.

   Deux erreurs classiques : faire sa propre cryptographie, et réutiliser un mode de chiffrement sur toutes les données. Quand on emploie une bibliothèque éprouvée, on lit ce qu'elle documente sur le mode d'emploi, et on ne le change pas au hasard.

3. Gestion des secrets

   Un secret est toute valeur qui donne un accès : mot de passe, jeton, clé, certificat. Sa fuite est presque toujours due à trois erreurs.

   1. Secret dans le dépôt : même supprimé ensuite, il reste dans l'historique et dans les clones. Le changer est la seule action qui vaut.
   2. Secret en clair dans la configuration : il faut une source externe : coffre à secrets du fournisseur, coffre de l'hébergeur, gestionnaire de secrets — et une injection à l'exécution.
   3. Secret dans les journaux : un secret écrit dans une trace est compromis, même si la trace est supprimée ensuite.

   La règle de lecture : un secret ne doit jamais pouvoir être lu depuis le code, jamais apparaître dans un journal, et pouvoir être changé sans redéploiement de l'application.

4. Exercices

   1. Liste de contrôle : écrivez la liste de configuration de votre environnement de production, et vérifiez-la ligne par ligne.
   2. Inventaire des secrets : listez tous les secrets utilisés par votre application, et indiquez pour chacun où il est stocké et s'il apparaît dans un journal.
   3. Rotation : décrivez la procédure de rotation d'un secret, et vérifiez qu'elle peut être exécutée sans redéploiement complet.