# Klucz API w aplikacji Expo: co trzeba chronić > Klucz publiczny Supabase, sekret serwera, zmienne Expo: sprawdź, co może trafić do aplikacji na iPhone'a, i przetestuj dostęp na dwóch kontach. Oryginalna strona: [Klucz API w aplikacji Expo: co trzeba chronić](https://devoria.fr/pl/blog/klucz-api-aplikacja-expo-co-chronic) Autor: [Mehdi Azizi](https://devoria.fr/pl/mehdi-azizi) Publikacja: 2026-09-29 Ostatnia aktualizacja treści: 2026-10-09 ## 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](https://docs.expo.dev/guides/environment-variables/). 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](https://supabase.com/docs/guides/getting-started/api-keys). ## 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](https://supabase.com/docs/guides/database/postgres/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](https://devoria.fr/pl/resources) 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](https://devoria.fr/pl/blog/guideline-5-1-2-ai-att-udostepnianie-danych), ś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](https://devoria.fr/pl/blog/aplikacja-claude-code-tutorial-iphone) 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](https://devoria.fr/pl/expertise/jak-stworzyc-aplikacje-na-iphone) pokazuje ten etap w kontekście całego projektu. Jeśli chcesz iść po kolei, [iOS Kit](https://devoria.fr/pl/kits/ios) 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](https://devoria.fr/pl/diagnostic) 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. ## Twój projekt [iOS Kit](https://devoria.fr/pl/kits/ios): Stwórz aplikację na iPhone'a z Claude Code: Starter Code moich aplikacji, skille sprawdzające jego pracę oraz Apple Review Kit, App Store Screenshots Kit i ASO Kit. 129,99 €.