Hemlig API-nyckel i en Expo-app: vad ska skyddas?

En miljövariabel är inte nödvändigtvis en hemlighet

I en Expo-app är en variabel med prefixet EXPO_PUBLIC_ avsedd för appens kod. Den får inte innehålla en serverhemlighet. Expo förklarar att de här värdena byggs in i den kompilerade JavaScript-koden och kan läsas av appens användare. Att flytta en nyckel till en .env-fil räcker alltså inte för att skydda den. Källa: miljövariabler i Expo.

Innan du ber en AI att "koppla in API:t", sortera det du ger den: en tjänsteadress, en nyckel som är tänkt att vara publik, eller en nyckel som ger behörighet till privilegierade åtgärder. Den sorteringen avgör var koden ska köras.

Tabellen nedan är ett designunderlag, inte en granskning av din app.

Element	Var den ska ligga	Vad du ska kontrollera
Backendens publika adress	Appens konfiguration	Den pekar på rätt miljö.
Supabase publishable-nyckel, eller gamla anon-nyckeln	I appen om behörigheterna är korrekt konfigurerade	Dataregler blockerar verkligen åtkomst till en annan användares konto.
Supabase secret- eller service_role-nyckel	Endast på servern	Den syns varken i mobilens bundle eller i loggar som klienten kommer åt.
Hemlig nyckel från en AI-leverantör	Endast på servern	Appen anropar din server, som kontrollerar användaren och gränserna före leverantören.

Supabase skiljer mellan nycklar avsedda för klienter och hemliga nycklar avsedda för betrodda miljöer. En publik nyckel identifierar projektet; den ersätter inte behörigheterna på datan. Källa: API-nycklar i Supabase.

Exempel: en påhittad app för läsdagbok

Tänk dig en app där Léa och Sami sparar sina böcker och privata anteckningar. Exemplet är till för att förbereda testerna; det beskriver inte resultat från en Devoria-app.

Det normala flödet ser rätt ut: Léa loggar in och ser sina anteckningar. Men det svarar ännu inte på den viktiga frågan: nekar servern en begäran från Léa som gäller en av Samis anteckningar?

Ett filter i gränssnittet, som "visa den inloggade användarens anteckningar", förbättrar visningen. Behörigheten måste också tillämpas på datasidan. I Supabase kan du med Row Level Security-regler begränsa vilka rader som är åtkomliga utifrån sessionen. Supabase rekommenderar att de aktiveras för tabeller som exponeras via API:t och förklarar policyer för läsning och skrivning. Källa: Row Level Security.

I ditt eget testprojekt: koppla varje anteckning till sin ägare och definiera separat vem som får läsa, skapa, ändra och radera den. Kontrollera även filerna: att en databasrad är skyddad bevisar inte att en bild är privat.

Testet du kör med två testkonton

Förbered två konton som du kontrollerar, en olika bok i vart och ett och en liten igenkännbar anteckning. Använd påhittad data i en godkänd testmiljö.

1. Läsa sin egen anteckning. Konto A hittar anteckning A.
2. Läsa B:s anteckning från A. Begäran avslöjar inte det privata innehållet.
3. Ändra B:s anteckning från A. Servern nekar; anteckning B förblir oförändrad.
4. Skapa i B:s namn från A. Servern nekar den tilldelningen.
5. Läsa utan session. Inget privat innehåll returneras.
6. Öppna B:s privata fil från A. Filen går inte att komma åt.

Anteckna det faktiska resultatet, den testade versionen och eventuellt fel. "Reglerna är aktiverade" är inte ett testresultat. Testmallen bland resurserna kan fungera som grund för att spara de här bevisen.

Låt betalda anrop gå via din server

För en funktion som sammanfattar en bok med ett AI-API kan flödet vara: app → din server → leverantör → din server → app. Den hemliga nyckeln stannar på servern. Den arkitekturen räcker inte ensam: åtkomsten till servern måste också kontrolleras.

I det påhittade exemplet måste servern bland annat kontrollera sessionen, kontrollera att boken tillhör personen, begränsa upprepade förfrågningar och returnera ett begripligt fel om leverantören inte svarar. Klienten bestämmer inte själv att en användare har betald åtkomst.

Förbered fyra tester: utloggad användare, bok från ett annat konto, gräns nådd och leverantör otillgänglig. Det sista låter dig kontrollera att appen lämnar sitt laddningsläge utan att tappa det som skrivits in.

Vad du kan be din kodassistent om

Här är en granskningsinstruktion att anpassa till ditt repo, utan att klistra in dina hemliga värden:

Lista variablerna som används av mobilkoden och av servern, och visa bara deras namn. Identifiera privilegierade anrop som finns på klientsidan. För privat data, beskriv kontrollerna för läsning och skrivning och föreslå sedan ett test med två testkonton. Gör ingen nyckelrotation eller ändring i produktion utan godkännande.

Läs svaret tillsammans med motsvarande kod. En assistent kan hitta en inkonsekvens; svaret ersätter inte att köra testerna. Guiden skapa en app med Claude Code förklarar hur du delar upp arbetet.

Innan du fortsätter med din app

Du ska kunna förklara tre saker enkelt: vilka värden som är publika, vilka operationer som går via servern och vilka tester som visar att ett konto inte ser ett annat kontos data. Om någon av punkterna är oklar, reda ut den innan du lägger till funktioner.

Sidan skapa en iPhone-app sätter in det här steget i hela projektet. För att ta saker i rätt ordning erbjuder iOS Kit en väg i fyra steg och Starter Code som redan innehåller konton och AI. Om du inte vet vilket steg du ska fortsätta från, sätter den kostnadsfria diagnosen ordning på ditt projekt och skickar dig min checklista mot avslag från Apple.

Vanliga frågor

Var ska man lägga en hemlig API-nyckel i en Expo-app?

På din server, aldrig i appen. Supabase secret- eller service_role-nyckeln, liksom en AI-leverantörs hemliga nyckel, ska bara finnas på serversidan. Appen anropar din server, som kontrollerar användaren och gränserna innan leverantören anropas. Kontrollera att ingen av nycklarna syns i mobilens bundle eller i loggar som klienten kommer åt.

Skyddar en .env-fil min API-nyckel i Expo?

Inte på egen hand. En variabel med prefixet EXPO_PUBLIC_ är avsedd för appens kod och får inte innehålla en serverhemlighet. Expo förklarar att de här värdena byggs in i den kompilerade JavaScript-koden och kan läsas av appens användare. Att flytta en nyckel till en .env-fil räcker alltså inte för att skydda den.

Vad är skillnaden mellan en publik och en hemlig API-nyckel?

En publik nyckel är tänkt att följa med i appen: den identifierar projektet, men ersätter inte behörigheterna på datan. En hemlig nyckel ger behörighet till privilegierade åtgärder och är reserverad för betrodda miljöer. Hos Supabase kan publishable-nyckeln, eller den gamla anon-nyckeln, ligga i appen om behörigheterna är korrekt konfigurerade. Secret- och service_role-nycklarna stannar på servern.

Hur anropar man ett AI-API från en Expo-app utan att exponera nyckeln?

Låt anropet gå via din server: appen anropar servern, som anropar leverantören och sedan skickar svaret tillbaka till appen. Den hemliga nyckeln stannar på servern. Servern måste också kontrollera sessionen, begränsa upprepade förfrågningar och returnera ett begripligt fel om leverantören inte svarar. Klienten bestämmer inte själv att en användare har betald åtkomst.

Hur kontrollerar man att varje användare bara ser sin egen data?

Förbered två testkonton som du kontrollerar, med en igenkännbar anteckning i vart och ett. Från konto A, försök läsa, ändra och skapa i konto B:s namn, och sedan öppna B:s privata fil. Gör även testerna utan session: varje begäran ska nekas eller inte avslöja något. Anteckna det faktiska resultatet, för "reglerna är aktiverade" är inte ett testresultat.

Hur ber man en AI att kontrollera nycklarna i sin app?

Be den lista variablerna i mobilkoden och på servern, och bara visa deras namn, utan att du klistrar in dina hemliga värden. Be den också identifiera privilegierade anrop på klientsidan och föreslå ett test med två testkonton. Förbjud all nyckelrotation eller ändring i produktion utan godkännande. Svaret ersätter inte att köra testerna.