# Cheie API secretă în aplicația Expo: ce trebuie protejat

> Cheie publică Supabase, secret de server, variabile Expo: vezi ce poate fi livrat în aplicația ta iPhone și testează accesul cu două conturi.

Pagina originală: [Cheie API secretă în aplicația Expo: ce trebuie protejat](https://devoria.fr/ro/blog/cheie-api-secreta-aplicatie-expo)
Autor: [Mehdi Azizi](https://devoria.fr/ro/mehdi-azizi)
Publicare: 2026-09-29
Ultima revizuire a conținutului: 2026-10-09


## O variabilă de mediu nu e neapărat un secret

Într-o aplicație Expo, o variabilă cu prefixul `EXPO_PUBLIC_` e destinată codului aplicației. Nu trebuie să conțină un secret de server. Expo explică faptul că aceste valori sunt incluse în JavaScript-ul compilat și pot fi citite de utilizatorii aplicației. Deci nu e suficient să muți o cheie într-un fișier `.env` ca s-o protejezi. [Sursă: variabilele de mediu Expo](https://docs.expo.dev/guides/environment-variables/).

Înainte să ceri unei IA să „conecteze API-ul”, clasifică ce îi dai: o adresă de serviciu, o cheie gândită să fie publică sau o cheie care permite acțiuni privilegiate. Clasificarea asta stabilește unde trebuie să ruleze codul.

Tabelul de mai jos e o grilă de concepție, nu un audit al aplicației tale.

| Element                                          | Unde îl pui                                             | Ce trebuie verificat                                                                         |
| ------------------------------------------------ | ------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| Adresa publică a backend-ului                    | Configurația aplicației                                 | Trimite către mediul corect.                                                                 |
| Cheia Supabase publishable sau vechea cheie anon | În aplicație, dacă permisiunile sunt configurate corect | Regulile de date chiar blochează accesul la contul altui utilizator.                         |
| Cheia Supabase secret sau service_role           | Doar pe server                                          | Nu apare nici în bundle-ul mobil, nici în logurile accesibile clientului.                    |
| Cheia secretă a unui furnizor de IA              | Doar pe server                                          | Aplicația îți apelează serverul, care verifică utilizatorul și limitele înainte de furnizor. |

Supabase face diferența între cheile destinate clienților și cheile secrete destinate mediilor de încredere. O cheie publică identifică proiectul; nu înlocuiește permisiunile asupra datelor. [Sursă: cheile API Supabase](https://supabase.com/docs/guides/getting-started/api-keys).

## Exemplu: o aplicație fictivă de jurnal de lectură

Să ne imaginăm o aplicație în care Léa și Sami își salvează cărțile și notițele private. Exemplul ăsta servește la pregătirea testelor; nu descrie rezultate obținute pe o aplicație Devoria.

Fluxul normal pare corect: Léa se conectează și își vede notițele. Dar asta încă nu răspunde la întrebarea importantă: refuză serverul o cerere a lui Léa care vizează o notiță a lui Sami?

Un filtru în interfață, de tipul „afișează notițele utilizatorului conectat”, îmbunătățește afișarea. Autorizarea trebuie aplicată și la nivelul datelor. În Supabase, regulile Row Level Security permit restricționarea rândurilor accesibile în funcție de sesiune. Supabase recomandă activarea lor pentru tabelele expuse prin API și explică politicile de citire și scriere. [Sursă: Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security).

Pentru propriul proiect de test, asociază fiecare notiță cu proprietarul ei și definește separat cine o poate citi, crea, modifica și șterge. Verifică și fișierele: faptul că protejezi un rând din baza de date nu dovedește că o imagine e privată.

## Testul de rulat cu două conturi de test

Pregătește două conturi pe care le controlezi, câte o carte diferită în fiecare și o mică notiță ușor de recunoscut. Folosește date fictive într-un mediu de test autorizat.

1. **Citește propria notiță.** Contul A găsește notița A.
2. **Citește notița lui B din A.** Cererea nu dezvăluie conținutul ei privat.
3. **Modifică notița lui B din A.** Serverul refuză; notița B rămâne neschimbată.
4. **Creează în numele lui B din A.** Serverul refuză această atribuire.
5. **Citește fără sesiune.** Nu se returnează niciun conținut privat.
6. **Deschide fișierul privat al lui B din A.** Fișierul nu e accesibil.

Notează rezultatul real, versiunea testată și eventuala eroare. „Regulile sunt activate” nu e un rezultat de test. [Grila de testare disponibilă în resurse](https://devoria.fr/ro/resources) îți poate servi ca bază ca să păstrezi aceste dovezi.

## Trece apelurile plătite prin serverul tău

Pentru o funcție care rezumă o carte cu [un API de IA](https://devoria.fr/ro/blog/guideline-5-1-2-ai-terta-att-partajare-date), fluxul poate fi: aplicație → serverul tău → furnizor → serverul tău → aplicație. Cheia secretă rămâne pe server. Arhitectura asta nu e suficientă singură: și accesul la server trebuie controlat.

În exemplul fictiv, serverul trebuie printre altele să verifice sesiunea, să verifice că acea carte aparține persoanei, să limiteze cererile repetate și să returneze o eroare ușor de înțeles dacă furnizorul nu răspunde. Clientul nu decide singur că un utilizator are acces plătit.

Pregătește patru teste: utilizator neconectat, carte a altui cont, limită atinsă și furnizor indisponibil. Ultimul îți permite să verifici că aplicația iese din starea de încărcare fără să piardă ce a introdus utilizatorul.

## Ce poți să-i ceri asistentului tău de cod

Iată o instrucțiune de review pe care s-o adaptezi la repo-ul tău, fără să lipești în ea valorile secrete:

> Inventariază variabilele folosite de codul mobil și de server, afișând doar numele lor. Identifică apelurile privilegiate prezente pe partea de client. Pentru datele private, descrie controalele de citire și scriere, apoi propune un test cu două conturi de test. Nu face nicio rotație de chei și nicio modificare în producție fără validare.

Citește răspunsul împreună cu codul corespunzător. Un asistent poate depista o inconsecvență; răspunsul lui nu înlocuiește rularea testelor. Ghidul [creează o aplicație cu Claude Code](https://devoria.fr/ro/blog/aplicatie-iphone-claude-code-tutorial) explică cum să împarți munca asta.

## Înainte să continui cu aplicația

Trebuie să poți explica simplu trei lucruri: ce valori sunt publice, ce operațiuni trec prin server și ce teste arată că un cont nu vede datele altuia. Dacă unul dintre aceste puncte rămâne neclar, lămurește-l înainte să adaugi funcții.

Pagina [creează o aplicație iPhone](https://devoria.fr/ro/expertise/creeaza-o-aplicatie-iphone) pune această etapă în contextul proiectului complet. Ca să avansezi în ordine, [iOS Kit](https://devoria.fr/ro/kits/ios) îți oferă un parcurs în patru etape și un cod de pornire care include deja conturile și IA. Dacă nu mai știi de la ce etapă să reiei, [diagnosticul gratuit](https://devoria.fr/ro/diagnostic) îți pune proiectul în ordine și îți trimite checklist-ul meu anti-respingere Apple.

## Întrebări frecvente

### Unde pun o cheie API secretă într-o aplicație Expo?

Pe serverul tău, niciodată în aplicație. Cheia Supabase secret sau service_role, la fel ca și cheia secretă a unui furnizor de IA, trebuie să rămână exclusiv pe server. Aplicația îți apelează serverul, care verifică utilizatorul și limitele înainte să apeleze furnizorul. Verifică faptul că niciuna dintre aceste chei nu apare în bundle-ul mobil sau în logurile accesibile clientului.

### Un fișier .env îmi protejează cheia API în Expo?

Nu de unul singur. O variabilă cu prefixul `EXPO_PUBLIC_` e destinată codului aplicației și nu trebuie să conțină un secret de server. Expo explică faptul că aceste valori sunt incluse în JavaScript-ul compilat și pot fi citite de utilizatorii aplicației. Deci nu e suficient să muți o cheie într-un fișier `.env` ca s-o protejezi.

### Care e diferența dintre o cheie API publică și o cheie secretă?

O cheie publică e gândită să fie livrată în aplicație: identifică proiectul, dar nu înlocuiește permisiunile asupra datelor. O cheie secretă permite acțiuni privilegiate și e rezervată mediilor de încredere. La Supabase, cheia publishable sau vechea cheie anon poate rămâne în aplicație dacă permisiunile sunt configurate corect. Cheile secret și service_role rămân pe server.

### Cum apelez un API de IA dintr-o aplicație Expo fără să expun cheia?

Trece apelul prin serverul tău: aplicația apelează serverul, care apelează furnizorul și apoi trimite răspunsul înapoi aplicației. Cheia secretă rămâne pe server. Serverul trebuie și să verifice sesiunea, să limiteze cererile repetate și să returneze o eroare ușor de înțeles dacă furnizorul nu răspunde. Clientul nu decide singur că un utilizator are acces plătit.

### Cum verific că fiecare utilizator își vede doar propriile date?

Pregătește două conturi de test pe care le controlezi, cu o notiță ușor de recunoscut în fiecare. Din contul A, încearcă să citești, să modifici și să creezi în numele contului B, apoi să deschizi fișierul privat al lui B. Fă și testele fără sesiune: fiecare cerere trebuie refuzată sau să nu dezvăluie nimic. Notează rezultatul real, pentru că „regulile sunt activate” nu e un rezultat de test.

### Cum îi cer unei IA să verifice cheile aplicației mele?

Cere-i să inventarieze variabilele din codul mobil și de pe server, afișând doar numele lor, fără să lipești valorile secrete. Cere-i și să identifice apelurile privilegiate prezente pe partea de client și să propună un test cu două conturi de test. Interzice orice rotație de chei sau modificare în producție fără validare. Răspunsul ei nu înlocuiește rularea testelor.


## Proiectul tău

[iOS Kit](https://devoria.fr/ro/kits/ios): Creează-ți aplicația iPhone cu Claude Code: codul de pornire al aplicațiilor mele, skill-urile care îi verifică munca și Apple Review Kit, App Store Screenshots Kit și ASO Kit. 129,99 €.