Bezpieczeństwo Twojej aplikacji Bolt

„Bezpieczeństwo Bolta" to dwie rzeczy, które warto rozdzielić. Pierwsza to sam projekt w Bolcie: co wklejasz do czatu, gdzie trafiają zmienne środowiskowe, komu udostępniasz projekt i gdzie jest wdrażany. Druga to kod, który Bolt generuje, niemal zawsze SPA na Vite i React podłączona do Supabase, która przynosi te same pięć czy sześć błędów co zawsze. Ten przewodnik obejmuje obie, z plikiem instrukcji, żeby Bolt stosował reguły przy każdym generowaniu, promptem do przeglądu przed wdrożeniem i sposobem sprawdzenia wyniku z zewnątrz.

Część 1: zabezpieczenie projektu w Bolcie

Bolt działa w Twojej przeglądarce i to zmienia, gdzie żyją klucze

Bolt uruchamia cały projekt wewnątrz przeglądarki dzięki WebContainers. Podczas pracy nie ma własnego serwera, więc każdy klucz wpisany do pliku .env jest w projekcie, a z prefiksem VITE_ ląduje wbudowany w bundle, który jest wdrażany. Dla przeglądarki to w porządku tylko z kluczami publicznymi (anon Supabase, publishable Stripe). Sekretne nie mają miejsca we frontendzie: idą do Edge Function w Supabase albo funkcji Netlify, a klient wywołuje funkcję.

To, co wklejasz do czatu, trafia do kodu

Jeśli wklejasz klucz do rozmowy, żeby „podłączyć" usługę, model wpisuje go tam, gdzie go potrzebuje, zwykle do komponentu. Stamtąd podróżuje do wszystkich odwiedzających. Zasada: klucze publiczne idą do .env; sekretne do panelu usługi, która uruchamia funkcję (Supabase lub Netlify), nigdy do czatu. A jeśli wkleiłeś jakiś przez pomyłkę, zrotuj go: historia go zachowuje, nawet gdy usuniesz go z kodu.

Udostępnianie, eksport i wdrażanie

Udostępniony link do projektu pokazuje pełny kod, łącznie z .env. Zanim udostępnisz, sprawdź, co jest w środku. Jeśli eksportujesz do GitHuba, niech repozytorium będzie prywatne, a .env w .gitignore. Wdrożenie jednym kliknięciem idzie na Netlify, na subdomenę .netlify.app albo Twoją domenę; Netlify daje TLS i przekierowanie na HTTPS, ale nie nagłówki bezpieczeństwa, a produkcyjne zmienne środowiskowe konfiguruje się w jego panelu, nie w .env projektu.

Supabase jest Twój

Integracja z Supabase tworzy tabele, polityki i funkcje z czatu. RLS, buckety i ustawienia Auth pozostają Twoją odpowiedzialnością, a Bolt popełnia te same błędy z politykami co Lovable. Przewodnik bezpieczeństwa dla Supabase ma trzy zapytania SQL do audytu projektu w minutę.

Część 2: błędy, które Bolt wkłada do Twojego kodu

• Sekretne klucze w komponentach. Wywołanie OpenAI albo Stripe z Reacta z kluczem w środku. Poszukaj sk_, service_role i Bearer we wdrożonym bundle'u.
• Tabele bez RLS albo z politykami using (true). Gdy zapytanie pada na uprawnieniach, model otwiera politykę zamiast ją naprawić.
• Edge Functions bez uwierzytelnienia. Szablon odpowiada każdemu z Access-Control-Allow-Origin: *; jeśli funkcja wydaje pieniądze, każdy może je wydać.
• Sprawdzanie tylko w interfejsie. Strona administracyjna jest ukryta, jeśli nie jesteś adminem, ale API i tak odpowiada.
• Source mapy na produkcji. Niektóre szablony Vite mają build.sourcemap: true; publikuje to Twój oryginalny kod obok zminifikowanego.
• Niewidoczność dla AI i wyszukiwarek. HTML dociera pusty, a boty ChatGPT czy Perplexity nic nie widzą. Jeśli landing ma znaczenie, prerenderuj go albo oddziel. Szczegóły w dlaczego aplikacje tworzone przez AI są niewidoczne dla AI.
• Brak nagłówków bezpieczeństwa. Ani CSP, ani HSTS, ani X-Frame-Options. Na Netlify dodaje się je plikiem.

Blok, który Bolt zastosuje zawsze

Bolt czyta plik .bolt/prompt w Twoim projekcie jako stałe instrukcje. Utwórz plik i wklej to:

Reguły bezpieczeństwa tego projektu:
- Nigdy nie umieszczaj sekretnych kluczy w kodzie frontendu ani w zmiennych VITE_. Integracje z sekretnymi kluczami idą do Edge Function w Supabase albo funkcji Netlify, która czyta klucz ze swoich zmiennych środowiskowych.
- Każda nowa tabela ma włączone RLS i jedną jawną politykę na operację. Nie używaj using (true) ani with check (true) poza publiczną treścią tylko do odczytu, i mów mi, gdy to robisz.
- Każda funkcja serwerowa weryfikuje JWT użytkownika, ogranicza Access-Control-Allow-Origin do naszej domeny i waliduje dane wejściowe.
- Uprawnienia administratora są sprawdzane w RLS albo na serwerze, nigdy tylko w interfejsie.
- Pliki użytkowników trafiają do prywatnych bucketów z politykami i podpisanymi URL-ami.
- build.sourcemap pozostaje wyłączone na produkcji.
- Wstaw prawdziwy tytuł, meta description i tagi Open Graph do index.html.

I nagłówki dla Netlify, w pliku public/_headers, który wdraża się razem z aplikacją:

/*
  Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  X-Content-Type-Options: nosniff
  X-Frame-Options: DENY
  Referrer-Policy: strict-origin-when-cross-origin
  Permissions-Policy: camera=(), microphone=(), geolocation=()

Prompt do przeglądu przed wdrożeniem

Przejrzyj bezpieczeństwo tego projektu i na razie niczego nie zmieniaj. Odpowiedz listą:
1. Klucze lub tokeny w kodzie frontendu albo w zmiennych VITE_, z plikiem i linią.
2. Tabele bez RLS i polityki z using (true) lub with check (true).
3. Funkcje serwerowe, które nie weryfikują JWT, odpowiadają Access-Control-Allow-Origin: * albo nie walidują danych wejściowych.
4. Akcje administratora chronione tylko w interfejsie.
5. Publiczne buckety z plikami użytkowników.
6. Włączone build.sourcemap i brak pliku _headers.
7. Metadane w index.html wciąż pochodzące z szablonu.
Dla każdego punktu zaproponuj dokładną zmianę i poczekaj na moje potwierdzenie.

Sprawdź wynik z zewnątrz

curl -sI https://twojadomena.com | grep -iE "strict-transport|x-frame|x-content-type"
curl -s https://twojadomena.com | grep -oE '/assets/[^"]+\.js' | head -1
curl -s https://twojadomena.com/assets/index-XXXX.js | grep -oE "sk_live_[A-Za-z0-9]+|service_role|eyJhbGciOi[A-Za-z0-9_-]{20,}" | head -3
curl -sI https://twojadomena.com/assets/index-XXXX.js.map | head -1

Oczekiwane: obecne nagłówki, żadnego klucza w chunku i 404 na source mapie. Potem sprawdź API Supabase bez sesji, jak wyjaśnia przewodnik po Supabase. Scanaris wykonuje te kontrole i około czterdziestu innych w 30 sekund: wykrywa, że aplikacja powstała w Bolcie, szuka sekretów w bundle'u, sprawdza source mapy, nagłówki, CORS, ciasteczka i wystawione pliki, odpytuje tabele Supabase bez sesji i weryfikuje, czy Twoja treść jest czytelna bez JavaScriptu. Dla każdego błędu dostajesz fix prompt do wklejenia w czacie Bolta, a skan może powtarzać się codziennie, bo ponowne wygenerowanie może przywrócić naprawiony błąd.

Często zadawane pytania

Czy zmienne VITE_ są prywatne?

Nie. Vite wbudowuje w bundle wszystko, co zaczyna się od VITE_; to jego sposób na powiedzenie „to jest publiczne". Sekretne klucze nie mają tego prefiksu i nie są czytane z frontendu.

Czy mogę ustawić nagłówki bezpieczeństwa na Netlify?

Tak, plikiem _headers w katalogu publicznym albo przez netlify.toml. Netlify stosuje je przy następnym wdrożeniu; sprawdź curlem.

Co zrobić, jeśli wkleiłem sekretny klucz do czatu Bolta?

Zrotuj go w usłudze źródłowej, nawet jeśli usunąłeś go z kodu: historia projektu i wcześniejsze wdrożenia go zachowują. Potem dodaj go w panelu Supabase lub Netlify i poproś Bolta o przeniesienie integracji do funkcji.