Comment gérer les secrets (clés API, mots de passe) dans un projet ?
posée 4 months ago580 vuesfr
Nos clés API sont dans le code et dans le dépôt Git privé. « C'est privé, donc ça va », dit un collègue. A-t-il raison ?
Diagnostic IA
Généré par IA. Ce n'est pas une réponse — la communauté ci-dessous le confirme ou le corrige. Vérifiez toujours avant de vous y fier.
1 réponse
Non. Un dépôt privé n'est pas un coffre-fort : - tous ceux qui ont accès au dépôt (anciens employés, prestataires, CI, outils tiers) ont les clés ; - les dépôts fuient : un compte compromis, une erreur de visibilité, un fork, un clone sur un portable volé ; - l'historique Git garde les secrets pour toujours, même après suppression ; - tu ne peux pas avoir des clés différentes par environnement.
Bonnes pratiques : 1. Secrets dans des variables d'environnement, avec .env dans .gitignore et un .env.example sans valeurs réelles versionné. 2. En production : le gestionnaire de secrets de la plateforme (AWS Secrets Manager, Azure Key Vault, les secrets GitHub Actions, les variables chiffrées de Vercel/Render, Doppler, Infisical…). 3. Clés distinctes par environnement (dev, staging, prod), avec le moindre privilège. 4. Rotation régulière, et immédiate au départ d'une personne ou en cas de doute. 5. Scan automatique : *secret scanning* et *push protection* de GitHub, gitleaks en pre-commit et en CI.
Et pour les clés déjà présentes dans l'historique : considère-les comme compromises et fais-les tourner.
Connectez-vous pour dire si ça a marché.
Sign in and verify your email to post an answer.