Jak zabezpieczyć kod generowany przez AI — Checklist bezpieczeństwa Vibe Coding

Jeśli kod swojej aplikacji pisałeś "od czucia" z Claude lub Cursor i chcesz ją przekazać płacącemu klientowi, czekaj. Kod generowany przez AI zawiera przewidywalne dziury bezpieczeństwa — ujawnione klucze API, brakującą walidację danych wejściowych, domyślne uprawnienia bazy danych, które pozwalają każdemu użytkownikowi zobaczyć dane wszystkich pozostałych. To nie są przypadki graniczne. Pojawiają się w prawie każdym pierwszym wariancie kodu wygenerowanego przez AI.

Ten przewodnik to lista kontrolna bezpieczeństwa przed uruchomieniem. Wykonaj ją krok po kroku, zanim jakikolwiek rzeczywisty użytkownik dotknięty Twoją aplikację. Napisane dla najpopularniejszego stosu (Next.js + Supabase + Vercel), ale zasady mają zastosowanie niezależnie od narzędzi.

Dlaczego kod generowany przez AI ma problemy z bezpieczeństwem

Modele AI optymalizują się 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. Co prawdopodobnie nie zrobi automatycznie: upewni się, że Użytkownik A nie może zobaczyć zadań Użytkownika B, zwaliduje, że pola wejściowe nie mogą zaakceptować złośliwych skryptów, ukryje klucze API przed narzędziami deweloperskimi przeglądarki lub doda limitowanie szybkości, aby zapobiec atakowi na Twoje endpointy.

To nie są błędy AI — to luki w podskazówce. AI buduje to, czego poprosiłeś. Prawdopodobnie nie poprosiłeś o bezpieczeństwo, bo skupiałeś się na funkcjach. Teraz czas wrócić i to dodać.

Krok 1: Audyt zmiennych środowiskowych

To najczęstszy i najbardziej niebezpieczny błąd w aplikacjach pisanych „od czucia". Sprawdź każdy plik w projekcie pod kątem zakodowanych na sztywno kluczy API, adresów URL baz danych lub sekretów.

Czego szukać: Przeszukaj bazę kodów w poszukiwaniu stringów zaczynających się od sk-, eyJ, sbp_, supabase, postgres:// lub dowolnych długich łańcuchów wyglądających losowo. Sprawdź te pliki w szczególności: dowolny plik w katalogu /app lub /pages, dowolny plik komponentu, Twój next.config.js i dowolne pliki narzędziowe.

Rozwiązanie: Przenieś każdy sekret do zmiennych środowiskowych. W Next.js tylko zmienne poprzedzone NEXT_PUBLIC_ są ujawniane w przeglądarce. URL bazy danych, klucz roli usługi i sekrety API nigdy nie powinny mieć tego prefiksu.

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

# Te są okay do ujawnienia w przeglądarce:
NEXT_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Weryfikacja: Sprawdź, czy plik .gitignore zawiera .env.local. Jeśli już zacommitowałeś sekrety do Git, znajdują się w historii nawet po usunięciu — obróć (regeneruj) wszystkie ujawnione klucze natychmiast.

Krok 2: Włącz Row-Level Security w Supabase

To pojedynczy najkrytyczniejszy krok, jeśli używasz Supabase. Domyślnie tabele Supabase nie mają żadnych ograniczeń dostępu — każdy ze swoim anonimowym kluczem 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.

Rozwiązanie: Włącz Row-Level Security (RLS) w każdej tabeli, a następnie utwórz zasady, które ograniczają 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, w której 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 je widzisz, Twoje zasady są błędne. Supabase ma edytor SQL, gdzie możesz testować zasady bezpośrednio.

Typowy błąd AI: Claude często generuje zapytania Supabase przy użyciu klucza service_role (który omija RLS) zamiast klucza anon z właściwymi 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 (trasy API, akcje serwera) i nigdy nie być ujawniany w przeglądarce.

Krok 3: Dodaj autentykację prawidłowo

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

Zarządzanie sesją: Upewnij się, że sesje wygasają. Sprawdź, czy Twoje ustawienie autentykacji zawiera rozsądny limit czasu sesji (ustawienia domyślne Supabase są generalnie w porządku, ale zweryfikuj). Upewnij się, że wylogowanie faktycznie unieważnia sesję, a nie tylko czyści lokalny plik cookie.

Wymagania dotyczące hasła: Jeśli masz autentykację za pomocą poczty e-mail/hasła, wymusz minimalną długość hasła (8+ znaków). Supabase obsługuje to w ustawieniach projektu → Autentykacja → Wymagania dotyczące hasła.

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 ważną sesję i przekierowuje nieuwierzytelnionych użytkowników na stronę logowania. Nie polegaj tylko na kontrolach po stronie klienta — użytkownik może je ominąć, zwracając się bezpośrednio do Twojego API.

Weryfikacja poczty e-mail: Włącz potwierdzenie poczty e-mail w ustawieniach Supabase Auth. Zapobiega to tworzeniu kont z fałszywymi adresami e-mail i dodaje podstawową warstwę ważności konta.

Krok 4: Zwaliduj wszystkie dane wejściowe

Formularze generowane przez AI zwykle mają podstawową walidację (pola obowiązkowe, format e-maila), ale rzadko chronią przed złośliwymi wejściami.

Co dodać:

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

Oczyść HTML w dowolnej treści generowanej przez użytkowników, która jest wyświetlana. Jeśli Twoja aplikacja ma komentarze, opisy lub dowolne 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 typy plików, jeśli Twoja aplikacja akceptuje przesyłane pliki. Procedury obsługi przesyłania generowane przez AI często nie mają limitów, co oznacza, że ktoś mógłby przesłać plik 2GB lub plik wykonywalny. Dodaj limity rozmiaru (5MB jest rozsądne dla większości aplikacji) i ogranicz typy plików do tego, czego rzeczywiście potrzebujesz (obrazy, pliki PDF itp.).

Krok 5: Zabezpiecz swoje trasy API

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

Autentykacja na każdym endpoincie. Każda trasa API zwracająca lub modyfikująca 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, sprawdź, czy ma dostęp do konkretnego zasobu, do którego chce uzyskać dostęp. „Użytkownik A jest zalogowany" nie oznacza „Użytkownik A może edytować profil Użytkownika B". Sprawdź własność na każdym dostępie do danych.

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

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

Krok 6: Sprawdź konfigurację wdrażania

Twoja platforma wdrażania ma ustawienia bezpieczeństwa, które AI nie konfiguruje za Ciebie.

Ustawienia Vercel do sprawdzenia: Włącz „Deployment Protection" (wymaga autoryzacji do przeglądania wdrożeń podglądu — zapobiega przypadkowemu udostępnianiu adresów URL podglądu, które ujawniają pracę w toku). Ustaw limity wydatków, aby zapobiec nieoczekiwanym opłatom, jeśli Twoja aplikacja zostanie uwięziona w przepięciach ruchu. Skonfiguruj dozwolone domeny w nagłówkach CORS.

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

Nagłówki: Dodaj nagłówki bezpieczeństwa do swojego next.config.js lub vercel.json: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (uniemożliwia osadzenie Twojej strony w iframach w celu clickjackingu), Strict-Transport-Security (wymusza HTTPS). To są 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 bezpieczeństwa w Twoich zależnościach. Napraw problemy o krytycznym i wysokim znaczeniu. Uruchom npm audit fix w celu automatycznych poprawek, gdzie są dostępne.

Lighthouse: Otwórz wdrożoną witrynę w Chrome, otwórz DevTools, uruchom audyt Lighthouse. Sprawdź wynik „Best Practices" — wychwytuje on typowe problemy bezpieczeństwa, takie jak brak HTTPS, podatne biblioteki i niezabezpieczone nagłówki.

Testowanie ręczne: 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 przesyłać puste formularze, dane wejściowe o zbyt dużym rozmiarze 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 do produkcji:

• Wszystkie sekrety w zmiennych środowiskowych (bez zakodowanych na sztywno kluczy)
• .env.local w .gitignore (i brak sekretów w historii Git)
• Supabase RLS włączone w 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
• Kontrole autoryzacji (weryfikacja własności) na 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 dotyczy
• Limitowanie szybkości na endpointach API
• Nagłówki bezpieczeństwa skonfigurowane
• npm audit uruchomiony i problemy krytyczne naprawione
• Domena niestandardowa z SSL skonfigurowana
• Wdrożenia podglądu chronione
• Test dostępu do danych między użytkownikami przeszedł

Podsumowanie

Zabezpieczanie aplikacji napisanej „od czucia" to nie chodzi o bycie ekspertem od bezpieczeństwa. Chodzi o przejście przez listę kontrolną, która wychwytuje przewidywalne luki, które AI pozostawia. Kroki powyżej zajmują 2–4 godziny i zapobiegają najczęstszym lukom. Dla aplikacji skierowanej do klienta to nie jest opcjonalne — to jest różnica między pracą profesjonalną a zobowiązaniem.

Jeśli tworzysz swoją pierwszą aplikację pisaną „od czucia", zacznij od naszego kompletnego przewodnika do pisania kodu „od czucia". Jeśli chcesz ulepszyć podpowiedzi, których używasz z Claude lub Cursor, spróbuj naszego bezpłatnego optymizatora podpowiedzi. Aby zapoznać się z przeglądem najlepszych narzędzi do kodowania, zobacz Claude Code vs Codex.

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