Lovable programos sauga: 12 patikrų ir dar 8

Esu Denys, full-stack ir AI inžinierius. Šį mėnesį taisiau kliento programą, sukurtą su Lovable. Viskas veikė ant Supabase, kaip įprasta, o saugos pataisų buvo tiek, kad atrodė, jog programa iš jų ir sudaryta. Štai sąrašas, kurį dabar pereinu kiekviename Lovable ar Supabase projekte, prieš pavadindamas klientų duomenis apsaugotais.

Ar Lovable saugus? Iki šiol žinomos saugos problemos

Platforma sukuria ir talpina jūsų programą, tačiau programos sauga daugiausia priklauso nuo už jos esančios Supabase duomenų bazės, nes programa šią duomenų bazę skaito ir rašo tiesiai iš naršyklės. Viešai žinomi atvejai rodo abiejų rūšių problemas:

Kada	Kas nutiko	Šaltinis
2025 m. kovas	CVE-2025-48757: nuskaičius 1645 Lovable demonstracines programas, 170 iš jų rasta 303 endpoint’ai, kurie atiduodavo duomenis kiekvienam, turinčiam viešąjį raktą, nes RLS trūko arba buvo per laisvas	Matt Palmer atskleidimas, 2025 m. gegužė
2026 m. vasaris	Viena Lovable talpinama programa atskleidė 18 697 vartotojų įrašus; jos funkcijų prieigos patikra įleido anonimus lankytojus ir blokavo prisijungusius vartotojus. Lovable teigė, kad dalis kodo nebuvo sugeneruota Lovable	The Register, 2026 m. vasario 27 d.
2026 m. vasario 3 d. – balandžio 20 d.	Dėl platformos regresijos kiti Lovable vartotojai galėjo skaityti viešų projektų pokalbių istoriją ir šaltinio kodą	Lovable pranešimas apie incidentą, 2026 m. balandžio 22 d.

Pirmos dvi yra programos lygio spragos, tokios, kokias pagauna žemiau esančios patikros. Trečia buvo paties Lovable klaida, ir Lovable ją ištaisė; jūsų dalis yra nelaikyti raktų pokalbiuose ir kode (3 patikra) ir pakeisti visus, kurie ten buvo. Lovable prieš paskelbiant paleidžia saugos skenavimą, tačiau imtis veiksmų pagal jo rezultatus turite jūs, o CVE paskelbimo metu šis skenavimas tikrino, ar politika egzistuoja, o ne ar ji teisinga. Taigi klausimas „ar Lovable saugus” susiveda į tai, ar jūsų duomenų bazė išlaiko žemiau esančias patikras.

Kodėl Lovable programoje nepakanka „RLS įjungtas”?

Lovable programa su duomenų baze kalbasi tiesiai iš naršyklės. Jūsų pačių backend’o tarp jų nėra: puslapis kviečia Supabase Data API viešuoju raktu, o Postgres nusprendžia, kas grįžta (kurias schemas šis API pateikia, nustatoma atskirai, tai aprašyta Supabase exposed schemas). Todėl kiekviena taisyklė, sauganti klientų duomenis, turi gyventi duomenų bazėje, o duomenų bazė turi kelias duris.

Row level security yra vienos iš jų. Teisės (grants) nusprendžia, ar rolė apskritai gali liesti lentelę, politikos nusprendžia, kurias eilutes, o trys dalykai politikas apeina visiškai: slaptasis raktas, view, sukurti be security_invoker, ir SECURITY DEFINER funkcijos. Tai ne teorija. Paties Lovable saugos vadove prašoma peržiūrėti jo sukurtas RLS politikas, o aukščiau minėtas CVE-2025-48757 yra tai, kas nutinka, kai niekas to nedaro.

Promptas: įklijuokite jį į Lovable ar Claude

Galite įklijuoti kaip yra. Paskui patys patikrinkite rezultatą: AI mėgsta sakyti „padaryta”, kai taip nėra, o promptas, po kurio klaida dingsta, gali tai padaryti išplėsdamas prieigą.

Patikrink šį projektą dėl saugos, ištaisyk, ką rasi, ir pasakyk, ką pakeitei:

1. Testuok su dviem vartotojais dviejose įmonėse. Vartotojas A bando skaityti, redaguoti, trinti B įrašus pagal id, per API, paiešką ir eksportus. Viskas turi nepavykti.
2. RLS kiekvienoje lentelėje, politikos tikrina eilutės savininką arba įmonę. „Prisijungęs" nepakanka.
3. Service role raktas niekada nėra frontend'e. Edge funkcijos, kurios jį naudoja, pačios tikrina vartotoją ir filtruoja pagal įmonę, raktas apeina RLS.
4. Rolės, planas ir įmonės id niekada ne iš vartotojo metaduomenų, vartotojai juos gali keisti. Laikyk juos lentelėje, kurią rašo tik serveris.
5. Kai užklausa siunčia du id (projektas + užduotis), patikrink, ar užduotis priklauso tam projektui.
6. Atimk iš anon ir authenticated visas teises į lenteles, grąžink tik tai, ko reikia politikoms. RLS nesustabdo TRUNCATE. Kiekviena migracija, kuri kuria lentelę, turi jos GRANT: nuo 2026 m. spalio 30 d. Supabase naujų lentelių automatiškai nebeatveria, o programa gauna klaidą 42501.
7. Visi view su security_invoker = true, kitaip jie apeina RLS.
8. Storage bucket'ai: vartotojai skaito ir rašo tik savo failus, jokių viešų bucket'ų privatiems duomenims.
9. SECURITY DEFINER funkcijos: NULL turi reikšti atmetimą, o ne leidimą.
10. Užklausų limitai prisijungimui, registracijai, slaptažodžio atstatymui ir OTP, laikomi DB, o ne atmintyje.
11. Validuok visą įvestį serveryje.
12. Paleisk Supabase security advisor ir ištaisyk kiekvieną įspėjimą.

12 patikrų ir kaip įrodyti kiekvieną

1. Du vartotojai dviejose įmonėse

Sukurkite vartotoją A įmonėje 1 ir vartotoją B įmonėje 2, kiekvieną su keliais įrašais. Prisijunkite kaip A ir bandykite skaityti, redaguoti ir trinti B įrašus pagal id, per API, per paiešką ir per kiekvieną eksportą. Kiekvienas bandymas turi negrąžinti nieko arba baigtis klaida. Tai vienintelis testas, kuris pagauna didžiąją dalį to, kas toliau, nes jis tikrina, ką daro užpuolikas, o ne tai, ką jūs parašėte.

Pridėkite trečią vartotoją, priklausantį abiem įmonėms. Politika „kviečiantysis yra eilutės įmonės narys” leidžia šiam vartotojui skaityti įmonės 2 eilutes, kol jis dirba įmonėje 1. Kitoje Supabase programoje mano zondas su tokiu vartotoju grąžino kitos įmonės dokumentą, kol užklausa nepradėjo filtruoti ir pagal užklausos įmonę. Tai aprašiau pastaboje vartotojas dviejose org., kurio RLS neatskyrė.

2. RLS kiekvienoje lentelėje, apribotas savininku ar įmone

auth.uid() is not null reiškia „bet kuris prisijungęs vartotojas”, o viešame registracijos puslapyje tai reiškia bet ką. Kiekviena politika lygina eilutės savininką ar įmonę su kviečiančiuoju. Išvardykite lenteles, kuriose RLS vis dar išjungtas:

select c.relname
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind in ('r', 'p') and not c.relrowsecurity;

3. Slaptasis raktas niekada nėra frontend’e

Service role raktas ir naujesnis sb_secret_ raktas apeina kiekvieną politiką. Ieškokite abiejų sukompiliuotame JavaScript ir pakeiskite kiekvieną raktą, kuris kada nors buvo paskelbtas. Edge funkcijos, kurios jį naudoja, pačios turi patikrinti, kas yra vartotojas, ir filtruoti pagal įmonę, nes su šiuo raktu daugiau nieko to nepadarys.

4. Rolės, planas ir įmonės id niekada ne iš vartotojo metaduomenų

raw_user_meta_data yra tai, ką klientas atsiuntė į signUp, ir vartotojai vėliau gali tai pakeisti. Kitoje programoje naujo vartotojo trigeris iš ten skaitė pakviestą rolę, todėl kiekvienas užsiregistravęs galėjo perduoti savininko rolę ir tapti Owner. Roles, planus ir įmonių id laikykite lentelėje, kurią rašo tik serveris, arba app_metadata. Visa istorija: rolė, paimta iš registracijos metaduomenų.

5. Du id vienoje užklausoje: patikrinkite, ar jie priklauso kartu

Kai užklausa neša projekto id ir užduoties id, autorizuoti projektą nepakanka. Vartotojas, turintis teises projekte A, siunčia A kartu su sekcijos id iš projekto B, ir eilutė patenka į B. RLS to nepagauna, nes insert pažymi eilutę paties užpuoliko projekto id, o būtent jį politika ir tikrina. Prieš rašydami patikrinkite, ar antrinis įrašas priklauso pirminiam.

6. Teisės (grants): atimkite viską, grąžinkite tik reikalingą

Teisės ir politikos yra du atskiri sluoksniai. Pridėjus politikas teisė nėra atimama, todėl Supabase RLS vadove sakoma atimti ir grąžinti aiškiai. Kitame projekte supabase/postgres 17.6.1 atvaizdas buvo davęs anon ir authenticated TRUNCATE, REFERENCES, TRIGGER ir MAINTAIN teises kiekvienoje public lentelėje, o TRUNCATE jokia politika netaikoma. Data API neturi TRUNCATE endpoint’o, todėl tai nėra vienos užklausos išvalymas, bet jokiai kliento rolei to nereikia, o kiekviena funkcija, vykdanti SQL tos rolės teisėmis, tai paveldi.

revoke all on public.orders from anon, authenticated;
grant select, insert, update on public.orders to authenticated;

select grantee, table_name, privilege_type
from information_schema.role_table_grants
where table_schema = 'public' and grantee in ('anon', 'authenticated')
order by table_name;

Viena data keičia šią patikrą. Supabase nebeatveria naujų lentelių automatiškai: naujiems projektams nuo 2026 m. gegužės 30 d., o visiems esamiems projektams nuo 2026 m. spalio 30 d., įskaitant tuos, kuriuos sukūrė Lovable. Po to lentelė, kurią Lovable ar migracija sukuria be aiškaus GRANT, programai nematoma: užklausa nepavyksta su klaida 42501, o funkcija, naudojanti lentelę, nustoja veikti. Todėl kiekviena migracija, kuri kuria lentelę, dabar turi ir jos teises, šalia enable row level security ir politikų.

Dvi dalys lieka tos pačios. Esamos lentelės išlaiko savo teises, todėl atimti nereikalingas vis dar jūsų darbas. O pakeitimas atima tik select, insert, update ir delete: Lovable projekte su naujomis numatytosiomis reikšmėmis naujos lentelės vis tiek gaudavo TRUNCATE, REFERENCES, TRIGGER ir MAINTAIN anon ir authenticated. Pirmiausia atimti viską, paskui suteikti, vis dar yra saugi tvarka.

7. Kiekvienas view su security_invoker = true

View veikia savininko teisėmis, o Supabase savininkas paprastai yra postgres, todėl view virš saugomos lentelės išduoda kiekvieną eilutę, kurią politikos sulaiko. Postgres 15 ir naujesnėje versijoje:

alter view public.customer_summary set (security_invoker = true);

8. Storage: tik savi failai, jokio viešo bucket’o privatiems duomenims

Viešas bucket’as atiduoda bet kurį failą bet kam, kas turi URL. Privatūs failai turi būti privačiame bucket’e su storage.objects politikomis, kurios tikrina savininką ar įmonę, dažniausiai pagal pirmą kelio aplanką. Perkėlę projektą suskaičiuokite veikiančias storage politikas: vienoje programoje po perkėlimo nepavyko nė vienas įkėlimas, nes politikų migracija niekada nebuvo paleista, o lentelė turėjo įjungtą RLS ir nulį politikų.

9. SECURITY DEFINER funkcijos: NULL reiškia atmetimą

PL/pgSQL if not (has_permission or assignee_id = auth.uid()) nekelia išimties, kai assignee_id yra null: visa sąlyga yra null, o if ją praleidžia. Ta pati išraiška politikos viduje yra saugi, nes ji null traktuoja kaip atmetimą. Vienoje programoje dėl to rolė su visais išjungtais leidimais galėjo veikti su visomis 3683 užduotimis, nes nė viena neturėjo vykdytojo. Apgaubkite sąlygą coalesce(…, false). Detalės: NULL PL/pgSQL IF NOT praleido patikrą 3683 užduotims.

10. Užklausų limitai, laikomi duomenų bazėje

Apribokite prisijungimą, registraciją, slaptažodžio atstatymą ir OTP, o skaitiklį laikykite Postgres. Lovable programoje limitai gyveno kintamajame edge funkcijos viduje. 2026 m. spalio 17 d. patikrinau talpinamą projektą: kiekviena užklausa vyko naujame isolate, todėl skaitiklis atmintyje visada buvo 1 ir limitas niekada negalėjo suveikti. Vietinis supabase functions serve isolate naudoja pakartotinai, todėl tas pats kodas praėjo visus vietinius testus.

Raktas svarbus tiek pat, kiek saugykla. Talpinamoje platformoje paskutinis X-Forwarded-For šuolis yra paties Supabase proxy, todėl raktas pagal jį sudeda visus kviečiančiuosius į vieną krepšį, o x-client-ip nustato klientas. Mano zonde tikrą klientą nešė cf-connecting-ip. Pataisa buvo SECURITY DEFINER funkcija claim_rate_limit(bucket, key, max, window), kurią gali vykdyti tik service role, serializuota advisory užraktu ir sauganti IP ar vartotojo id maišą, o ne neapdorotą reikšmę.

11. Validuokite visą įvestį serveryje

Ką bepatikrintų forma, API priima viską, ką atsiunčia klientas. Ilgiai, formatai, enum’ai ir nuosavybė tikrinami duomenų bazėje (constraints, trigeriai) arba edge funkcijoje, niekada tik React.

12. Supabase Security Advisor, kiekvienas įspėjimas

Atidarykite Advisors, tada Security Advisor ir ištaisykite kiekvieną radinį. Jis pažymi lenteles su išjungtu RLS, view, kurie apeina RLS, politikas, skaitančias vartotojo metaduomenis, pernelyg leidžiančias using (true) politikas ir funkcijas su kintamu search_path. Patikrų 1, 5, 9 ir 10 jis nemato, nes jos yra apie logiką, o ne konfigūraciją.

Ko Lovable programa mane išmokė, ko tos 12 nemato?

Tai išaugo iš kliento programos ir jos peržiūrų. Nė viena jų nerodoma skeneryje.

1. Laukai, kurių klientas negali nustatyti. Klientas pats atsiuntė status: 'approved', taip praleisdamas moderavimą. UPDATE politika, kurios with check laisvesnis už jos using, taip pat leidžia vartotojui perkelti eilutę kitam savininkui. Politika negali apskaičiuoti reikšmės, todėl BEFORE INSERT OR UPDATE trigeris iš naujo išveda status, rolę, kainą ir įmonę iš paties serverio duomenų ir ignoruoja tai, ką atsiuntė klientas.
2. Kiekvienas rašymo kelias, ne tik pagrindinis insert. Kai pagrindinis insert buvo pataisytas, ta pati apėjimo spraga liko priedų, komentarų, soft-deleted elemento atkūrimo ir skaitiklių keliuose. Išvardykite visus saugomo stulpelio rašytojus, prieš taisydami pirmąjį.
3. Allow-list’ai, ne deny-list’ai. Suklastoti įrašai užtruko penkis peržiūros ratus, nes kiekviena pataisa užblokuodavo vieną kombinaciją ir palikdavo gretimą atvirą. Trigeris, leidžiantis tik išvardytas tipo ir būsenos kombinacijas, uždarė visą klasę iš karto.
4. Funkcijos taip pat yra API. Kiekviena public funkcija pasiekiama per /rpc bet kuria role su EXECUTE, o RLS funkcijoms netaikomas. Kiekvienai SECURITY DEFINER funkcijai nustatykite set search_path = '', atimkite EXECUTE iš public, anon ir authenticated ir suteikite jį tik rolei, kuriai reikia.
5. EXECUTE atėmimas gali sugadinti viešus puslapius. Postgres tikrina EXECUTE kiekvienai funkcijai, naudojamai kiekvienoje rolei taikomoje politikoje, net šakoje, kuri niekada nebūtų vykdoma. Kai anon neteko EXECUTE is_admin(), kiekvienas anoniminis skaitymas baigėsi klaida 42501. Tik administratoriams skirtos politikos eina to authenticated, o vieši skaitymai gauna savo politiką be administratoriaus šakos.
6. Registracija su įjungtu el. pašto patvirtinimu. Su įjungtu patvirtinimu signUp negrąžina sesijos, todėl bet koks profilio įrašymas iškart po jo vyksta kaip anon ir tyliai neįrašo nieko. Lovable projektuose dažnai įjungtas auto-confirm, kuris klaidą paslepia. Laukus perduokite signUp({ options: { data } }), leiskite naujo vartotojo trigeriui juos validuoti ir įrašyti, o tuos metaduomenis laikykite nepatikimais (4 patikra).
7. Testai, kurie praeina dėl netinkamos priežasties. Vietinis stekas ir talpinamas projektas turėjo skirtingas numatytąsias teises, todėl „anon negali įterpti” vietoje praėjo, nes trūko teisės, o ne todėl, kad RLS veikė. Neigiamas testas ką nors reiškia tik tada, kai egzistuoja teigiama teisė. Palyginkite pg_default_acl vietoje ir produkcijoje.
8. Gyva duomenų bazė, o ne migracijų failai. Po migracijos ar projekto perkėlimo palyginkite, kas iš tikrųjų veikia: pg_policies, pg_get_functiondef kiekvienai apsaugai ir aukščiau minėtas teises. Kitoje programoje nauja migracija nukopijavo seną funkcijos kūną ir tyliai atšaukė vėlesnę pataisą.

Ar Lovable programa atitinka GDPR?

Lovable nepadaro programos atitinkančios ar neatitinkančios; tai lemia, ką programa daro su asmens duomenimis, o saugumo peržiūra į tai neatsako. Tai šešios spragos, kurias tikrinu Lovable Cloud programoje, kiekviena su pataisa:

1. Išvardykite visus duomenų tvarkytojus. Lovable Cloud valdo duomenų bazę, autentifikaciją, saugyklą ir funkcijas Supabase platformoje, Lovable talpina svetainę ir gali siųsti prisijungimo laiškus, o Lovable AI Gateway perduoda tekstą modelio teikėjui. Pridėkite kiekvieną el. pašto, DI ar scraping paslaugą, kurią kviečia jūsų funkcijos. Kiekvienai, gaunančiai asmens duomenis, reikia duomenų tvarkymo sutarties (DPA), o esančiai už ES ribų – dar ir perdavimo mechanizmo. Talpinimo regiono kode nėra, tad jo paklauskite.
2. Ištrinkite naudotoją, kuris turi turinio. To naudotojo parašyto turinio išoriniai raktai gali užblokuoti trynimą, ir tada prašymo ištrinti duomenis įvykdyti nepavyksta. Nustatykite tiems raktams cascade arba set null, pridėkite trynimo trigerį, kuris pašalina ir naudotojo el. pašto žurnalus bei prisijungimo žetonus, ir laikykite duomenų bazės testą, kuris ištrina tokį naudotoją.
3. Nustatykite saugojimo terminą. El. pašto žurnalai, peržiūrų sekimas, nepavykusių laiškų eilės ir minkštai ištrintos eilutės dažnai laiko asmens duomenis be pabaigos datos. Suplanuota užduotis, kuri po nustatyto laiko galutinai ištrina minkštai ištrintas eilutes ir pašalina jų failus, uždaro didžiąją dalį.
4. Laiškų sekimas tik su sutikimu. Atidarymų ir paspaudimų registravimas kiekvienam gavėjui pagal ePrivacy taisykles reikalauja sutikimo: sutikimo žymė, pagal nutylėjimą išjungta, su laiko žyma, kurią nustato serveris, o ne klientas.
5. Laikykite adresus už funkcijų žurnalų ribų. Edge function žurnalai nevalomi, tad console.log su gavėjo adresu jį ten palieka. Registruokite ID ir kiekius.
6. Įjunkite el. pašto patvirtinimą. Su automatiniu patvirtinimu bet kas gali užsiregistruoti su adresu, kuris jam nepriklauso, ir įnešti į programą tikro žmogaus adresą. Aukščiau esančio sąrašo 6 punktas apima registracijos pusę.

Kaip patikrinti savo programą: funkcijose suraskite API raktus ir išvardykite paslaugas, ištrinkite testinį naudotoją su turiniu, ieškokite @ funkcijų žurnaluose ir paprašykite kiekvieno teikėjo duomenų tvarkymo sutarties. Tai nėra teisinė konsultacija.

Kaip neleisti tam sugrįžti?

Kiekviena patikra aukščiau yra užklausa ar testas, todėl laikykite jas repozitorijoje ir paleiskite prieš kiekvieną diegimą. Supabase pgTAP testai apima teises, politikas ir funkcijas; dviejų įmonių testas priklauso šalia jų. Jei jūsų programa turi roles ir leidimų ekraną, nepakanka ir vieno testo kiekvienai politikai: kiekvieną leidimo langelį įrodau prieš produkcijos kopiją, tai aprašyta kaip testuoti Supabase RLS, kur 30 iš 87 langelių nieko nedarė. Nemokama Supabase saugumo patikra paleidžia 46 OWASP Top 10:2025 taisykles prieš projekto roles, teises, politikas ir autentifikacijos nustatymus, todėl naudokite ją pirmam apėjimui; dviejų įmonių testas ir viskas, kas susiję su jūsų sąsaja, lieka rankiniu darbu.

Ko šis sąrašas neapima: mokėjimų ir webhook’ų, paslapčių jūsų Git istorijoje, saugos antraščių talpinimo vietoje, atsarginių kopijų. Jie svarbūs, bet tai kitas sąrašas.

Jei paveldėjote Lovable ar Supabase programą ir nesate tikri, kurias iš šių patikrų ji praeina, nuo šio audito prasideda projekto gelbėjimas. Audito įmonės laiko apskaitos atvejis rodo, kaip rolių patikros atrodo produkcinėje programoje.