Gestionarea corectă a secrets în Expo: EAS Secrets vs .env

Dacă ai lucrat vreodată cu Expo și ai terminat prin a urca un .env din greșeală în Git sau ai realizat că o cheie privată e vizibilă la un simplu decompiler pe APK, nu ești singurul. Am trecut prin asta acum câțiva ani la un proiect cu 15k useri activi și am învățat pe pielea mea diferența dintre secrets de build și secrets de runtime.

Haideți să lămurim cum separăm lucrurile corect fără să complicăm excesiv setup-ul.

Marea capcană: EXPO_PUBLIC_ și bundle-ul de JS

De la Expo SDK 49 încoace, avem suport nativ pentru fișiere .env. Regula e simplă pe hârtie: orice variabilă care începe cu EXPO_PUBLIC_ devine disponibilă în codul tău de React Native.

Unde e problema? Mulți devi cred că dacă pun EXPO_PUBLIC_STRIPE_SECRET_KEY într-un fișier .env.production local sau pe server, ea e securizată. Fals. Tot ce are prefixul EXPO_PUBLIC_ este injectat direct în bundle-ul de JavaScript la build time. Oricine descarcă APK-ul sau IPA-ul și folosește un tool banal de reverse engineering (gen jadx sau dezarhivare simplă) îți citește cheia în 30 de secunde.

Trade-off sincer: .env.development și .env.production sunt excelente pentru URL-uri de API, feature flags sau IDs publice (cum e un Sentry DSN). Dar nu pune NICIODATĂ chei private acolo, indiferent că fișierul tău e trecut în .gitignore sau nu.

EAS Secrets: unde strălucesc și unde te încurcă

Pentru chei de signing, token-uri de deployment (npm, Sentry, Fastlane) sau API keys de care are nevoie doar procesul de build de pe serverele Expo, răspunsul e EAS Secrets.

Când rulezi un build pe infrastructura Expo (eas build), runner-ul injectează variabilele definite în EAS direct în mediul de execuție al mașinii virtuale.

Ce îmi place la EAS Secrets:

1. Nu ajung niciodată în codul sursă sau în repozitoriul de Git.
2. Sunt criptate direct pe infrastructura Expo și nu pot fi citite în UI după salvare.
3. Pot fi scoped super curat pe organizație sau pe proiect individual.

Ce e nasol? Dacă vrei să faci un build local (eas build --local), variabilele din EAS Secrets nu vin automat jos. Trebuie să le pasezi manual în terminal sau să creezi un setup local paralel. În plus, dacă ai nevoie de un secret în interiorul aplicației în timp ce rulează pe telefonul userului, EAS Secrets nu te ajută direct — tot ce injectezi acolo la runtime mobil devine tot public.

Arhitectura curată pe care o folosesc eu

După peste 12 aplicații lansate cu Expo, am rămas la o regulă simplă de separare:

• Runtime Public Values: .env.development și .env.production. Aici stau EXPO_PUBLIC_API_URL sau EXPO_PUBLIC_SENTRY_DSN. Le comit în Git fără frică, pentru că sunt oricum publice în bundle.
• Build-Time Secrets: EAS Secrets (setate din CLI). Aici stau SENTRY_AUTH_TOKEN, MAPS_API_KEY (dacă e folosit doar la generare nativă) sau token-uri de npm privat.
• Runtime Sensitive Secrets: NICIODATĂ pe mobil. Dacă aplicația trebuie să facă un request semnat la un serviciu terț (ex. Stripe, OpenAI), mobilul vorbește cu backend-ul propriu (Node, Go, Laravel), iar backend-ul ține cheia secretă și procesează răspunsul.

Voi cum gestionați secrets pe mobil? Ați pățit vreodată să vă leagă cineva vreo cheie din bundle?