← Retour aux ressources
// technique · sécurité

Gérer ses secrets proprement

Un secret commité par erreur, et c'est la clé de ta base ou de Stripe sur GitHub pour toujours. Voici où les secrets doivent vivre, comment les injecter selon l'environnement, et quoi faire quand l'un fuit.

Technique24 juil. 2026~7 min · intermédiaire
.envSecrets ManagerCI variablesrotationgit
// sommaire
01La règle d’or02Où ils vivent, par environnement03Les lire proprement04Rotation & fuite05Sources & ressources
01

La règle d’or

Un secret ne vit jamais dans le code, ni dans le dépôt git. Il vit dans l'environnement, injecté au moment de l'exécution. Le code lit process.env ; il ne connaît jamais la valeur.

.gitignorecopier
# .gitignore — la premiere ligne de defense
.env
.env.local
.env*.local
# et si un secret a DEJA ete commite : le retirer de l'historique
# (git rm --cached + git filter-repo) ET le faire tourner immediatement
!

Un .env commité une fois reste dans l'historique git à jamais, même supprimé ensuite. Le seul vrai correctif : faire tourner (révoquer + régénérer) le secret exposé.

02

Où ils vivent, par environnement

local.env.local, gitignoré, jamais partagé par git
CIvariables masquées dans GitLab/GitHub, pas dans le YAML
prod (managé)variables d’env de Vercel / Amplify
prod (AWS)Secrets Manager ou SSM Parameter Store
i

Les variables CI/CD masquées sont exactement celles de bien utiliser GitLab CI/CD.

03

Les lire proprement

Deux réflexes : ne jamais mettre un secret dans une variable NEXT_PUBLIC_ (elle finit dans le bundle client), et valider la présence des secrets au démarrage plutôt que de découvrir qu'il en manque un en pleine requête prod.

config.tscopier
// on lit les secrets via process.env, jamais en dur dans le code
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);
// valider leur presence au boot : mieux vaut crasher au demarrage
// qu'a la premiere requete en prod
["STRIPE_SECRET_KEY", "DATABASE_URL"].forEach((k) => {
  if (!process.env[k]) throw new Error(`Missing env var: ${k}`);
});
i

La frontière NEXT_PUBLIC_ est le même piège que dans les failles de sécurité de base sur Next.js.

04

Rotation & fuite

fais tourner les secrets régulièrement, et immédiatement dès qu'un doute existe ;
un secret par environnement : la clé de staging n'est pas celle de prod ;
un scan de secrets en CI (gitleaks) pour attraper une fuite avant le merge ;
en cas de fuite : révoquer d'abord, enquêter ensuite. L'ordre compte.
05

Sources & ressources

01OWASP — Secrets Management Cheat SheetLe cadre général : stockage centralisé, cycle de vie, rotation automatisée, réponse à incident.↗02Next.js — How to use environment variablesOrdre de chargement des .env et pourquoi une variable NEXT_PUBLIC_ est inlinée dans le bundle client au build.↗03GitHub Docs — Removing sensitive data from a repositoryLa procédure officielle : révoquer/faire tourner le secret d'abord, réécrire l'historique avec git filter-repo ensuite.↗04gitleaks — Secret detection for git reposL'outil à brancher en CI ou en pre-commit pour attraper une clé avant le merge.↗05AWS — Rotate AWS Secrets Manager secretsRotation automatique planifiée, avec intégrations natives pour les bases de données.↗06AWS — Systems Manager Parameter StoreSecureString chiffré par KMS, hiérarchies de paramètres, IAM — l'alternative moins chère quand la rotation n'est pas requise.↗07Vercel — Sensitive environment variablesVariables non relisibles après création, redaction dans les logs de build, politique d'équipe.↗

Gérer ses secrets, c'est une discipline simple : hors du code, hors de git, injectés par l'environnement, validés au boot, et tournés sans hésiter. Un scan en CI comme filet, et la clé de ta base ne finira jamais dans un dépôt public.