Hardcoded Credentials

Définition

Les Hardcoded Credentials (credentials codés en dur) désignent des mots de passe, clés API, tokens d'accès, certificats ou autres secrets d'authentification directement écrits dans le code source d'une application, les fichiers de configuration versionnés, ou les scripts de déploiement. Cette pratique constitue l'une des vulnérabilités de sécurité les plus répandues et les plus dangereuses dans les applications modernes, classée systématiquement dans les listes CWE Top 25 (CWE-798 : Use of Hard-coded Credentials). Le risque posé par les credentials hardcodés est maximal : le code source est potentiellement accessible à de nombreux développeurs, est versionné dans des systèmes de contrôle de version qui conservent l'historique (y compris les suppressions), peut être involontairement exposé (dépôts GitHub publics accidentels, partage de snippets), et peut être extrait d'artefacts compilés par décompilation ou analyse binaire. Des études régulières révèlent des centaines de milliers de secrets actifs exposés sur GitHub public. Les origines des credentials hardcodés sont multiples. Les raccourcis de développement ("je mets ça temporairement, je changerai avant le commit"), la méconnaissance des alternatives sécurisées (variables d'environnement, secrets managers), les projets legacy avec peu de discipline sécurité, les scripts d'automatisation où la commodité est privilégiée, et les projets open source où des secrets de test ou de développement sont commités par erreur. La détection des credentials hardcodés utilise plusieurs approches complémentaires : outils de secret scanning (GitLeaks, TruffleHog, detect-secrets) dans les pre-commit hooks et pipelines CI, revue de code avec focus sécurité, formation des développeurs aux patterns d'identification (chaînes base64, patterns de clés API, chaînes de connexion), et audit de l'historique Git des dépôts existants. La remédiation d'un credential hardcodé déjà commité dans l'historique Git requiert non seulement de remplacer le secret dans le code, mais aussi de purger l'historique Git (via git-filter-repo ou BFG Repo-Cleaner) ET de révoquer/tourner immédiatement le secret exposé, car la suppression du fichier ne supprime pas l'historique accessible aux personnes ayant déjà cloné le dépôt.