Jak zabezpieczyć aplikację powstałą w oparciu o Vibe Code przed przekazaniem jej klientom

Jeśli stworzyłeś aplikację z Claude lub Cursor i masz ją niedługo oddać płacącemu klientowi, zatrzymaj się. Kod generowany przez AI zawiera przewidywalne luki bezpieczeństwa — odsłonięte klucze API, brakującą walidację danych wejściowych, domyślne uprawnienia bazy danych, które pozwalają każdemu użytkownikowi zobaczyć dane wszystkich innych. To nie są przypadki brzegowe. Zdarzają się w prawie każdej pierwszej wersji kodu wygenerowanego przez AI.

Ten przewodnik to lista kontrolna bezpieczeństwa przed uruchomieniem. Przejdź przez nią krok po kroku zanim jakakolwiek rzeczywista osoba będzie korzystać z Twojej aplikacji. Jest napisany dla najpopularniejszego stosu vibe codingu (Next.js + Supabase + Vercel), ale zasady stosują się niezależnie od narzędzi, które używasz.

Dlaczego kod generowany przez AI ma problemy z bezpieczeństwem

Modele AI optymalizują pod kątem „czy to działa?" a nie „czy to bezpieczne?" Kiedy powiesz Claude „zbuduj mi menedżer zadań z kontami użytkowników", wygeneruje kod, który tworzy użytkowników, przechowuje zadania i je wyświetla. Czego prawdopodobnie nie zrobi automatycznie: upewni się, że Użytkownik A nie może zobaczyć zadań Użytkownika B, zwaliduje, że pola wprowadzania nie mogą przyjmować złośliwych skryptów, ukryje Twoje klucze API przed narzędziami deweloperskimi przeglądarki, czy doda ograniczanie szybkości, aby zapobiec atakowi na Twoje punkty końcowe.

To nie są problemy AI — to są luki w promptcie. AI buduje to, o co poprosiłeś. Prawdopodobnie nie poprosiłeś o bezpieczeństwo, bo skupiałeś się na funkcjach. Teraz pora wrócić i dodać je.

Krok 1: Przeanalizuj swoje zmienne środowiskowe

To najczęstszy i najniebezpieczniejszy błąd w aplikacjach vibe-codowanych. Sprawdź każdy plik w swoim projekcie pod kątem zakodowanych kluczy API, adresów URL baz danych lub sekretów.

Czego szukać: Przeszukaj swoją bazę kodu pod kątem łańcuchów zaczynających się od sk-, eyJ, sbp_, supabase, postgres://, lub jakichkolwiek długich losowo wyglądających łańcuchów. Sprawdź konkretnie te pliki: każdy plik w katalogu /app lub /pages, każdy plik komponentu, Twój next.config.js, i każdy plik użyteczności.

Naprawienie: Przenieś każdy sekret do zmiennych środowiskowych. W Next.js tylko zmienne przedrostkowe NEXT_PUBLIC_ są odsłonięte dla przeglądarki. Adres URL bazy danych, klucz roli usługi i sekrety API nigdy nie powinny mieć tego przedrostka.

# .env.local (NIGDY nie commituj tego pliku)
SUPABASE_SERVICE_ROLE_KEY=your-secret-key
DATABASE_URL=postgres://...

# Te są ok do odsłonięcia przeglądarce:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Weryfikacja: Sprawdź, czy Twój plik .gitignore zawiera .env.local. Jeśli już commitowałeś sekrety do Git, są one w historii nawet po usunięciu — obrót (regeneracja) każdego odsłoniętego klucza natychmiast.

Krok 2: Włącz zabezpieczenie na poziomie wierszy w Supabase

To pojedynczy najkrytyczniejszy krok, jeśli używasz Supabase. Domyślnie tabele Supabase nie mają żadnych ograniczeń dostępu — każdy z Twoim kluczem anon może czytać i pisać każdy wiersz w każdej tabeli. To oznacza, że Użytkownik A może zobaczyć dane Użytkownika B za pomocą prostego wywołania API.

Naprawienie: Włącz Row-Level Security (RLS) na każdej tabeli, a następnie utwórz zasady, które ograniczą dostęp.

Przejdź do pulpitu nawigacyjnego Supabase → Table Editor → wybierz każdą tabelę → kliknij „RLS Disabled", aby ją włączyć. Następnie dodaj zasady:

Dla typowej aplikacji, gdzie użytkownicy powinni widzieć tylko swoje dane, utwórz zasadę SELECT: auth.uid() = user_id. Utwórz podobne zasady dla INSERT, UPDATE i DELETE.

Przetestuj: Zaloguj się jako Użytkownik A, spróbuj uzyskać dostęp do danych Użytkownika B za pośrednictwem API. Jeśli możesz to zobaczyć, Twoje zasady są złe. Supabase ma edytor SQL, w którym możesz testować zasady bezpośrednio.

Typowy błąd AI: Claude często generuje zapytania Supabase za pomocą klucza service_role (który omija RLS) zamiast klucza anon z odpowiednimi zasadami RLS. Sprawdź, czy kod po stronie klienta używa tylko klucza anon. Klucz roli usługi powinien istnieć tylko w kodzie po stronie serwera (trasach API, akcjach serwera) i nigdy nie być odsłonięty dla przeglądarki.

Krok 3: Prawidłowo dodaj autentykację

Kod autentykacji generowany przez AI często działa, ale robi skróty. Sprawdź te konkretne problemy:

Zarządzanie sesją: Upewnij się, że sesje wygasają. Sprawdź, czy Twoja konfiguracja autentykacji zawiera rozsądny limit czasu sesji (domyślne wartości Supabase są ogólnie w porządku, ale zweryfikuj). Upewnij się, że wylogowanie rzeczywiście unieważnia sesję, a nie tylko czyści lokalny plik cookie.

Wymagania dotyczące hasła: Jeśli masz autentykację email/hasło, wymuś minimalną długość hasła (8+ znaków). Supabase obsługuje to w ustawieniach projektu → Authentication → Password Requirements.

Chronione trasy: Każda strona wyświetlająca dane specyficzne dla użytkownika wymaga oprogramowania pośredniczącego autentykacji. W Next.js App Router utwórz oprogramowanie pośredniczące, które sprawdza prawidłową sesję i przekierowuje nieuwierzytelnionych użytkowników na stronę logowania. Nie polegaj wyłącznie na sprawdzeniach po stronie klienta — użytkownik może je ominąć, trafiając bezpośrednio do Twojego API.

Weryfikacja email: Włącz potwierdzenie email w ustawieniach Supabase Auth. To zapobiega tworzeniu kont z fałszywymi adresami email i dodaje podstawową warstwę ważności konta.

Krok 4: Waliduj wszystkie dane wejściowe

Formularze generowane przez AI zwykle mają podstawową walidację (pola wymagane, format email), ale rzadko chronią przed złośliwymi danymi wejściowymi.

Co dodać:

Walidacja po stronie serwera na każdym punkcie końcowym API. Nigdy nie ufaj walidacji tylko po stronie klienta — można ją ominąć, wysyłając żądania bezpośrednio do API. Użyj biblioteki walidacji, takiej jak Zod (dla TypeScript), aby zdefiniować schematy dla każdego fragmentu danych, które Twoja aplikacja akceptuje.

Oczyszczaj HTML w każdej zawartości generowanej przez użytkownika, która jest wyświetlana. Jeśli Twoja aplikacja ma komentarze, opisy lub jakiekolwiek pole tekstowe, które renderuje się w przeglądarce, użyj biblioteki, takiej jak DOMPurify, aby usunąć niebezpieczne skrypty. Bez tego ktoś może wstrzyknąć JavaScript, który kradnie sesje innych użytkowników (cross-site scripting / XSS).

Ogranicz rozmiar i typ przesyłanego pliku, jeśli Twoja aplikacja akceptuje przesyłanie plików. Programy obsługi przesyłania generowane przez AI często nie mają limitów, co oznacza, że ktoś może przesłać plik o rozmiarze 2GB lub plik wykonywalny. Dodaj limity rozmiaru (5MB jest uzasadnione dla większości aplikacji) i ograniczy typy plików do tego, co naprawdę potrzebujesz (obrazy, pliki PDF itp.).

Krok 5: Zabezpiecz swoje trasy API

Sprawdź każdą trasę API lub akcję serwera w Twojej aplikacji pod kątem tych problemów:

Autentykacja na każdym punkcie końcowym. Każda trasa API, która zwraca lub modyfikuje dane użytkownika, powinna najpierw zweryfikować sesję użytkownika. AI często generuje trasy API, które akceptują żądania od każdego.

Autoryzacja poza autentykacją. Nawet po potwierdzeniu, że użytkownik jest zalogowany, zweryfikuj, że ma prawo dostępu do konkretnego zasobu, o który prosi. „Użytkownik A jest zalogowany" nie oznacza „Użytkownik A może edytować profil Użytkownika B". Sprawdzaj właścicielstwo przy każdym dostępie do danych.

Ograniczanie szybkości. Bez ograniczania szybkości ktoś może wysłać tysiące żądań na sekundę do Twojego API, aby albo przechwycić dane, albo przytłoczyć Twój serwer. Dodaj podstawowe ograniczanie szybkości za pomocą biblioteki, takiej jak rate-limiter-flexible, lub użyj wbudowanego ograniczania szybkości Vercel na Edge Functions.

Metody HTTP. Upewnij się, że Twoje trasy API odpowiadają tylko na metody HTTP, na które powinny. Trasa obsługująca żądania POST nie powinna również odpowiadać na żądania DELETE, chyba że celowo to zaprojektowałeś.

Krok 6: Sprawdź konfigurację wdrożenia

Twoja platforma wdrożenia ma ustawienia bezpieczeństwa, które AI nie konfiguruje dla Ciebie.

Ustawienia Vercel do sprawdzenia: Włącz „Deployment Protection" (wymaga autentykacji do wyświetlenia wdrożeń podglądowych — zapobiega przypadkowemu udostępnianiu przez klientów adresów URL podglądów, które ujawniają pracę w toku). Ustaw limity wydatków, aby zapobiec nieoczekiwanym opłatom, jeśli Twoja aplikacja uzyska skok ruchu. Skonfiguruj dozwolone domeny w nagłówkach CORS.

Domena niestandardowa i SSL: Jeśli dostarczasz to klientowi, skonfiguruj jego niestandardową domenę z HTTPS. Vercel i Netlify obsługują SSL automatycznie. Nigdy nie dostarcz aplikacji klienta w poddomenie .vercel.app — wygląda nieprofesjonalnie i klient nie może jej łatwo przenieść.

Nagłówki: Dodaj nagłówki bezpieczeństwa do next.config.js lub vercel.json: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (zapobiega osadzaniu Twojej witryny w iframes w celu clickjackingu), Strict-Transport-Security (wymusza HTTPS). To jednorazowe dodatki, które zapobiegają całym klasom ataków.

Krok 7: Uruchom ostateczne skanowanie bezpieczeństwa

Zanim cokolwiek przekażesz klientowi, uruchom te bezpłatne sprawdzenia:

npm audit: Uruchom npm audit w katalogu projektu. Flaguje znane luki w bezpieczeństwie Twoich zależności. Napraw problemy o krytycznym i wysokim stopniu ważności. Uruchom npm audit fix, aby automatycznie naprawić tam, gdzie jest to dostępne.

Lighthouse: Otwórz wdrożoną witrynę w Chrome, otwórz DevTools, uruchom audyt Lighthouse. Sprawdzenie wyniku „Best Practices" — przechwytuje typowe problemy z bezpieczeństwem, takie jak brakujący HTTPS, podatne biblioteki i niezabezpieczone nagłówki.

Testy manualne: Zaloguj się jako jeden użytkownik, spróbuj uzyskać dostęp do danych innego użytkownika, modyfikując adresy URL lub wywołania API. Spróbuj przesłać puste formularze, dane wejściowe o zbyt dużych rozmiarach i znaki specjalne (takie jak kodowane ładunki XSS). Jeśli którekolwiek z nich działają, masz problemy do naprawienia.

Lista kontrolna przed uruchomieniem

Wydrukuj to i sprawdź każdy element przed przejściem na żywo:

• Wszystkie sekrety w zmiennych środowiskowych (bez zakodowanych kluczy)
• .env.local w .gitignore (i brak sekretów w historii Git)
• Supabase RLS włączone na każdej tabeli
• Zasady RLS przetestowane (Użytkownik A nie może zobaczyć danych Użytkownika B)
• Kod po stronie klienta używa tylko klucza anon (klucz roli usługi tylko po stronie serwera)
• Autentykacja na każdej trasie API
• Sprawdzenia autoryzacji (weryfikacja własności) przy dostępie do danych
• Walidacja danych wejściowych na każdym formularzu (po stronie serwera, nie tylko po stronie klienta)
• Limity przesyłania plików (rozmiar i typ), jeśli mają zastosowanie
• Ograniczanie szybkości na punktach końcowych API
• Nagłówki bezpieczeństwa skonfigurowane
• npm audit uruchomiony i krytyczne problemy naprawione
• Domena niestandardowa z SSL skonfigurowana
• Wdrożenia podglądowe chronione
• Test dostępu do danych między użytkownikami przeszedł

Najważniejsze

Zabezpieczenie aplikacji vibe-codowanej nie polega na tym, aby zostać ekspertem w bezpieczeństwie. Chodzi o przejście listy kontrolnej, która przechwytuje przewidywalne luki, które AI zostawia. Kroki powyżej zajmują 2–4 godziny i zapobiegają najpowszechniejszym podatnościom. Dla aplikacji skierowanej do klienta to nie jest opcjonalne — to różnica między pracą profesjonalną a odpowiedzialnością.

Jeśli budujesz swoją pierwszą aplikację vibe-codowaną, zacznij od naszego kompletnego przewodnika po vibe codingu. Jeśli chcesz poprawić prompty, które używasz z Claude lub Cursor, spróbuj naszego bezpłatnego optymalizatora promptów. A aby uzyskać rozbicie najlepszych narzędzi kodowania, zobacz Claude Code vs Codex.

Ujawnienie: Niektóre linki w tym artykule to linki partnerskie. Rekomendujemy tylko narzędzia, które osobiście testowaliśmy i regularnie używamy. Sprawdź naszą pełną politykę ujawniania.