Titkos API-kulcs Expo appban: mit kell védeni?

Egy környezeti változó nem feltétlenül titok

Egy Expo appban az EXPO_PUBLIC_ előtagú változó az alkalmazás kódjának szól. Szerveroldali titok nem lehet benne. Az Expo leírja, hogy ezek az értékek bekerülnek a lefordított JavaScriptbe, és az app felhasználói ki tudják olvasni őket. Vagyis attól, hogy egy kulcsot átteszel egy .env fájlba, még nem lesz védve. Forrás: Expo környezeti változók.

Mielőtt megkérsz egy AI-t, hogy „kösse be az API-t”, sorold be, mit adsz a kezébe: egy szolgáltatás címét, egy eleve publikusnak szánt kulcsot, vagy egy kiemelt jogosultságú műveleteket engedélyező kulcsot. Ez a besorolás dönti el, hol kell futnia a kódnak.

Az alábbi táblázat tervezési szempontrendszer, nem az appod auditja.

Elem	Hova kerüljön	Mit kell ellenőrizni
A backend publikus címe	Az app konfigurációja	A megfelelő környezetre mutat.
Supabase publishable kulcs, vagy a régi anon kulcs	Az appba, ha a jogosultságok helyesen vannak beállítva	Az adatszabályok tényleg megakadályozzák, hogy hozzáférj egy másik felhasználó fiókjához.
Supabase secret vagy service_role kulcs	Csak a szerverre	Nem jelenik meg sem a mobil bundle-ben, sem a kliens számára elérhető naplókban.
Egy AI-szolgáltató titkos kulcsa	Csak a szerverre	Az app a te szerveredet hívja, amely a szolgáltató előtt ellenőrzi a felhasználót és a limiteket.

A Supabase megkülönbözteti a klienseknek szánt kulcsokat a megbízható környezetekbe való titkos kulcsoktól. A publikus kulcs a projektet azonosítja, de nem helyettesíti az adatokra vonatkozó jogosultságokat. Forrás: Supabase API-kulcsok.

Példa: egy kitalált olvasónapló-app

Képzelj el egy appot, amelyben Léa és Sami rögzíti a könyveit és a privát jegyzeteit. A példa a tesztek előkészítésére szolgál, nem egy Devoria-appon kapott eredményeket mutat be.

A normál folyamat rendben lévőnek tűnik: Léa bejelentkezik, és látja a jegyzeteit. Ez viszont még nem válaszolja meg a fontos kérdést: elutasítja-e a szerver Léa kérését, ha az Sami egyik jegyzetére irányul?

Egy felületi szűrő, például „a bejelentkezett felhasználó jegyzeteinek megjelenítése”, a megjelenítést teszi jobbá. Az engedélyezést az adatok oldalán is érvényesíteni kell. A Supabase-ben a Row Level Security szabályokkal a munkamenet alapján korlátozhatod, mely sorok érhetők el. A Supabase azt javasolja, hogy kapcsold be őket az API által elérhető tábláknál, és elmagyarázza az olvasási és írási szabályokat. Forrás: Row Level Security.

A saját tesztprojektedben rendeld hozzá minden jegyzetet a tulajdonosához, és külön határozd meg, ki olvashatja, hozhatja létre, módosíthatja és törölheti. A fájlokat is ellenőrizd: attól, hogy egy adatbázissor védett, még nem biztos, hogy egy kép privát.

A teszt, amit két tesztfiókkal kell lefuttatnod

Készíts két fiókot, amelyeket te irányítasz, mindegyikben egy-egy másik könyvvel és egy rövid, felismerhető jegyzettel. Kitalált adatokat használj, engedélyezett tesztkörnyezetben.

1. Saját jegyzet olvasása. Az A fiók megtalálja az A jegyzetet.
2. B jegyzetének olvasása A-ból. A kérés nem fedi fel a privát tartalmat.
3. B jegyzetének módosítása A-ból. A szerver elutasítja, a B jegyzet változatlan marad.
4. Létrehozás B nevében A-ból. A szerver elutasítja ezt a hozzárendelést.
5. Olvasás munkamenet nélkül. Semmilyen privát tartalom nem jön vissza.
6. B privát fájljának megnyitása A-ból. A fájl nem érhető el.

Jegyezd fel a tényleges eredményt, a tesztelt verziót és az esetleges hibát. Az, hogy „a szabályok be vannak kapcsolva”, nem teszteredmény. Az erőforrások között elérhető tesztsablon jó kiindulópont a bizonyítékok megőrzéséhez.

A fizetős hívást vezesd át a szervereden

Egy olyan funkciónál, amely egy AI API-val összefoglal egy könyvet, a folyamat ez lehet: app → a te szervered → szolgáltató → a te szervered → app. A titkos kulcs a szerveren marad. Ez az architektúra önmagában nem elég: a szerverhez való hozzáférést is ellenőrizni kell.

A kitalált példában a szervernek többek között ellenőriznie kell a munkamenetet, azt, hogy a könyv az adott személyé-e, korlátoznia kell az ismételt kéréseket, és érthető hibát kell visszaadnia, ha a szolgáltató nem válaszol. Nem a kliens dönti el, hogy egy felhasználónak jár-e a fizetős hozzáférés.

Készíts elő négy tesztet: nem bejelentkezett felhasználó, egy másik fiók könyve, elért limit és elérhetetlen szolgáltató. Az utolsóval azt ellenőrzöd, hogy az app kilép a töltési állapotból, és nem vész el a beírt szöveg.

Mit kérhetsz a kódoló asszisztensedtől

Íme egy átnézési utasítás, amit a saját repódhoz igazíthatsz. A titkos értékeidet ne másold bele:

Gyűjtsd össze a mobilkód és a szerver által használt változókat, csak a nevüket megjelenítve. Azonosítsd a kliensoldalon lévő kiemelt jogosultságú hívásokat. A privát adatoknál írd le az olvasási és írási ellenőrzéseket, majd javasolj egy tesztet két tesztfiókkal. Jóváhagyás nélkül ne végezz kulcsrotációt és ne módosíts semmit élesben.

A választ a hozzá tartozó kóddal együtt olvasd el. Egy asszisztens kiszúrhat egy ellentmondást, de a válasza nem helyettesíti a tesztek lefuttatását. Az app készítése Claude Code-dal útmutató elmagyarázza, hogyan bontsd fel ezt a munkát.

Mielőtt továbbmennél az appoddal

Három dolgot egyszerűen el kell tudnod magyarázni: mely értékek publikusak, mely műveletek mennek át a szerveren, és mely tesztek bizonyítják, hogy egy fiók nem látja egy másik adatait. Ha ezek közül bármelyik homályos, tisztázd, mielőtt új funkciókat adsz hozzá.

Az iPhone-app készítése oldal elhelyezi ezt a lépést a teljes projektben. Ha sorrendben akarsz haladni, az iOS Kit egy négylépéses utat és egy kezdőkódot ad, amelyben a fiókok és az AI már benne vannak. Ha nem tudod, melyik lépésnél folytasd, az ingyenes diagnózis sorba rendezi a projektedet, és elküldi neked az Apple-elutasítás elleni checklistemet.

Gyakori kérdések

Hova tegyem a titkos API-kulcsot egy Expo appban?

A szerveredre, soha nem az appba. A Supabase secret vagy service_role kulcsa, ahogy egy AI-szolgáltató titkos kulcsa is, kizárólag a szerveroldalon maradhat. Az app a te szerveredet hívja, amely a szolgáltató hívása előtt ellenőrzi a felhasználót és a limiteket. Ellenőrizd, hogy egyik kulcs se jelenjen meg a mobil bundle-ben vagy a kliens számára elérhető naplókban.

Megvédi egy .env fájl az API-kulcsomat Expóban?

Önmagában nem. Az EXPO_PUBLIC_ előtagú változó az alkalmazás kódjának szól, és nem lehet benne szerveroldali titok. Az Expo leírja, hogy ezek az értékek bekerülnek a lefordított JavaScriptbe, és az app felhasználói ki tudják olvasni őket. Vagyis attól, hogy egy kulcsot átteszel egy .env fájlba, még nem lesz védve.

Mi a különbség a publikus és a titkos API-kulcs között?

A publikus kulcsot arra szánták, hogy az appal együtt kerüljön ki: a projektet azonosítja, de nem helyettesíti az adatokra vonatkozó jogosultságokat. A titkos kulcs kiemelt jogosultságú műveleteket engedélyez, és csak megbízható környezetekben használható. A Supabase-nél a publishable kulcs, vagy a régi anon kulcs, maradhat az appban, ha a jogosultságok helyesen vannak beállítva. A secret és a service_role kulcs a szerveren marad.

Hogyan hívjak AI API-t egy Expo appból a kulcs kiszivárogtatása nélkül?

Vezesd át a hívást a szervereden: az app a szervert hívja, az meghívja a szolgáltatót, majd visszaküldi a választ az appnak. A titkos kulcs a szerveren marad. A szervernek ellenőriznie kell a munkamenetet is, korlátoznia kell az ismételt kéréseket, és érthető hibát kell visszaadnia, ha a szolgáltató nem válaszol. Nem a kliens dönti el, hogy egy felhasználónak jár-e a fizetős hozzáférés.

Hogyan ellenőrizzem, hogy minden felhasználó csak a saját adatait látja?

Készíts két tesztfiókot, amelyeket te irányítasz, mindegyikben egy felismerhető jegyzettel. Az A fiókból próbáld meg olvasni, módosítani és a B fiók nevében létrehozni, majd megnyitni B privát fájlját. Munkamenet nélkül is próbáld ki: minden kérést el kell utasítani, vagy nem fedhet fel semmit. Jegyezd fel a tényleges eredményt, mert az, hogy „a szabályok be vannak kapcsolva”, nem teszteredmény.

Hogyan kérjem meg az AI-t, hogy ellenőrizze az appom kulcsait?

Kérd meg, hogy gyűjtse össze a mobilkód és a szerver változóit, csak a nevüket megjelenítve, és ne másold be a titkos értékeidet. Kérd azt is, hogy azonosítsa a kliensoldalon lévő kiemelt jogosultságú hívásokat, és javasoljon egy tesztet két tesztfiókkal. Tilts meg minden kulcsrotációt és éles módosítást jóváhagyás nélkül. A válasza nem helyettesíti a tesztek lefuttatását.