Jak bezpiecznie przechowywać klucze API w aplikacji

Aby bezpiecznie przechowywać klucze API, zapisuj je jako sekrety lub zmienne środowiskowe u hostingu, używaj ich tylko w kodzie po stronie serwera i nigdy nie wklejaj ich do czatu, plików kodu, zrzutów ekranu ani repozytorium Git. Przydziel każdemu kluczowi najmniejsze potrzebne uprawnienia, ustaw limity wydatków u dostawcy, a jeśli klucz kiedykolwiek wycieknie, zmień go — utwórz nowy i usuń stary — zamiast tylko ukrywać, gdzie się pojawił.

Klucz API to hasło do usługi. Twój klucz OpenAI pozwala komuś wydawać Twoje pieniądze na AI; Twój sekretny klucz Stripe pozwala wystawiać zwroty; klucz dostawcy poczty pozwala wysyłać maile w Twoim imieniu. Narzędzia do budowy aplikacji AI dobrze podłączają te klucze, ale nie zawsze pilnują, gdzie trafiają, dlatego ten przewodnik pokazuje, jak je chronić i jak to sprawdzić.

Klucze publiczne a sekretne

Nie każdy klucz jest sekretny. Znajomość różnicy pozwala nie panikować z powodu niewłaściwego klucza i nie ignorować właściwego.

Jeśli nie wiesz, jakiego typu jest dany klucz, sprawdź dokumentację dostawcy. W razie wątpliwości traktuj go jako sekret.

Krok 1: Przechowuj klucze jako sekrety, nie w kodzie

Klucze powinny znaleźć się w ustawieniach zmiennych środowiskowych lub sekretów Twojego hostingu. Kod odczytuje je po nazwie w czasie działania (na przykład process.env.OPENAI_API_KEY), więc wartość nigdy nie pojawia się w Twoich plikach. Tło znajdziesz w czym są zmienne środowiskowe i sekrety.

Przenieś każdy klucz API z kodu do zmiennych środowiskowych. Wypisz każdy klucz, który znalazłeś, plik, w którym był, i nazwę zmiennej, której użyłeś. Nie pokazuj mi wartości.

Potem sprawdź, czy nic nie zostało:

Przeszukaj cały projekt, w tym pliki konfiguracyjne i wszystkie pliki .env, pod kątem czegokolwiek, co wygląda jak klucz API lub hasło. Podaj plik i numer linii, nie wartość.

Krok 2: Używaj kluczy sekretnych tylko na serwerze

To najważniejsza zasada. Wszystko, co dostaje przeglądarka, może odczytać odwiedzający — źródło strony i pliki JavaScript są widoczne w narzędziach deweloperskich.

Dlatego jeśli aplikacja musi wywołać OpenAI, przeglądarka powinna wywołać Twój serwer, a serwer wywołuje OpenAI z kluczem. Klucz nigdy nie opuszcza serwera.

Funkcja czatu wywołuje OpenAI bezpośrednio z przeglądarki. Przenieś to wywołanie do trasy API po stronie serwera, która odczytuje OPENAI_API_KEY ze środowiska. Przeglądarka ma wywoływać tylko naszą trasę. Wymagaj logowania do tej trasy.

Uważaj na jedną częstą pułapkę w frameworkach frontendowych: zmienne z publicznym prefiksem — VITE_ w Vite, NEXT_PUBLIC_ w Next.js — są celowo wbudowywane w kod przeglądarki. Sekretny klucz z takim prefiksem jest odsłonięty, mimo że „jest w zmiennej środowiskowej".

Krok 3: Sprawdź, czy nic nie wycieka

Nie zakładaj, że się udało — sprawdź działającą stronę:

1. Otwórz opublikowaną aplikację w przeglądarce.
2. Otwórz narzędzia deweloperskie, a potem kartę Sources lub Network.
3. Przeszukaj pliki pod kątem pierwszych znaków każdego sekretnego klucza (na przykład sk_ lub sk-).
4. Sprawdź żądania sieciowe, które wysyła aplikacja. Żądanie idące prosto z przeglądarki do płatnego dostawcy AI to sygnał alarmowy.

Jeśli znajdziesz sekretny klucz, przenieś go na serwer (krok 2) i zmień (krok 6), bo już był publiczny.

Krok 4: Ogranicz, co każdy klucz może robić

Wielu dostawców pozwala ograniczyć klucz:

• Klucze z zakresem lub ograniczone, które mogą robić tylko to, czego potrzebuje Twoja aplikacja. Stripe na przykład obsługuje klucze ograniczone z konkretnymi uprawnieniami.
• Ograniczenia domeny lub IP dla kluczy, które muszą być publiczne, na przykład kluczy do map.
• Osobne klucze dla każdej aplikacji i każdego środowiska, aby jeden wyciek nie odsłonił wszystkiego, a unieważnienie jednego nie psuło pozostałych.
• Klucze testowe podczas budowania, a klucze produkcyjne tylko w opublikowanej aplikacji.

Krok 5: Ogranicz skalę szkód

Nawet dobrze chroniony klucz może zostać nadużyty przez Twoją aplikację — na przykład ktoś może wielokrotnie w skrypcie wywoływać Twoją funkcję AI.

• Ustaw limity wydatków lub alerty u każdego płatnego dostawcy.
• Wymagaj logowania przy każdej funkcji, która kosztuje pieniądze za wywołanie.
• Dodaj limit zapytań na użytkownika. Zobacz czym jest ograniczanie liczby zapytań.

Dodaj limit 30 żądań AI na użytkownika na godzinę do /api/chat. Gdy limit zostanie osiągnięty, zwróć jasny komunikat. Odrzucaj żądania od użytkowników, którzy nie są zalogowani.

Krok 6: Zmieniaj klucze, które wyciekły

Jeśli sekretny klucz pojawi się tam, gdzie nie powinien — w wiadomości czatu, commicie, zrzucie ekranu, zgłoszeniu do pomocy technicznej, kodzie przeglądarki — zakładaj, że został przejęty.

1. Utwórz nowy klucz u dostawcy.
2. Zaktualizuj sekret w ustawieniach aplikacji.
3. Wdróż lub opublikuj ją ponownie, aby działająca aplikacja używała nowego klucza.
4. Usuń stary klucz u dostawcy.
5. Sprawdź logi użycia u dostawcy pod kątem aktywności, której nie rozpoznajesz.

Samo usunięcie wiadomości czatu lub commita Git nie wystarczy. Historia Git zachowuje stare wersje, a wszystko, co było publiczne, mogło już zostać skopiowane.

Częste błędy

• Wklejanie klucza do promptu. Trafia do historii czatu. Zamiast tego użyj formularza sekretów.
• Publiczny prefiks przy zmiennej sekretnej. VITE_OPENAI_API_KEY wysyła klucz każdemu odwiedzającemu.
• Zatwierdzenie pliku .env. Upewnij się, że jest w .gitignore, zanim wypchniesz kod po raz pierwszy.
• Jeden klucz wszędzie. Używaj osobnych kluczy do testów i produkcji oraz dla każdej aplikacji.
• Brak limitu wydatków. Wyciekły lub nadużywany klucz bez limitu może wygenerować duży rachunek, zanim to zauważysz.
• Ukrywanie zamiast zmiany. Gdy klucz został ujawniony, tylko nowy klucz to naprawia.
• Klucze na zrzutach ekranu. Przytnij lub zamaż strony ustawień, zanim udostępnisz je komuś po pomoc.

Lista kontrolna

• Każdy klucz jest zapisany jako sekret lub zmienna środowiskowa, nie w kodzie.
• Żaden plik .env ani klucz nie jest zatwierdzony w Git.
• Klucze sekretne są używane wyłącznie w kodzie po stronie serwera.
• Żadna zmienna sekretna nie ma publicznego prefiksu, jak VITE_ ani NEXT_PUBLIC_.
• Przeszukałem JavaScript działającej strony pod kątem prefiksu każdego klucza i nic nie znalazłem.
• Klucze mają zakres lub ograniczenia tam, gdzie dostawca na to pozwala.
• Klucze testowe i produkcyjne są osobne.
• Funkcje płatne wymagają logowania i mają limity na użytkownika.
• Każdy płatny dostawca ma limit wydatków lub alert.
• Wiem, jak zmienić każdy klucz, a każdy klucz, który kiedykolwiek był odsłonięty, został zmieniony.

Ochrona kluczy w Mythex

Mythex chroni klucze przed trafieniem do kodu i czatu na dwa sposoby:

• Karta żądania sekretów. Gdy agent potrzebuje klucza, pokazuje kartę w czacie, w której wpisujesz wartość w polach formularza, a nie w polu wiadomości; zapisuje się ona jako sekret projektu. Zobacz Sekrety w czacie.
• Ustawienia projektu → Sekrety lub /secrets w czacie, by samodzielnie dodawać lub zmieniać klucze. Zobacz Zmienne środowiskowe i sekrety.

Po zmianie sekretu w opublikowanej aplikacji opublikuj ją ponownie, aby działająca wersja go odebrała. Wyeksportowane projekty nie zawierają sekretów, więc dodaj je ponownie tam, gdzie uruchamiasz kod. Jeśli klucz kiedykolwiek pojawi się w czacie, zmień go u dostawcy.

Resztę przedstartowego przeglądu bezpieczeństwa przejdź według listy kontrolnej bezpieczeństwa dla aplikacji zbudowanych przez AI. Jeśli dodajesz funkcje AI, jak korzystać z API LLM omawia klucze i koszty dokładniej.

Pytania