„Bezpieczeństwo Lovable" to dwie rzeczy, które warto rozdzielić. Pierwsza to sam projekt w Lovable: co wklejasz do czatu, gdzie przechowuje sekrety, kto może zobaczyć Twój projekt i gdzie ostatecznie ląduje aplikacja. Druga to kod, który Lovable generuje: SPA w React na Supabase, która zawsze przynosi te same pięć czy sześć błędów. Ten przewodnik obejmuje obie, z blokiem instrukcji do sekcji Knowledge Twojego projektu, promptem do przeglądu przed publikacją i sposobem sprawdzenia wyniku z zewnątrz.
Część 1: zabezpieczenie projektu w Lovable
To, co wklejasz do czatu, zostaje tam
Czat projektu to historia Twojej aplikacji: każdy prompt, każdy klucz, który wkleiłeś „żeby działało", i każda odpowiedź. Jeśli sekretny klucz wchodzi przez czat, model ma tendencję do wpisywania go wprost w kod frontendu, a stamtąd podróżuje w bundle'u do wszystkich odwiedzających. Zasada jest prosta: klucze nigdy nie wchodzą przez czat. Gdy Lovable prosi Cię o sekret do podłączenia usługi, użyj pola sekretów, które oferuje; to zapisuje go jako zmienną Edge Functions w Supabase, po stronie serwera, a wygenerowany kod czyta go przez Deno.env.get.
Sekrety: serwer tak, przeglądarka nie
Lovable umie zrobić z integracją dwie rzeczy: wywołać ją z przeglądarki albo z Edge Function. Pierwsza jest właściwa dla kluczy publicznych (anon Supabase, publishable Stripe, ID projektu). Druga to jedyna opcja dla kluczy sekretnych (OpenAI, Resend, secret Stripe, service_role). Jeśli prosisz o funkcję, a wynik wywołuje usługę z komponentu React z kluczem w środku, poproś wprost o przeniesienie jej do Edge Function. Więcej w sekrety, które Twoja aplikacja wycieka w przeglądarce.
Widoczność projektu i kodu
Publiczny projekt w Lovable wystawia kod i historię promptów każdemu, kto ma link, łącznie z każdym kluczem, który kiedykolwiek wkleiłeś. Sprawdź widoczność w ustawieniach projektu, a jeśli włączyłeś synchronizację z GitHubem, czy repozytorium jest prywatne. Jeśli klucz był kiedyś w publicznym projekcie lub repozytorium, uznaj go za skompromitowany i zrotuj.
Gdzie żyje opublikowana aplikacja
Lovable publikuje na subdomenie .lovable.app albo na Twojej własnej domenie. Ten hosting nie pozwala konfigurować nagłówków bezpieczeństwa ani własnych przekierowań. Dla wielu aplikacji to wystarczy; jeśli potrzebujesz Content-Security-Policy, HSTS lub reguł cache, wyeksportuj do GitHuba i wdróż na Vercelu lub Netlify z ich plikiem konfiguracyjnym. Pamiętaj też, że URL podglądu każdej wersji jest dostępny dla każdego, kto go ma.
Supabase jest Twój, nie Lovable
Gdy podłączasz Supabase (albo używasz zarządzanego backendu Lovable, który pod spodem jest Supabase), Lovable tworzy za Ciebie tabele, polityki i funkcje. Ale RLS, buckety i ustawienia Auth pozostają Twoją odpowiedzialnością. Po CVE-2025-48757 Lovable dodał przegląd bezpieczeństwa przed publikacją; traktuj go jako pierwszy filtr, nie gwarancję, i przejdź przewodnik bezpieczeństwa dla Supabase, który ma trzy zapytania SQL do audytu projektu w minutę.
Część 2: błędy, które Lovable wkłada do Twojego kodu
- Tabele bez RLS albo z politykami
using (true). Źródło CVE i najpoważniejszy błąd. Każdy z kluczem anon czyta i zapisuje Twoje dane. - Sprawdzanie uprawnień tylko we frontendzie. Ścieżka
/admin, która tylko ukrywa przycisk, jeśli użytkownik nie jest adminem. Serwer (RLS albo Edge Function) też musi to sprawdzać, bo API da się wywołać bez interfejsu. - Edge Functions bez uwierzytelnienia i limitów. Szablon odpowiada każdemu, z
Access-Control-Allow-Origin: *, a jeśli wywołuje OpenAI albo wysyła e-maile, każdy może zużyć Twój limit. Wymagaj JWT użytkownika, ogranicz origin i ustaw górny limit żądań na użytkownika. - Publiczne buckety na pliki użytkowników. Lovable tworzy bucket jako publiczny, żeby obrazki „się wyświetlały". Dla prywatnych dokumentów: prywatny bucket i podpisane URL-e.
- Niewidoczność dla AI i wyszukiwarek. Aplikacja to SPA na Vite: HTML dociera pusty, a boty ChatGPT czy Perplexity nic nie widzą. Jeśli landing i blog mają znaczenie, oddziel je od aplikacji. Szczegóły w dlaczego aplikacje tworzone przez AI są niewidoczne dla AI.
- Brak nagłówków bezpieczeństwa i metadanych. Ani CSP, ani HSTS, ani X-Frame-Options, a tytuł jest z szablonu. Pierwsze wymaga wdrożenia poza lovable.app; drugie naprawia jeden prompt.
- Walidacja tylko w formularzu. Pole ma
maxLength, ale Edge Function albo tabela przyjmują, co przyjdzie. Waliduj też na serwerze i w ograniczeniach bazy danych.
Blok do sekcji Knowledge Twojego projektu
W ustawieniach projektu Lovable ma sekcję wiedzy, którą model czyta przy każdym żądaniu. Wklej to, żeby reguły obowiązywały od pierwszego promptu:
Reguły bezpieczeństwa tego projektu:
- Każda nowa tabela ma włączone RLS i jedną jawną politykę na operację. Nigdy nie używaj using (true) ani with check (true) poza tabelami publicznej treści tylko do odczytu, i mów mi, gdy to robisz.
- Nigdy nie umieszczaj sekretnych kluczy w kodzie frontendu. Integracje z sekretnymi kluczami idą do Edge Function, która czyta sekret przez Deno.env.get.
- Każda Edge Function weryfikuje JWT użytkownika, chyba że powiem inaczej, ogranicza Access-Control-Allow-Origin do naszej domeny i waliduje dane wejściowe.
- Uprawnienia administratora są sprawdzane w RLS albo na serwerze, nigdy tylko we frontendzie.
- Pliki wgrywane przez użytkowników trafiają do prywatnych bucketów z politykami i podpisanymi URL-ami.
- Kolumny role, is_admin, plan i credits nie są edytowalne przez użytkownika.
- Wstaw prawdziwy tytuł, meta description i tagi Open Graph do index.html.Prompt do przeglądu przed publikacją
Przejrzyj bezpieczeństwo tego projektu i na razie niczego nie zmieniaj. Odpowiedz listą:
1. Tabele bez RLS i polityki z using (true) lub with check (true).
2. Klucze lub tokeny obecne w kodzie frontendu, z plikiem i linią.
3. Edge Functions, które nie weryfikują JWT, odpowiadają Access-Control-Allow-Origin: * albo nie walidują danych wejściowych.
4. Ścieżki lub akcje administratora chronione tylko we frontendzie.
5. Publiczne buckety z plikami użytkowników.
6. Kolumny uprawnień, które użytkownik może zmienić.
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
Otwórz opublikowaną aplikację w oknie incognito, prawy przycisk, „Pokaż źródło strony", i poszukaj service_role, sk_live, sk- i Bearer w ładowanych plikach JavaScript. Potem sprawdź API Supabase bez sesji:
curl -s "https://TWOJ_PROJEKT.supabase.co/rest/v1/profiles?select=*" -H "apikey: TWOJ_KLUCZ_ANON" -H "Authorization: Bearer TWOJ_KLUCZ_ANON"Jeśli zwraca wiersze, ta tabela jest otwarta. Scanaris robi to i około czterdziestu innych kontroli w 30 sekund: wykrywa, że aplikacja powstała w Lovable, odpytuje tabele Supabase bez sesji, szuka sekretów w bundle'u, sprawdza nagłówki, ciasteczka, CORS i wystawione pliki oraz weryfikuje, czy Twoja treść jest czytelna bez JavaScriptu. Dla każdego błędu dostajesz fix prompt do wklejenia w czacie Lovable z dokładną zmianą, a skan może powtarzać się codziennie, bo ponowne wygenerowanie kodu może przywrócić błąd, który już naprawiłeś.
Często zadawane pytania
Czy Lovable już naprawił problem z RLS?
Lovable dodał przegląd bezpieczeństwa przed publikacją i poprawił szablony, ale model nadal generuje otwarte polityki, gdy zapytanie pada. RLS pozostaje Twoją odpowiedzialnością: użyj zapytań z przewodnika po Supabase.
Czy mogę ustawić nagłówki bezpieczeństwa w aplikacji hostowanej na lovable.app?
Nie z poziomu Lovable. Jeśli ich potrzebujesz, zsynchronizuj z GitHubem i wdróż na Vercelu lub Netlify, gdzie konfiguruje się je plikiem. Aplikację nadal edytujesz w Lovable.
Co zrobić, jeśli wkleiłem sekretny klucz do czatu?
Zrotuj go w usłudze źródłowej, nawet jeśli nie ma go już w kodzie: historia czatu i wcześniejsze bundle go zachowują. Potem dodaj go przez pole sekretów i poproś model o przeniesienie integracji do Edge Function.