Gestion des secrets et variables d’environnement

Dans une application React, les variables d’environnement se répartissent en deux catégories : côté serveur (jamais envoyées au navigateur) et côté client (intégrées au paquet JavaScript). Comprendre à quelle catégorie appartiennent vos variables est la première étape de la gestion des secrets, car les variables côté client sont effectivement publiques dès que le paquet est déployé.

Dans les projets Vite, seules les variables préfixées par VITE_ sont incluses dans le paquet client. VITE_PUBLIC_API_URL=https://api.example.com est accessible dans le code du navigateur via import.meta.env.VITE_PUBLIC_API_URL. Toutes les autres variables sont retirées du paquet au moment de la compilation et restent réservées au serveur.

Dans Next.js, le préfixe NEXT_PUBLIC_ expose une variable au code JavaScript du navigateur. NEXT_PUBLIC_ANALYTICS_ID=UA-123 est intégré au paquet client. Les variables sans ce préfixe (comme DATABASE_URL) sont accessibles uniquement dans le code côté serveur (composants serveur, routes d’API, actions serveur) et ne sont jamais envoyées au navigateur.

Une variable sans préfixe reste accessible si elle est sérialisée par inadvertance. Par exemple, si un composant serveur transmet l’intégralité de son objet de configuration en tant que propriété à un composant client, et que cette configuration contient DATABASE_URL, ce secret apparaît dans le HTML envoyé au navigateur. Une transmission prudente des propriétés et un audit de la sérialisation permettent d’éviter cela.

Les éléments suivants ne doivent jamais apparaître dans le paquet client : chaînes de connexion et mots de passe de bases de données, clés secrètes d’API tierces (clé secrète Stripe, clé d’API OpenAI), clés privées RSA/EC, secrets de signature JWT et jetons d’authentification de services internes. Si l’un de ces éléments est nécessaire pour un appel d’API, faites passer cet appel par un point de terminaison serveur.

Le modèle de serveur pour l’interface utilisateur (BFF) place une fine couche serveur entre l’application React et les services externes sensibles. Le client appelle /api/stripe/charge, le serveur BFF ajoute la clé secrète Stripe et appelle l’API Stripe, puis le BFF ne renvoie que les données de réponse nécessaires. Les secrets restent définitivement sur le serveur.

dotenv-vault chiffre votre fichier .env et permet de le partager et de le déployer de manière sécurisée entre les environnements, sans enregistrer de secrets en clair dans le contrôle de version. Parmi les solutions de production figurent HashiCorp Vault (édition pour entreprises), AWS Parameter Store (SSM) et GCP Secret Manager ; toutes permettent de récupérer les secrets via une API au moment de l’exécution plutôt qu’au moment de la compilation.

Les plateformes CI/CD (GitHub Actions, GitLab CI) fournissent un stockage chiffré des secrets, accessible sous forme de variables d’environnement pendant les compilations. Stockez les secrets dans GitHub Secrets et référencez-les dans les flux de travail avec ${{ secrets.STRIPE_SECRET_KEY }}. Les secrets sont masqués dans les journaux et ne sont jamais inclus dans l’artefact compilé.

Next.js et Vite prennent en charge plusieurs fichiers .env : .env (tous les environnements), .env.local (remplacements locaux, ignoré par Git), .env.development, .env.production. Le fichier local remplace les valeurs du fichier partagé, ce qui permet une configuration propre à chaque développeur sans modifier les autres environnements.

Après la compilation, recherchez les secrets accidentellement exposés dans le paquet JavaScript. Exécutez grep -r "password|secret|api_key" dist/ ou utilisez un outil spécialisé comme strings pour analyser les fichiers compilés. Certains secrets, s’ils sont accidentellement inclus, sont facilement reconnaissables à leur format (UUID, chaînes base64 ou préfixes de clé tels que sk_live_).

Chaque environnement et chaque service ne doivent avoir accès qu’aux secrets dont ils ont besoin. Le client React n’a besoin d’aucun secret : il devrait recevoir uniquement des identifiants publics. Le serveur BFF n’a besoin que des secrets requis par les API qu’il appelle. Les environnements de développement doivent utiliser des clés d’API hors production, avec des permissions limitées et des plafonds de dépenses.

Vite utilise VITE_ et Next.js utilise NEXT_PUBLIC_ pour exposer des variables au paquet du navigateur. Toutes les autres variables sont réservées au serveur. N’incluez jamais de mots de passe de bases de données, de clés secrètes d’API ou de secrets de signature JWT dans le code client. Utilisez le modèle BFF pour faire transiter les appels d’API sensibles. Utilisez dotenv-vault, AWS Parameter Store ou GitHub Secrets pour gérer les secrets en production. Auditez les paquets compilés afin de repérer les secrets accidentellement exposés.