# Titkos API-kulcs Expo appban: mit kell védeni? > Publikus Supabase-kulcs, szerveroldali titok, Expo-változók: nézd meg, mi kerülhet az iPhone-appba, és teszteld a hozzáférést két fiókkal. Eredeti oldal: [Titkos API-kulcs Expo appban: mit kell védeni?](https://devoria.fr/hu/blog/titkos-api-kulcs-expo-app) Szerző: [Mehdi Azizi](https://devoria.fr/hu/mehdi-azizi) Megjelenés: 2026-09-29 A tartalom utolsó frissítése: 2026-10-09 ## 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](https://docs.expo.dev/guides/environment-variables/). 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](https://supabase.com/docs/guides/getting-started/api-keys). ## 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](https://supabase.com/docs/guides/database/postgres/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](https://devoria.fr/hu/resources) 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](https://devoria.fr/hu/blog/guideline-5-1-2-kulso-mi-att-adatmegosztas) ö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](https://devoria.fr/hu/blog/alkalmazas-keszitese-claude-code-iphone-utmutato) ú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](https://devoria.fr/hu/expertise/iphone-alkalmazas-keszitese) oldal elhelyezi ezt a lépést a teljes projektben. Ha sorrendben akarsz haladni, az [iOS Kit](https://devoria.fr/hu/kits/ios) 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](https://devoria.fr/hu/diagnostic) 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. ## A projekted [iOS Kit](https://devoria.fr/hu/kits/ios): Készítsd el az iPhone-appodat Claude Code-dal: az appjaim kiinduló kódja, a munkáját ellenőrző skillek, valamint az Apple Review Kit, az App Store Screenshots Kit és az ASO Kit. 129,99 €.