Klucz API w aplikacji Expo: co trzeba chronić

Zmienna środowiskowa to niekoniecznie sekret

W aplikacji Expo zmienna z prefiksem EXPO_PUBLIC_ jest przeznaczona dla kodu aplikacji. Nie może zawierać sekretu serwera. Expo wyjaśnia, że te wartości są wbudowywane w skompilowany JavaScript i użytkownicy aplikacji mogą je odczytać. Samo przeniesienie klucza do pliku .env go więc nie chroni. Źródło: zmienne środowiskowe Expo.

Zanim poprosisz AI o „podpięcie API”, sklasyfikuj to, co jej przekazujesz: adres usługi, klucz przewidziany jako publiczny albo klucz, który pozwala na uprzywilejowane operacje. Od tej klasyfikacji zależy, gdzie ma się wykonywać kod.

Poniższa tabela to schemat projektowy, a nie audyt twojej aplikacji.

Element	Gdzie go umieścić	Co sprawdzić
Publiczny adres backendu	Konfiguracja aplikacji	Wskazuje na właściwe środowisko.
Klucz Supabase publishable lub dawny klucz anon	Aplikacja, jeśli uprawnienia są poprawnie ustawione	Reguły danych naprawdę blokują dostęp do konta innego użytkownika.
Klucz Supabase secret lub service_role	Wyłącznie serwer	Nie pojawia się ani w bundlu mobilnym, ani w logach dostępnych dla klienta.
Tajny klucz dostawcy AI	Wyłącznie serwer	Aplikacja wywołuje twój serwer, który sprawdza użytkownika i limity przed wywołaniem dostawcy.

Supabase rozróżnia klucze przeznaczone dla klientów i klucze tajne do zaufanych środowisk. Klucz publiczny identyfikuje projekt, ale nie zastępuje uprawnień do danych. Źródło: klucze API Supabase.

Przykład: fikcyjna aplikacja do notatek z lektur

Wyobraź sobie aplikację, w której Lea i Sami zapisują swoje książki i prywatne notatki. Ten przykład służy do przygotowania testów. Nie opisuje wyników uzyskanych w żadnej aplikacji Devoria.

Zwykła ścieżka wygląda dobrze: Lea się loguje i widzi swoje notatki. Ale to jeszcze nie odpowiada na ważne pytanie: czy serwer odrzuci żądanie Lei dotyczące notatki Samiego?

Filtr w interfejsie, np. „pokaż notatki zalogowanego użytkownika”, poprawia wyświetlanie. Autoryzacja musi jednak działać też po stronie danych. W Supabase reguły Row Level Security pozwalają ograniczyć dostępne wiersze na podstawie sesji. Supabase zaleca ich włączenie dla tabel udostępnianych przez API i opisuje polityki odczytu i zapisu. Źródło: Row Level Security.

We własnym projekcie testowym przypisz każdą notatkę do właściciela i osobno określ, kto może ją czytać, tworzyć, edytować i usuwać. Sprawdź też pliki: ochrona wiersza w bazie danych nie dowodzi, że obrazek jest prywatny.

Test do przeprowadzenia na dwóch kontach testowych

Przygotuj dwa konta, nad którymi masz kontrolę, w każdym inną książkę i krótką, łatwą do rozpoznania notatkę. Używaj fikcyjnych danych w dozwolonym środowisku testowym.

1. Odczyt własnej notatki. Konto A widzi notatkę A.
2. Odczyt notatki B z konta A. Żądanie nie ujawnia jej prywatnej treści.
3. Edycja notatki B z konta A. Serwer odmawia, notatka B się nie zmienia.
4. Tworzenie w imieniu B z konta A. Serwer odrzuca takie przypisanie.
5. Odczyt bez sesji. Nie zwraca się żadna prywatna treść.
6. Otwarcie prywatnego pliku B z konta A. Plik jest niedostępny.

Zapisz rzeczywisty wynik, testowaną wersję i ewentualny błąd. „Reguły są włączone” to nie jest wynik testu. Szablon testów dostępny w zasobach może posłużyć jako baza do przechowywania tych dowodów.

Płatne wywołania przepuszczaj przez swój serwer

Dla funkcji, która streszcza książkę przy użyciu API AI, ścieżka może wyglądać tak: aplikacja → twój serwer → dostawca → twój serwer → aplikacja. Tajny klucz zostaje na serwerze. Sama ta architektura nie wystarczy: dostęp do serwera też musi być kontrolowany.

W fikcyjnym przykładzie serwer musi m.in. sprawdzić sesję, sprawdzić, czy książka należy do danej osoby, ograniczać powtarzane żądania i zwracać zrozumiały błąd, gdy dostawca nie odpowiada. Klient sam nie decyduje, że użytkownik ma płatny dostęp.

Przygotuj cztery próby: niezalogowany użytkownik, książka z innego konta, osiągnięty limit i niedostępny dostawca. Ostatnia pozwala sprawdzić, czy aplikacja wychodzi ze stanu ładowania bez utraty wpisanego tekstu.

O co możesz poprosić swojego asystenta kodowania

Oto polecenie do przeglądu, które dostosujesz do swojego repozytorium, bez wklejania w nie tajnych wartości:

Wypisz zmienne używane przez kod mobilny i przez serwer, pokazując tylko ich nazwy. Wskaż uprzywilejowane wywołania obecne po stronie klienta. Dla danych prywatnych opisz kontrole odczytu i zapisu, a potem zaproponuj test na dwóch kontach testowych. Nie wykonuj żadnej rotacji kluczy ani zmian na produkcji bez zatwierdzenia.

Czytaj odpowiedź razem z odpowiednim kodem. Asystent może wychwycić niespójność, ale jego odpowiedź nie zastępuje uruchomienia testów. Poradnik jak stworzyć aplikację z Claude Code wyjaśnia, jak podzielić tę pracę.

Zanim zaczniesz rozwijać aplikację dalej

Musisz umieć prosto wyjaśnić trzy rzeczy: które wartości są publiczne, które operacje idą przez serwer i które testy pokazują, że jedno konto nie widzi danych drugiego. Jeśli któryś z tych punktów jest niejasny, wyjaśnij go, zanim dodasz kolejne funkcje.

Strona jak stworzyć aplikację na iPhone'a pokazuje ten etap w kontekście całego projektu. Jeśli chcesz iść po kolei, iOS Kit oferuje ścieżkę w czterech krokach i Starter Code, który ma już konta i AI. Jeśli nie wiesz, od którego kroku wrócić do pracy, darmowa diagnoza uporządkuje twój projekt i wyśle ci moją checklistę, która pomaga uniknąć odrzucenia przez Apple.

Najczęściej zadawane pytania

Gdzie trzymać tajny klucz API w aplikacji Expo?

Na swoim serwerze, nigdy w aplikacji. Klucz Supabase secret lub service_role, tak jak tajny klucz dostawcy AI, musi zostać wyłącznie po stronie serwera. Aplikacja wywołuje twój serwer, który sprawdza użytkownika i limity przed wywołaniem dostawcy. Sprawdź, czy żaden z tych kluczy nie pojawia się w bundlu mobilnym ani w logach dostępnych dla klienta.

Czy plik .env chroni mój klucz API w Expo?

Sam z siebie nie. Zmienna z prefiksem EXPO_PUBLIC_ jest przeznaczona dla kodu aplikacji i nie może zawierać sekretu serwera. Expo wyjaśnia, że te wartości są wbudowywane w skompilowany JavaScript i użytkownicy aplikacji mogą je odczytać. Samo przeniesienie klucza do pliku .env go więc nie chroni.

Czym różni się publiczny klucz API od tajnego?

Klucz publiczny jest przewidziany do dołączenia do aplikacji: identyfikuje projekt, ale nie zastępuje uprawnień do danych. Klucz tajny pozwala na uprzywilejowane operacje i jest zarezerwowany dla zaufanych środowisk. W Supabase klucz publishable lub dawny klucz anon może zostać w aplikacji, jeśli uprawnienia są poprawnie ustawione. Klucze secret i service_role zostają na serwerze.

Jak wywołać API AI z aplikacji Expo bez ujawniania klucza?

Przepuść wywołanie przez swój serwer: aplikacja wywołuje serwer, ten wywołuje dostawcę i odsyła odpowiedź do aplikacji. Tajny klucz zostaje na serwerze. Serwer musi też sprawdzać sesję, ograniczać powtarzane żądania i zwracać zrozumiały błąd, gdy dostawca nie odpowiada. Klient sam nie decyduje, że użytkownik ma płatny dostęp.

Jak sprawdzić, czy każdy użytkownik widzi tylko swoje dane?

Przygotuj dwa konta testowe, nad którymi masz kontrolę, z łatwą do rozpoznania notatką w każdym. Z konta A spróbuj odczytać, edytować i utworzyć dane w imieniu konta B, a potem otworzyć prywatny plik B. Zrób też próby bez sesji: każde żądanie powinno zostać odrzucone albo niczego nie ujawnić. Zapisz rzeczywisty wynik, bo „reguły są włączone” to nie jest wynik testu.

Jak poprosić AI o sprawdzenie kluczy w mojej aplikacji?

Poproś ją o wypisanie zmiennych z kodu mobilnego i serwera, z samymi nazwami, bez wklejania tajnych wartości. Poproś też o wskazanie uprzywilejowanych wywołań po stronie klienta i zaproponowanie testu na dwóch kontach testowych. Zabroń rotacji kluczy i zmian na produkcji bez zatwierdzenia. Jej odpowiedź nie zastępuje uruchomienia testów.