Lista kontrolna bezpieczeństwa przed uruchomieniem aplikacji zrobionej z AI

Szybki start jest w porządku, ale jest krótka lista rzeczy, które warto sprawdzić, zanim otworzysz aplikację na świat. Żadna nie wymaga bycia ekspertem od bezpieczeństwa, a wszystkie da się sprawdzić z zewnątrz w parę minut. Ten poradnik omawia każdy punkt w trzech częściach: dlaczego ma znaczenie, jak sprawdzić to samodzielnie i jak to naprawić, z przykładami konfiguracji dla stacków, których aplikacje tworzone przez AI używają najczęściej (Next.js na Vercelu, Supabase, Firebase). Na końcu dostajesz wersję dwuminutową do wklejenia na listę startową.

Jak atakujący znajdują to w kilka minut

Większość włamań do aplikacji tworzonych przez AI to nie sprytne hacki. Ktoś otwiera Twoją stronę, wciska F12, czyta JavaScript, który Twoja aplikacja już wysłała do jego przeglądarki, i kopiuje URL, który Twoja aplikacja i tak wywołuje. Automatyczne skanery robią to samo na masową skalę, odpytując popularne ścieżki jak /.env czy /.git na tysiącach stron dziennie, nawet nie wiedząc, że istniejesz. Wszystko poniżej to rzeczy, które mogą sprawdzić bez żadnego dostępu do Twojego kodu, i właśnie dlatego Ty powinieneś sprawdzić je pierwszy.

1. Żadnych sekretów we frontendzie

Dlaczego to ważne. Klucze API i tokeny należą wyłącznie do serwera. Kiedy asystent AI „podłącza" usługę, często wrzuca klucz prosto do kodu klienta, gdzie każdy może go przeczytać w DevTools. Ujawniony klucz Stripe sk_live_ może przelewać prawdziwe pieniądze; klucz Supabase service_role oddaje całą Twoją bazę; klucz OpenAI lub Anthropic sprawia, że płacisz cudzy rachunek.

Jak sprawdzić. Otwórz stronę, wciśnij F12 → zakładka Sources (albo Network z filtrem JS) i przeszukaj pliki pod kątem ciągów takich jak sk_live, service_role, AKIA, sk-ant, AIza czy -----BEGIN. Jeśli Twój framework używa zmiennych z publicznym prefiksem (NEXT_PUBLIC_, VITE_, NUXT_PUBLIC_), upewnij się, że żadna nie zawiera sekretu: ten prefiks dosłownie znaczy „to idzie do przeglądarki".

Jak naprawić. Przenieś każdy sekret do zmiennej środowiskowej serwera i wykonuj wywołanie z route'a API albo funkcji serverless; przeglądarka rozmawia z Twoim serwerem, nigdy z dostawcą. I zrotuj ujawniony klucz: skoro raz był w publicznym bundle'u, traktuj go jako skompromitowany, nawet po usunięciu. Więcej w sekretach, które Twoja aplikacja wycieka w przeglądarce.

2. HTTPS i nagłówki bezpieczeństwa

Dlaczego to ważne. Serwuj wszystko przez HTTPS i przekierowuj na nie HTTP, żeby nikt nie mógł czytać ani modyfikować ruchu. Potem dodaj nagłówki, których przeglądarki używają do obrony Twoich użytkowników: Content-Security-Policy, żeby ograniczyć wstrzykiwanie, Strict-Transport-Security, żeby przykuć HTTPS, X-Frame-Options przeciw clickjackingowi i X-Content-Type-Options, żeby przeglądarka nie „zgadywała" typów plików. Większość generowanych aplikacji domyślnie nie ma żadnego z nich.

Jak sprawdzić. Odpytaj swoją stronę przez curl -I https://twojadomena.pl i obejrzyj zwrócone nagłówki, albo użyj darmowego narzędzia do sprawdzania nagłówków bezpieczeństwa.

Jak naprawić. W Next.js deklarujesz je w next.config.js; na Vercelu, dla dowolnego frameworka, w vercel.json:

{
  "headers": [
    {
      "source": "/(.*)",
      "headers": [
        { "key": "Strict-Transport-Security", "value": "max-age=31536000; includeSubDomains" },
        { "key": "X-Frame-Options", "value": "SAMEORIGIN" },
        { "key": "X-Content-Type-Options", "value": "nosniff" },
        { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" },
        { "key": "Permissions-Policy", "value": "camera=(), microphone=(), geolocation=()" }
      ]
    }
  ]
}

CSP zasługuje na osobną chwilę: zacznij w trybie Content-Security-Policy-Report-Only, zobacz, co by blokowała, i przełącz ją na egzekwowanie, gdy już niczego nie psuje. Zobacz nagłówki bezpieczeństwa HTTP wyjaśnione po ludzku.

3. Reguły bazy danych (RLS) na każdej tabeli

Dlaczego to ważne. Jeśli używasz Supabase lub Firebase, Twoja aplikacja rozmawia z bazą prosto z przeglądarki, więc reguły bazy to jedyne, co stoi między odwiedzającym a Twoimi danymi. Bez nich każdy z kluczem publicznym czyta i zapisuje Twoje tabele bez logowania: dokładnie ta luka, która stoi za podatnością RLS w Lovable.

Jak sprawdzić. Przy otwartej aplikacji skopiuj wywołanie /rest/v1/ z zakładki Network i otwórz je w oknie incognito. Jeśli zwraca dane bez sesji, jesteś wystawiony. W Supabase Table Editor oznacza tabele czerwoną etykietą „RLS disabled". W Firebase sprawdź, czy reguły nie są wciąż w trybie testowym (allow read, write: if true albo z datą wygaśnięcia).

Jak naprawić. Włącz Row-Level Security na każdej tabeli z polityką domyślnej odmowy i napisz reguły dla każdej operacji powiązane z użytkownikiem. W Supabase minimum dla tabeli z kolumną user_id:

alter table public.items enable row level security;

create policy "items: tylko własne wiersze" on public.items
  for all to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

I nigdy nie polegaj na ukryciu przycisku w interfejsie: żądanie nadal istnieje.

4. Żadnych wystawionych wrażliwych plików

Dlaczego to ważne. Jedno żądanie do /.env może oddać każdy sekret, którego używa Twoja aplikacja; /.git/config pozwala każdemu pobrać całe repozytorium; opublikowane source mapy pozwalają odtworzyć Twój oryginalny kod; zapomniany backup.sql to Twoja baza danych w jednym pliku.

Jak sprawdzić. Spróbuj otworzyć twojadomena.pl/.env, /.git/HEAD, /.DS_Store, /backup.sql w przeglądarce i otwórz jeden plik JS z bundle'a, żeby zobaczyć, czy kończy się linią //# sourceMappingURL= wskazującą na dostępny .map. Na platformach takich jak Vercel czy Netlify .env nigdy nie jest wdrażany, ale na VPS-ie z nginxem albo Apache'em to się zdarza.

Jak naprawić. Zablokuj pliki z kropką na serwerze (w nginx location ~ /\. { deny all; }), wyłącz source mapy na produkcji (productionBrowserSourceMaps: false w Next.js, build.sourcemap: false w Vite) i wynieś kopie zapasowe z folderu publicznego.

5. CORS zamknięty na cztery spusty

Dlaczego to ważne. Polityka CORS, która odbija dowolne źródło z poświadczeniami, pozwala złośliwej stronie czytać dane Twoich użytkowników z użyciem ich sesji. Access-Control-Allow-Origin: * bez poświadczeń jest nieszkodliwy dla danych publicznych; niebezpieczeństwo to odbijanie dowolnego pytającego źródła i dodanie Access-Control-Allow-Credentials: true.

Jak sprawdzić. Odpytaj jeden ze swoich endpointów API przez curl -I -H "Origin: https://evil.example" https://twojadomena.pl/api/cokolwiek. Jeśli odpowiedź zwraca to samo źródło w Access-Control-Allow-Origin plus Allow-Credentials: true, masz problem.

Jak naprawić. Trzymaj zamkniętą listę dozwolonych źródeł (Twoje domeny produkcyjne i co najwyżej domena preview) i porównuj z nią; każde inne źródło nie dostaje nagłówka.

6. Ciasteczka i sesje poprawnie skonfigurowane

Dlaczego to ważne. Ciasteczka sesyjne powinny mieć Secure (tylko HTTPS), HttpOnly (nieczytelne z JavaScriptu, więc XSS ich nie ukradnie) i SameSite=Lax lub Strict (obrona przed CSRF). To jedna linia konfiguracji, która zamyka całą klasę błędów przejęcia konta.

Jak sprawdzić. F12 → Application → Cookies i spójrz na kolumny Secure, HttpOnly i SameSite swojego ciasteczka sesyjnego. Jeśli używasz dostawcy auth (Supabase Auth, Clerk, NextAuth), zwykle wychodzą poprawnie; zawodzą te ciasteczka, które dodaje Twoja własna aplikacja.

Jak naprawić. Przy ustawianiu ciasteczka: Set-Cookie: session=…; Secure; HttpOnly; SameSite=Lax; Path=/. W Expressie: res.cookie(name, value, { secure: true, httpOnly: true, sameSite: 'lax' }).

7. Zależności ze znanymi podatnościami

Dlaczego to ważne. Twoja aplikacja ciągnie za sobą setki pakietów. Podatna wersja biblioteki parsującej dane od użytkownika to punkt wejścia, którego nie napisałeś, ale który i tak jest Twój.

Jak sprawdzić i naprawić. Uruchom npm audit w projekcie i najpierw rozwiąż znaleziska krytyczne i wysokie; włącz Dependabota lub Renovate w repozytorium, żeby łatki same do Ciebie przychodziły. Jeśli Twoja strona wystawia publiczny package.json, reklamujesz też swoje wersje.

8. Limity żądań na endpointach, które kosztują pieniądze lub otwierają drzwi

Dlaczego to ważne. Formularz logowania, rejestracja, wysyłka e-maili i każdy endpoint wywołujący płatne API AI potrzebują limitu na IP lub na konto. Bez niego skrypt próbuje tysięcy haseł albo przez noc nabija rachunek za tokeny.

Jak naprawić. Prosty rate limit po stronie serwera (na IP i na minutę), a u płatnych dostawców limit wydatków ustawiony w ich panelu. Dostawcy auth zwykle mają limity prób już włączone: sprawdź, czy ich nie wyłączyłeś.

9. Błędy, które nie mówią za dużo

Dlaczego to ważne. Strona błędu z pełnym stack trace'em, zapytaniem SQL albo ścieżką serwera to mapa dla atakującego. To samo dotyczy nagłówków takich jak X-Powered-By, które ogłaszają dokładne wersje.

Jak naprawić. Ogólne strony błędów na produkcji, ze szczegółami tylko w Twoich logach. Usuń X-Powered-By (w Next.js poweredByHeader: false).

10. Domena i e-mail gotowe na prawdziwych użytkowników

Dlaczego to ważne. Jeśli wysyłasz e-maile (potwierdzenia, resety hasła), bez SPF, DKIM i DMARC wylądują w spamie albo, co gorsza, każdy będzie mógł wysyłać pocztę podszywając się pod Twoją domenę. A wygasający certyfikat lub domena kładzie całą stronę.

Jak sprawdzić i naprawić. Opublikuj rekordy SPF i DMARC w DNS, włącz DKIM u dostawcy wysyłki i włącz automatyczne odnawianie domeny i certyfikatu. Pół godziny pracy, która zapobiega najgorszemu możliwemu dniu.

W jakiej kolejności naprawiać, jeśli masz godzinę

Najpierw sekrety we frontendzie i reguły bazy danych: dwie luki, które oddają prawdziwe dane każdemu.
Potem wystawione pliki i CORS: tanie w naprawie i intensywnie sondowane przez automatyczne skanery.
Następnie nagłówki, ciasteczka i strony błędów: utwardzają to, co już działa.
Na końcu zależności, limity żądań i e-mail: mniej pilne w dniu startu, niezbędne tydzień później.

Twoja dwuminutowa checklista przed startem

Żadnych sk_live_, service_role ani kluczy prywatnych w Twoim JavaScripcie; zmienne publiczne przejrzane.
HTTPS wymuszony, z HSTS, X-Frame-Options, X-Content-Type-Options i CSP przynajmniej w trybie raportowania.
Row-Level Security (lub reguły Firebase) na każdej tabeli; test incognito zwraca pusto.
.env, .git, kopie zapasowe i source mapy niedostępne.
CORS ograniczony do własnych źródeł, nigdy nie odbija źródła z poświadczeniami.
Ciasteczka z Secure, HttpOnly i SameSite.
npm audit czysty z krytycznych i wysokich znalezisk.
Limity prób na logowaniu, rejestracji i endpointach AI; limity wydatków u dostawców.
Strony błędów bez trace'ów; brak X-Powered-By.
SPF, DKIM i DMARC opublikowane; automatyczne odnawianie domeny i certyfikatu.

Po prostu to załatw

Zamiast sprawdzać to wszystko ręcznie, uruchom Scanaris: weryfikuje te punkty i około 40 innych na Twojej działającej stronie w 30 sekund, porządkuje znaleziska według wpływu i daje Ci gotowy do wklejenia prompt, żeby naprawić każde z nich z Twoim AI, zanim znajdzie je ktoś inny. Włącz monitoring, a powie Ci, kiedy coś z tej listy znów się zepsuje po starcie.

Najczęściej zadawane pytania

Czy to zastępuje profesjonalny audyt bezpieczeństwa?

Nie. Ta lista obejmuje to, co da się sprawdzić z zewnątrz i co zawodzi w niemal każdej aplikacji tworzonej przez AI. Audyt sprawdza też Twoją logikę biznesową, uprawnienia między użytkownikami i sam kod. Ale bez tej listy audyt zacząłby się od tych samych punktów.

Ile to wszystko zajmuje?

Sprawdzenie: dziesięć minut skanerem albo pół godziny ręcznie. Naprawa: od popołudnia do dnia, w zależności od tego, ile punktów zawodzi; sekrety i RLS zajmują najwięcej, bo zmuszają do przeniesienia kodu na serwer.

A po starcie?

Powtarzaj listę za każdym razem, gdy AI wygeneruje nową funkcję dotykającą danych lub kluczy, i ustaw cotygodniowy automatyczny ponowny skan: aplikacje psują się przez zmiany, nie przez upływ czasu.