Variabile de mediu în Node.js: configurare fără secrete în cod
Cum separi configurarea și secretele de cod într-o aplicație Node.js, ce verifici la build și runtime și ce nu trebuie expus browserului.
Configurarea și codul au cicluri de viață diferite
O aplicație Node.js poate folosi aceleași surse în mai multe medii, dar cu baze de date, chei API și URL-uri diferite. Variabilele de mediu permit schimbarea acestor valori fără să modifici repository-ul pentru fiecare deployment.
Nu trata însă orice valoare ca secret. Separă configurarea publică de parole, token-uri și chei private.
Build-time versus runtime
Unele framework-uri citesc anumite variabile în timpul build-ului și includ rezultatul în artefactul generat. Altele citesc valorile la pornirea serverului sau la fiecare request.
Înainte de deployment, identifică pentru fiecare variabilă:
- dacă este necesară la build;
- dacă este citită doar la runtime;
- dacă poate ajunge în bundle-ul trimis browserului;
- dacă schimbarea ei cere rebuild sau doar restart.
Nu expune secretele prin variabile publice
Multe framework-uri au convenții pentru variabile care pot fi folosite în client. O cheie cu prefix destinat browserului nu mai trebuie considerată secretă.
Cheile pentru baze de date, servicii administrative și API-uri private trebuie folosite doar în procese server-side care au nevoie de ele.
Fișierele .env nu trebuie tratate ca depozit universal
Fișierele locale sunt utile pentru dezvoltare, dar nu ar trebui împinse în repository dacă includ secrete. Folosește reguli de ignore și păstrează un exemplu fără valori sensibile atunci când echipa are nevoie să știe ce chei trebuie configurate.
Un .env.example poate documenta numele variabilelor, nu credentialele reale.
Validează configurarea la pornire
Dacă aplicația depinde de o valoare obligatorie, este mai sigur să oprești pornirea cu o eroare clară decât să continui cu undefined și să descoperi problema într-un flux de producție.
Validează formatul URL-urilor, valorile numerice și opțiunile enumerate acolo unde este relevant.
Rotește secretele fără să le publici în istoric
Dacă un secret a ajuns într-un commit, ștergerea lui din ultima versiune nu îl face automat invalid. Rotește credentialul la furnizor și verifică istoricul și logurile în care ar fi putut apărea.
Evită și afișarea valorilor sensibile în logurile de build sau în mesajele de eroare.
Checklist pentru deployment
- listează variabilele obligatorii;
- separă build-time de runtime;
- marchează ce este secret;
- confirmă ce poate ajunge în browser;
- validează valorile la pornire;
- testează deployment-ul cu o configurație nouă;
- documentează rotația credentialelor.
Pentru fluxul complet din repository, continuă cu Deploy Node.js din GitHub și pagina Deploy din GitHub.
Ține configurarea aplicației separată de repository
Definește valorile necesare pentru build și runtime și păstrează secretele în configurarea proiectului, nu în codul public.