Tajný API klíč v aplikaci Expo: co chránit

Proměnná prostředí nemusí být tajemství

V aplikaci Expo je proměnná s prefixem EXPO_PUBLIC_ určená pro kód aplikace. Nesmí obsahovat serverové tajemství. Expo vysvětluje, že tyhle hodnoty se vkládají do zkompilovaného JavaScriptu a uživatelé aplikace si je můžou přečíst. Přesunout klíč do souboru .env tedy k jeho ochraně nestačí. Zdroj: proměnné prostředí Expo.

Než po AI budeš chtít, ať „napojí API“, roztřiď, co jí svěřuješ: adresu služby, klíč, který má být veřejný, nebo klíč, který povoluje privilegované akce. Podle toho se rozhoduje, kde se má kód spouštět.

Následující tabulka je návrhová mřížka, ne audit tvojí aplikace.

Prvek	Kam ho dát	Co ověřit
Veřejná adresa backendu	Konfigurace aplikace	Míří na správné prostředí.
Klíč Supabase publishable, nebo starší klíč anon	Aplikace, pokud jsou oprávnění správně nastavená	Pravidla pro data opravdu blokují přístup k účtu jiného uživatele.
Klíč Supabase secret nebo service_role	Jen server	Neobjevuje se v mobilním bundlu ani v lozích dostupných klientovi.
Tajný klíč poskytovatele AI	Jen server	Aplikace volá tvůj server, který před voláním poskytovatele zkontroluje uživatele a limity.

Supabase rozlišuje klíče určené pro klienty a tajné klíče pro důvěryhodná prostředí. Veřejný klíč identifikuje projekt; nenahrazuje oprávnění k datům. Zdroj: API klíče Supabase.

Příklad: smyšlená aplikace na čtenářský deník

Představ si aplikaci, kde si Lea a Sami ukládají knihy a soukromé poznámky. Příklad slouží k přípravě testů; nepopisuje výsledky naměřené na aplikaci Devoria.

Běžný průchod vypadá v pořádku: Lea se přihlásí a vidí svoje poznámky. Jenže tím ještě není zodpovězená ta důležitá otázka: odmítne server požadavek od Ley, který míří na Samiho poznámku?

Filtr v rozhraní, třeba „zobraz poznámky přihlášeného uživatele“, zlepší zobrazení. Autorizace ale musí platit i na straně dat. V Supabase umožňují pravidla Row Level Security omezit dostupné řádky podle session. Supabase doporučuje je zapnout u tabulek vystavených přes API a vysvětluje politiky pro čtení a zápis. Zdroj: Row Level Security.

Ve vlastním testovacím projektu přiřaď každou poznámku jejímu vlastníkovi a zvlášť urči, kdo ji smí číst, vytvořit, upravit a smazat. Zkontroluj i soubory: ochrana řádku v databázi nedokazuje, že je obrázek soukromý.

Testovací scénář pro dva testovací účty

Připrav si dva účty, které ovládáš, v každém jinou knihu a krátkou, snadno poznatelnou poznámku. Používej smyšlená data v povoleném testovacím prostředí.

1. Přečíst vlastní poznámku. Účet A najde poznámku A.
2. Přečíst poznámku B z účtu A. Požadavek neodhalí její soukromý obsah.
3. Upravit poznámku B z účtu A. Server odmítne; poznámka B zůstane beze změny.
4. Vytvořit záznam jménem B z účtu A. Server takové přiřazení odmítne.
5. Číst bez session. Nevrátí se žádný soukromý obsah.
6. Otevřít soukromý soubor B z účtu A. Soubor není dostupný.

Zapiš skutečný výsledek, testovanou verzi a případnou chybu. „Pravidla jsou zapnutá“ není výsledek testu. Jako základ pro uchování těchhle důkazů ti může posloužit testovací mřížka v sekci zdrojů.

Placené volání pošli přes svůj server

U funkce, která shrnuje knihu pomocí API umělé inteligence, může průchod vypadat takhle: aplikace → tvůj server → poskytovatel → tvůj server → aplikace. Tajný klíč zůstává na serveru. Samotná architektura ale nestačí: přístup k serveru musí být taky kontrolovaný.

Ve smyšleném příkladu musí server mimo jiné ověřit session, ověřit, že kniha patří danému člověku, omezit opakované požadavky a vrátit srozumitelnou chybu, když poskytovatel neodpovídá. Klient sám nerozhoduje o tom, že má uživatel placený přístup.

Připrav čtyři pokusy: nepřihlášený uživatel, kniha jiného účtu, dosažený limit a nedostupný poskytovatel. Ten poslední ověří, že aplikace opustí stav načítání a neztratí, co uživatel napsal.

Co můžeš chtít po svém asistentovi pro kód

Tady je zadání pro revizi, které si uprav podle svého repozitáře, a nevkládej do něj svoje tajné hodnoty:

Vypiš proměnné, které používá mobilní kód a server, a zobraz jen jejich názvy. Najdi privilegovaná volání na straně klienta. U soukromých dat popiš kontroly čtení a zápisu a pak navrhni testovací scénář se dvěma testovacími účty. Bez schválení neprováděj žádnou rotaci klíčů ani změnu v produkci.

Odpověď čti společně s odpovídajícím kódem. Asistent může odhalit nesrovnalost; jeho odpověď ale nenahrazuje spuštění testů. Návod vytvoř aplikaci s Claude Code vysvětluje, jak si tuhle práci rozdělit.

Než budeš s aplikací pokračovat

Musíš umět jednoduše vysvětlit tři věci: které hodnoty jsou veřejné, které operace jdou přes server a které testy ukazují, že jeden účet nevidí data jiného. Pokud ti některý bod není jasný, vyjasni si ho dřív, než přidáš další funkce.

Stránka vytvoř aplikaci pro iPhone zasazuje tenhle krok do celého projektu. Jestli chceš postupovat popořadě, iOS Kit nabízí cestu ve čtyřech krocích a Starter Code, který už obsahuje účty i AI. Pokud nevíš, u kterého kroku navázat, bezplatná diagnostika dá tvůj projekt do pořádku a pošle ti můj checklist proti zamítnutí od Applu.

Časté dotazy

Kam dát tajný API klíč v aplikaci Expo?

Na svůj server, nikdy do aplikace. Klíč Supabase secret nebo service_role, stejně jako tajný klíč poskytovatele AI, musí zůstat jen na serveru. Aplikace volá tvůj server, který zkontroluje uživatele a limity a teprve pak zavolá poskytovatele. Ověř, že se žádný z těchto klíčů neobjevuje v mobilním bundlu ani v lozích dostupných klientovi.

Ochrání soubor .env můj API klíč v Expo?

Sám o sobě ne. Proměnná s prefixem EXPO_PUBLIC_ je určená pro kód aplikace a nesmí obsahovat serverové tajemství. Expo vysvětluje, že tyhle hodnoty se vkládají do zkompilovaného JavaScriptu a uživatelé aplikace si je můžou přečíst. Přesunout klíč do souboru .env tedy k jeho ochraně nestačí.

Jaký je rozdíl mezi veřejným a tajným API klíčem?

Veřejný klíč je určený k tomu, aby byl součástí aplikace: identifikuje projekt, ale nenahrazuje oprávnění k datům. Tajný klíč povoluje privilegované akce a patří jen do důvěryhodných prostředí. U Supabase může klíč publishable, nebo starší klíč anon, zůstat v aplikaci, pokud jsou oprávnění správně nastavená. Klíče secret a service_role zůstávají na serveru.

Jak volat API umělé inteligence z aplikace Expo, aniž bych vystavil klíč?

Pošli volání přes svůj server: aplikace volá server, ten zavolá poskytovatele a odpověď vrátí aplikaci. Tajný klíč zůstává na serveru. Server musí taky ověřit session, omezit opakované požadavky a vrátit srozumitelnou chybu, když poskytovatel neodpovídá. Klient sám nerozhoduje o tom, že má uživatel placený přístup.

Jak ověřit, že každý uživatel vidí jen svoje data?

Připrav si dva testovací účty, které ovládáš, a v každém snadno poznatelnou poznámku. Z účtu A zkus číst, upravovat a vytvářet záznamy jménem účtu B a pak otevřít soukromý soubor B. Udělej i pokusy bez session: každý požadavek musí být odmítnut nebo nesmí nic odhalit. Zapiš skutečný výsledek, protože „pravidla jsou zapnutá“ není výsledek testu.

Jak požádat AI, aby zkontrolovala klíče mé aplikace?

Požádej ji, ať vypíše proměnné mobilního kódu a serveru a zobrazí jen jejich názvy, a nevkládej svoje tajné hodnoty. Ať taky najde privilegovaná volání na straně klienta a navrhne testovací scénář se dvěma testovacími účty. Zakaž jakoukoli rotaci klíčů nebo změnu v produkci bez schválení. Její odpověď nenahrazuje spuštění testů.