Poradnik

Checklista bezpieczeństwa aplikacji z Lovable: czy aplikacja jest bezpieczna?

Lovable jako platforma i aplikacja, którą Państwo na nim zbudowali, są zabezpieczane osobno. Lovable skanuje pod kątem typowych błędów, ale aplikacja jest tak bezpieczna, jak jej własne reguły dostępu, klucze i kod serwerowy. Prosimy sprawdzić, że zabezpieczenia na poziomie wierszy są włączone dla każdej eksponowanej tabeli i odpowiadają temu, kto może co widzieć, że żaden tajny klucz nie trafia do przeglądarki, że płatności są potwierdzane na serwerze i że ktoś obserwuje działającą aplikację.

Zespół inżynierów PlutonappsAktualizacja 30 September 2026Fakty sprawdzone na dzień 30 September 2026

Zacznij Talk to us

Za CVE-2025-48757: Wyłączone lub zbyt szerokie RLS
Można udostępnić: Klucz publiczny (anon) Supabase
Nigdy nie udostępniać: Klucza service role ani innych tajnych kluczy
Sprawdzać ponownie: Po każdej zmianie dotyczącej danych lub dostępu

Czy Lovable jest bezpieczny i czy to czyni moją aplikację bezpieczną?

Lovable deklaruje, że wspiera wymagania SOC 2 i RODO, i publikuje dokumentację bezpieczeństwa w swoim trust center. Dotyczy to platformy Lovable: jej infrastruktury, kontroli dostępu i personelu. Nie obejmuje reguł wewnątrz Państwa aplikacji, bo te napisali Państwo (z pomocą Lovable).

Skan bezpieczeństwa Lovable przeprowadza szybką kontrolę przy każdej publikacji: przegląd bazy danych, audyt zależności i kontrolę serwera MCP. Głębszy skan, uruchamiany ręcznie (lub według harmonogramu dla klientów Lovable Enterprise), sprawdza też kontrolę dostępu, nieuwierzytelnione endpointy, wstrzykiwanie, ujawnione sekrety, płatności, uwierzytelnianie i ujawnione dane osobowe. Dokumentacja Lovable jasno mówi, że te narzędzia nie gwarantują pełnego bezpieczeństwa. Skan należy traktować jak czujnik dymu, a nie inspekcję.

Czym było CVE-2025-48757 i czy dotyczy mojej aplikacji?

CVE-2025-48757, opublikowane w maju 2025, opisuje niewystarczające polityki zabezpieczeń na poziomie wierszy w stronach generowanych przez Lovable do 15 kwietnia 2025, które pozwalały nieuwierzytelnionym atakującym czytać lub zapisywać tabele bazy danych. Amerykańska National Vulnerability Database podaje krytyczną ocenę CVSS 3.1 równą 9,3 i zaznacza, że Lovable to kwestionuje, argumentując, że każdy klient odpowiada za ochronę danych własnej aplikacji.

Badacz, który to zgłosił, Matt Palmer, twierdzi, że przeskanował 1645 projektów i znalazł 303 podatne endpointy w 170 z nich oraz że Lovable udostępnił swój skan bezpieczeństwa wraz z Lovable 2.0 w kwietniu 2025. Niezależnie od zdania na temat sporu praktyczna lekcja jest ta sama: jeśli aplikacja została wygenerowana wcześniej lub zmieniali Państwo od tego czasu tabele, prosimy samodzielnie sprawdzić polityki. Polityka, która istnieje, to nie to samo co polityka, która jest poprawna.

Co powinna obejmować checklista bezpieczeństwa Lovable?

Checklista bezpieczeństwa aplikacji z Lovable, z testem dla każdego punktu
Kontrola	Dlaczego to ważne	Jak to przetestować
RLS włączone na każdej tabeli w eksponowanym schemacie	Bez niego Supabase pozwala każdej roli z uprawnieniem czytać i zapisywać całą tabelę	Uruchomić Security Advisor Supabase; wskazuje to reguła 0013 (rls_disabled_in_public)
Polityki zgodne z Państwa regułami	Polityka taka jak USING (true) przejdzie skan, a i tak przepuści wszystkich	Zalogować się jako użytkownik A, zażądać wierszy użytkownika B przez API i oczekiwać pustego wyniku
Tabele z RLS, ale bez polityki	Blokują wszystko, co objawia się jako zepsuta funkcja, a nie wyciek	Reguła Advisora 0008 (rls_enabled_no_policy); potem napisać politykę, której potrzebuje funkcja
Brak tajnych kluczy w przeglądarce	Klucz service role omija każdą politykę RLS	Przeszukać zbudowany JavaScript pod kątem sb_secret_ lub starszego klucza service_role; zmienić każdy klucz, który kiedykolwiek wyciekł
Kontrole po stronie serwera dla wszystkiego, co kosztuje	Kod klienta może edytować osoba, która z niego korzysta	Wywołać funkcję edge bezpośrednio ze zmienioną ceną lub planem i oczekiwać odmowy
Ograniczanie liczby zapytań przy rejestracji, logowaniu i wywołaniach AI	Nielimitowane zapytania zamieniają się w nadużycia lub niespodziewany rachunek	Na środowisku testowym wysłać skryptem 100 szybkich zapytań i potwierdzić, że większość zostaje odrzucona
Ochrona przed ujawnionymi hasłami i MFA dla administratorów	Hasła użyte ponownie po innych wyciekach to częsta droga włamania	Spróbować użyć przy rejestracji hasła znanego z wycieku
Dziennik audytu i monitoring błędów	Nie da się zbadać czegoś, czego nie zapisano	Wprowadzić zmianę administracyjną na środowisku testowym i znaleźć ją w dzienniku

Na podstawie dokumentacji Supabase o RLS, kluczach API i doradcach bazy danych oraz dokumentacji bezpieczeństwa Lovable, stan na 30 wrz 2026.

Jak naprawić błędy RLS w Supabase w aplikacji z Lovable?

Błędy RLS występują w dwóch przeciwnych odmianach i warto wiedzieć, z którą mają Państwo do czynienia.

Brak uprawnień (błąd Postgres 42501 lub pusty wynik). RLS jest włączone i żadna polityka nie pozwala na żądanie. To RLS działające poprawnie. Prosimy napisać najwęższą politykę, która pozwala funkcji działać, na przykład wiersze, w których kolumna właściciela równa się identyfikatorowi zalogowanego użytkownika.
Wszystko działa dla wszystkich. Groźniejszy przypadek. Polityka taka jak USING (true) albo brak włączonego RLS przepuszcza każdego użytkownika. Advisor Supabase wskazuje polityki zbyt liberalne (reguła 0024, permissive_rls_policy) i polityki istniejące przy wyłączonym RLS (reguła 0007, policy_exists_rls_disabled).
Polityki czytające metadane użytkownika. Supabase ostrzega przed opieraniem polityk na metadanych, które użytkownik może sam edytować (reguła 0015, rls_references_user_metadata). Zamiast tego prosimy użyć tabeli kontrolowanej przez serwer, na przykład tabeli członkostwa w zespole.

Gdy poproszą Państwo Lovable o naprawę polityki, prosimy potem ponownie uruchomić test z dwoma użytkownikami. Prompt, który usuwa błąd, może to zrobić przez poszerzenie dostępu – a to dokładnie ta awaria, której próbują Państwo zapobiec.

Które klucze można bezpiecznie ujawnić w aplikacji z Lovable?

Dokumentacja Supabase mówi, że klucz publiczny (anon) można bezpiecznie ujawnić, bo sięga tylko tam, na co pozwalają zabezpieczenia na poziomie wierszy. Tajny klucz, w tym klucz service role, omija każdą politykę RLS i nigdy nie może trafić do przeglądarki, opublikowanej aplikacji ani systemu kontroli wersji. Hasło w słowniku o kluczu anon i kluczu service role wyjaśnia różnicę. Sekrety usług zewnętrznych, takie jak klucze Stripe czy dostawcy e-maili, należą do sekretów funkcji edge, a nie do kodu aplikacji. Zobacz zarządzanie sekretami.

Jak często sprawdzać ponownie działającą aplikację z Lovable?

Po każdej zmianie dotyczącej danych, dostępu lub płatności, a wszystko inne – według harmonogramu: w zależnościach pojawiają się nowe podatności, klucze należy rotować, a nowe tabele przychodzą z nowymi politykami. Dlatego bezpieczeństwo działa lepiej jako nawyk niż jako audyt. W naszych planach kontrole bezpieczeństwa, code review i testy regresji są uruchamiane przy każdej zmianie, zanim trafi na produkcję, a zatwierdza ją inny inżynier niż autor.

Najczęściej zadawane pytania

Czy Lovable jest bezpieczny dla prawdziwej aplikacji biznesowej?

Lovable to rozsądne miejsce do budowania i kształtowania aplikacji, a do tego skanuje pod kątem typowych błędów bezpieczeństwa. To, czy gotowa aplikacja jest bezpieczna, zależy od jej własnych reguł dostępu, kluczy i kodu serwerowego, które należy zweryfikować, zanim pojawią się prawdziwi użytkownicy i prawdziwe dane. Dokumentacja Lovable mówi, że jego skany nie gwarantują pełnego bezpieczeństwa.

Czy klucz anon Supabase w mojej aplikacji z Lovable to problem bezpieczeństwa?

Nie. Supabase opisuje klucz publiczny (anon) jako bezpieczny do ujawnienia, bo sięga tylko tam, na co pozwala RLS. Staje się problemem dopiero, gdy RLS jest wyłączone lub zbyt szerokie. Klucz service role to co innego: omija RLS i nigdy nie może być w przeglądarce.

Czy CVE-2025-48757 nadal dotyczy aplikacji z Lovable?

CVE obejmuje strony generowane przez Lovable do 15 kwietnia 2025, a Lovable je kwestionuje. Od tego czasu Lovable dodał skan bezpieczeństwa. Każda aplikacja, stara czy nowa, nadal może zawierać zbyt szeroką politykę, więc prosimy przetestować własne tabele z dwoma kontami użytkowników, zamiast polegać na dacie.

Ile kosztuje przegląd bezpieczeństwa aplikacji z Lovable?

Jednorazowe przeglądy sprzedaje za stałą cenę wielu freelancerów i firm. W planie Plutonapps kontrole bezpieczeństwa i code review obejmują każdą zmianę w ramach miesięcznej ceny, obok budowy, testów, wydań i utrzymania aplikacji. Plany i ceny są w naszym cenniku.

Czy mogę sam przeprowadzić kontrole bezpieczeństwa?

Tak. Lovable uruchamia szybki skan przy publikacji, Security Advisor Supabase jest w panelu projektu, a test z dwoma użytkownikami z checklisty wymaga tylko dwóch kont testowych. Trudniej samodzielnie robić to przy każdej zmianie, tak długo, jak aplikacja działa.

Z naszych realizacji

Looph

Zabezpieczenia na poziomie wierszy na wszystkich 172 tabelach bazy danych, z 1180 politykami. Działa produkcyjnie.

Zulu

67 z 70 tabel ograniczonych do przestrzeni roboczej i sprawdzanych testem międzynajemcowym. Przed premierą.

Pojęcia na tej stronie

Aplikacja z Lovable nie działa na produkcji? Jak przygotować ją do produkcji — Dlaczego aplikacje działające w podglądzie psują się przy prawdziwych użytkownikach, jakie kontrole czynią je gotowymi na produkcję i kto je utrzymuje.
Jak przenieść aplikację z Lovable Cloud do własnego Supabase — Lovable Cloud a własny Supabase, co obejmuje eksport i czego nie obejmuje, oraz plan przełączenia, który utrzymuje produkcję w działaniu.
Jak zatrudnić programistę Lovable (i ile to kosztuje) — Freelancerzy, agencje partnerskie Lovable i abonament inżynierski porównane pod względem kosztów, zakresu i tego, kto potem utrzymuje aplikację.
Plany i cennik

Źródła

Każdy zewnętrzny fakt na tej stronie sprawdzono ze wskazanym źródłem dnia 30 September 2026. Ceny i plany się zmieniają; aktualne dane są pod linkami.