Lovable-sovelluksen tietoturva: 12 tarkistusta ja 8 lisää

Olen Denys, full-stack- ja tekoäly-insinööri. Tässä kuussa korjasin asiakkaan Lovablella tehtyä sovellusta. Kaikki pyöri tavalliseen tapaan Supabasen päällä, ja tietoturvakorjauksia oli niin paljon, että sovellus tuntui koostuvan niistä. Tämä on lista, jonka käyn nyt läpi jokaisessa Lovable- tai Supabase-projektissa, ennen kuin sanon asiakastietojen olevan suojattuja.

Onko Lovable turvallinen? Tähänastiset tietoturvaongelmat

Alusta rakentaa ja isännöi sovelluksesi, mutta sovelluksen turvallisuus riippuu enimmäkseen sen takana olevasta Supabase-tietokannasta, koska sovellus lukee ja kirjoittaa sitä suoraan selaimesta. Julkinen kirjanpito näyttää molemmat ongelmatyypit:

Milloin	Mitä tapahtui	Lähde
Maaliskuu 2025	CVE-2025-48757: 1 645 Lovablen esittelysovelluksen skannaus löysi 170 sovelluksesta 303 päätepistettä, jotka palauttivat dataa kenelle tahansa julkisen avaimen haltijalle, koska RLS puuttui tai oli liian löyhä	Matt Palmerin julkistus, toukokuu 2025
Helmikuu 2026	Yksi Lovablen isännöimä sovellus paljasti 18 697 käyttäjätietuetta; sen funktioiden pääsytarkistus päästi sisään anonyymit kävijät ja sulki ulos kirjautuneet käyttäjät. Lovable kertoi, ettei osa koodista ollut Lovablen generoimaa	The Register, 27. helmikuuta 2026
3. helmikuuta – 20. huhtikuuta 2026	Alustan regressio antoi muiden Lovable-käyttäjien lukea julkisten projektien chat-historiaa ja lähdekoodia	Lovablen tapahtumakirjoitus, 22. huhtikuuta 2026

Kaksi ensimmäistä ovat sovellustason aukkoja, juuri sellaisia, jotka alla olevat tarkistukset löytävät. Kolmas oli Lovablen oma, ja Lovable korjasi sen; sinun osasi on pitää avaimet poissa chateista ja koodista (tarkistus 3) ja vaihtaa kaikki avaimet, jotka siellä olivat. Lovable ajaa tietoturvaskannauksen ennen julkaisua, mutta sen perusteella toimiminen on sinun vastuullasi, ja CVE:n julkaisuhetkellä skannaus tarkisti, että politiikka on olemassa, ei että se on oikein. Joten kysymys “onko Lovable turvallinen” supistuu siihen, läpäiseekö tietokantasi alla olevat tarkistukset.

Miksi “RLS on päällä” ei riitä Lovable-sovelluksessa?

Lovable-sovellus puhuu tietokannalle suoraan selaimesta. Välissä ei ole omaa backendiä: sivu kutsuu Supabasen Data API:a julkisella avaimella, ja Postgres päättää, mitä palautuu (mitkä skeemat tuo API tarjoaa, on oma asetuksensa, jota käsittelee muistiinpano Supabase exposed schemas). Siksi jokaisen asiakastietoja suojaavan säännön on asuttava tietokannassa, ja tietokannassa on useita ovia.

Row level security on yksi niistä. Oikeudet (grants) ratkaisevat, saako rooli koskea tauluun lainkaan, politiikat ratkaisevat, mihin riveihin, ja kolme asiaa ohittaa politiikat kokonaan: secret key, ilman security_invoker-asetusta luodut viewt ja SECURITY DEFINER -funktiot. Tämä ei ole teoreettista. Lovablen oma tietoturvaopas pyytää tarkistamaan RLS-politiikat, jotka se luo, ja CVE-2025-48757 edellä on se, mitä tapahtuu, kun kukaan ei tee niin.

Prompti: liitä se Lovableen tai Claudeen

Voit liittää sen sellaisenaan. Tarkista sitten tulos itse: tekoäly sanoo mielellään “valmis”, vaikka ei ole, ja prompti, joka saa virheen katoamaan, voi tehdä sen laajentamalla pääsyä.

Auditoi tämä projekti tietoturvan osalta, korjaa löydökset ja kerro, mitä muutit:

1. Testaa kahdella käyttäjällä kahdessa yrityksessä. Käyttäjä A yrittää lukea, muokata ja poistaa B:n tietueita id:llä, API:n, haun ja vientien kautta. Kaikkien kokeilujen on epäonnistuttava.
2. RLS jokaisessa taulussa, politiikat tarkistavat rivin omistajan tai yrityksen. "Kirjautunut" ei riitä.
3. Service role key ei koskaan frontendissä. Sitä käyttävät edge functionit tarkistavat käyttäjän ja suodattavat yrityksen mukaan itse, koska avain ohittaa RLS:n.
4. Rooleja, pakettia ja yrityksen id:tä ei koskaan oteta user metadatasta, käyttäjät voivat muokata sitä. Pidä ne taulussa, johon vain palvelin kirjoittaa.
5. Kun pyyntö lähettää kaksi id:tä (projekti + tehtävä), tarkista, että tehtävä kuuluu tähän projektiin.
6. Poista kaikki taulujen oikeudet rooleilta anon ja authenticated ja anna takaisin vain se, mitä politiikat tarvitsevat. RLS ei pysäytä TRUNCATEa. Jokainen taulun luova migraatio sisältää sen GRANTin: 30. lokakuuta 2026 alkaen Supabase ei enää anna uusille tauluille oikeuksia automaattisesti, ja sovellus saa virheen 42501.
7. Kaikki viewt security_invoker = true, muuten ne ohittavat RLS:n.
8. Storage-bucketit: käyttäjät lukevat ja kirjoittavat vain omia tiedostojaan, ei julkisia bucketeja yksityiselle datalle.
9. SECURITY DEFINER -funktiot: NULL tarkoittaa kieltoa, ei sallimista.
10. Nopeusrajoitukset kirjautumiseen, rekisteröitymiseen, palautukseen ja OTP:hen, tallennettuna tietokantaan, ei muistiin.
11. Validoi kaikki syöte palvelimella.
12. Aja Supabasen security advisor, korjaa jokainen varoitus.

12 tarkistusta ja miten kunkin todistaa

1. Kaksi käyttäjää kahdessa yrityksessä

Luo käyttäjä A yritykseen 1 ja käyttäjä B yritykseen 2, kummallekin muutama tietue. Kirjaudu sisään A:na ja yritä lukea, muokata ja poistaa B:n tietueita id:llä, API:n kautta, haun kautta ja jokaisen viennin kautta. Jokaisen kokeilun on palautettava ei mitään tai virhe. Tämä on se yksi testi, joka pyydystää suurimman osan alla olevasta, koska se testaa, mitä hyökkääjä tekee, ei sitä, mitä itse kirjoitit.

Lisää kolmas käyttäjä, joka kuuluu molempiin yrityksiin. Politiikka muotoa “kutsuja on rivin yrityksen jäsen” päästää tämän käyttäjän lukemaan yrityksen 2 rivejä, kun hän työskentelee yrityksessä 1. Toisessa Supabase-sovelluksessa koettimeni palautti tällaisella käyttäjällä toisen yrityksen dokumentin, kunnes kysely alkoi suodattaa myös pyynnön yrityksen mukaan. Kirjoitin sen ylös nimellä käyttäjä kahdessa organisaatiossa, jota RLS ei eristänyt.

2. RLS jokaisessa taulussa, rajattu omistajaan tai yritykseen

auth.uid() is not null tarkoittaa “mitä tahansa sisäänkirjautunutta käyttäjää”, mikä julkisella rekisteröitymissivulla tarkoittaa kenet tahansa. Jokainen politiikka vertaa rivin omistajaa tai yritystä kutsujaan. Listaa taulut, joissa RLS on vielä pois päältä:

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. Secret key ei koskaan frontendissä

Service role key ja uudempi sb_secret_-avain ohittavat kaikki politiikat. Etsi molempia rakennetusta JavaScriptistä ja vaihda jokainen avain, joka on koskaan julkaistu. Niitä käyttävien edge functionien on itse tarkistettava, kuka käyttäjä on, ja suodatettava yrityksen mukaan, koska tällä avaimella mikään muu ei sitä tee.

4. Roolit, paketti ja yrityksen id eivät koskaan käyttäjän metadatasta

raw_user_meta_data on kaikki, mitä asiakas lähetti signUp-kutsulle, ja käyttäjät voivat muuttaa sitä myöhemmin. Toisessa sovelluksessa uuden käyttäjän triggeri luki kutsutun roolin sieltä, joten kuka tahansa rekisteröityvä pystyi välittämään omistajan roolin ja tulemaan Owneriksi. Pidä roolit, paketit ja yrityksen id:t taulussa, johon vain palvelin kirjoittaa, tai kentässä app_metadata. Koko tarina: rekisteröitymismetadatasta otettu rooli.

5. Kaksi id:tä yhdessä pyynnössä: tarkista, että ne kuuluvat yhteen

Kun pyyntö kantaa projektin id:tä ja tehtävän id:tä, projektin valtuutus ei riitä. Käyttäjä, jolla on oikeudet projektiin A, lähettää A:n sekä projektin B osion id:n, ja rivi päätyy B:hen. RLS ei sitä huomaa, koska insert leimaa hyökkääjän oman projektin id:n, jota politiikka juuri tarkistaa. Tarkista ennen kirjoitusta, että lapsi kuuluu vanhemmalle.

6. Oikeudet: poista, anna sitten takaisin vain tarvittava

Oikeudet ja politiikat ovat kaksi erillistä kerrosta. Politiikkojen lisääminen ei ota oikeutta pois, minkä vuoksi Supabasen RLS-opas käskee poistaa ja antaa takaisin erikseen. Toisessa projektissa supabase/postgres 17.6.1 -image oli antanut rooleille anon ja authenticated oikeudet TRUNCATE, REFERENCES, TRIGGER ja MAINTAIN jokaiseen public-skeeman tauluun, eikä mikään politiikka koske TRUNCATEa. Data API:ssa ei ole TRUNCATE-päätepistettä, joten tämä ei ole yhden pyynnön tyhjennys, mutta mikään asiakasrooli ei sitä tarvitse, ja jokainen funktio, joka ajaa SQL:ää sillä roolilla, perii sen.

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;

Yksi päivämäärä muuttaa tätä tarkistusta. Supabase lopettaa oikeuksien antamisen uusille tauluille automaattisesti: uusille projekteille 30. toukokuuta 2026 alkaen ja kaikille olemassa oleville projekteille 30. lokakuuta 2026 alkaen, myös niille, jotka Lovable loi. Sen jälkeen taulu, jonka Lovable tai migraatio luo ilman erillistä GRANT-lausetta, on sovellukselle näkymätön: pyyntö epäonnistuu virheeseen 42501 ja taulua käyttävä ominaisuus hajoaa. Siksi jokainen taulun luova migraatio sisältää nyt oikeutensa, enable row level security -lauseen ja politiikkojen vieressä.

Kaksi asiaa pysyy samana. Olemassa olevat taulut säilyttävät oikeudet, jotka niillä on, joten tarpeettomien poistaminen on edelleen sinun työtäsi. Ja muutos ottaa pois vain select-, insert-, update- ja delete-oikeudet: Lovable-projektissa uusilla oletuksilla uudet taulut tulivat edelleen oikeuksilla TRUNCATE, REFERENCES, TRIGGER ja MAINTAIN rooleille anon ja authenticated. Ensin kaikki pois, sitten anto, on edelleen turvallinen järjestys.

7. Jokainen view asetuksella security_invoker = true

View ajetaan omistajansa oikeuksilla, ja Supabasessa omistaja on yleensä postgres, joten suojatun taulun päälle tehty view antaa ulos jokaisen rivin, jonka politiikat pidättävät. Postgres 15:ssä ja uudemmissa:

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

8. Storage: vain omat tiedostot, ei julkista bucketia yksityiselle datalle

Julkinen bucket tarjoaa minkä tahansa tiedoston kenelle tahansa, jolla on URL. Yksityiset tiedostot kuuluvat yksityiseen bucketiin, jossa storage.objects-politiikat tarkistavat omistajan tai yrityksen, yleensä polun ensimmäisestä kansiosta. Projektin siirron jälkeen laske voimassa olevat storage-politiikat: yhdessä sovelluksessa jokainen tiedoston lataus epäonnistui siirron jälkeen, koska politiikkamigraatio ei koskaan ajettu ja taulussa oli RLS päällä nollalla politiikalla.

9. SECURITY DEFINER -funktiot: NULL tarkoittaa kieltoa

PL/pgSQL:ssä if not (has_permission or assignee_id = auth.uid()) ei nosta virhettä, kun assignee_id on null: koko ehto on null, ja if ohittaa sen. Sama lauseke on turvallinen politiikan sisällä, koska politiikka käsittelee nullin kieltona. Yhdessä sovelluksessa se antoi roolille, jolla kaikki oikeudet olivat pois, mahdollisuuden toimia kaikilla 3683 tehtävällä, koska yhdelläkään ei ollut vastuuhenkilöä. Kääri ehto coalesce(…, false)-kutsuun. Lisätietoa: PL/pgSQL IF NOT ja NULL ohitti tarkistuksen 3683 tehtävällä.

10. Tietokantaan tallennetut nopeusrajoitukset

Rajoita kirjautuminen, rekisteröityminen, salasanan palautus ja OTP, ja pidä laskuri Postgresissa. Lovable-sovelluksessa rajoitukset asuivat edge functionin sisäisessä muuttujassa. Koetin hostattua projektia 17. lokakuuta 2026: jokainen pyyntö ajettiin uudessa isolate-ympäristössä, joten muistin sisäinen laskuri oli aina 1 eikä rajoitus voinut koskaan laueta. Paikallinen supabase functions serve käyttää isolatea uudelleen, joten sama koodi läpäisi kaikki paikalliset testit.

Avain on yhtä tärkeä kuin säilö. Hostatulla alustalla viimeinen X-Forwarded-For-hyppy on Supabasen oma proxy, joten sen mukaan avaimen muodostaminen laittaa kaikki kutsujat samaan koriin, ja x-client-ip:n asettaa asiakas. Koettimessani cf-connecting-ip kantoi oikean asiakkaan. Korjaus oli SECURITY DEFINER -funktio claim_rate_limit(bucket, key, max, window), jonka vain service role voi suorittaa, sarjallistettuna advisory lockilla, ja joka tallentaa IP:n tai käyttäjän id:n tiivisteen raa’an arvon sijaan.

11. Validoi kaikki syöte palvelimella

Mitä lomake ikinä tarkistaakin, API hyväksyy kaiken, minkä asiakas lähettää. Pituudet, muodot, enumit ja omistajuus tarkistetaan tietokannassa (rajoitteet, triggerit) tai edge functionissa, ei koskaan vain Reactissa.

12. Supabasen Security Advisor, jokainen varoitus

Avaa Advisors, sitten Security Advisor, ja korjaa jokainen löydös. Se liputtaa taulut, joissa RLS on pois päältä, RLS:n ohittavat viewt, käyttäjän metadataa lukevat politiikat, sallivat using (true) -politiikat ja funktiot, joiden search_path on muuttuva. Se ei näe tarkistuksia 1, 5, 9 tai 10, koska ne koskevat logiikkaa, eivät konfiguraatiota.

Mitä Lovable-sovellus opetti, mitä nämä 12 eivät huomaa?

Nämä tulivat asiakkaan sovelluksesta ja sen katselmoinneista. Mikään niistä ei näy skannerissa.

1. Kentät, joita asiakas ei saa asettaa. Asiakas lähetti itse status: 'approved', mikä ohitti moderoinnin. UPDATE-politiikka, jonka with check on väljempi kuin sen using, antaa myös siirtää rivin toiselle omistajalle. Politiikka ei voi laskea arvoa, joten BEFORE INSERT OR UPDATE -triggeri johtaa status-, rooli-, hinta- ja yritysarvot uudelleen palvelimen omasta datasta ja ohittaa sen, minkä asiakas lähetti.
2. Jokainen kirjoitusreitti, ei vain pääinsert. Kun pääinsert oli korjattu, sama ohitus oli liitteissä, kommenteissa, poistetun kohteen palautuksessa ja laskureissa. Listaa suojatun sarakkeen jokainen kirjoittaja ennen kuin korjaat ensimmäisen.
3. Sallittujen listat, ei kiellettyjen listat. Väärennetyt tietueet vaativat viisi katselmointikierrosta, koska jokainen korjaus esti yhden yhdistelmän ja jätti naapurin auki. Triggeri, joka sallii vain luetellut tyypin ja tilan yhdistelmät, sulki koko luokan kerralla.
4. Funktiot ovat myös API. Jokaisen public-skeeman funktion voi kutsua /rpc-reitin kautta mikä tahansa rooli, jolla on EXECUTE, eikä RLS koske funktioita. Anna jokaiselle SECURITY DEFINER -funktiolle set search_path = '', poista EXECUTE rooleilta public, anon ja authenticated ja anna se vain roolille, joka sitä tarvitsee.
5. EXECUTE:n poistaminen voi rikkoa julkiset sivut. Postgres tarkistaa EXECUTE:n jokaiselta funktiolta, jota käyttää jokainen roolia koskeva politiikka, vaikka haarassa, joka ei koskaan ajettaisi. Kun anon menetti EXECUTE:n funktiosta is_admin(), jokainen anonyymi luku epäonnistui virheeseen 42501. Vain ylläpitäjille tarkoitetut politiikat menevät to authenticated, ja julkiset luvut saavat oman politiikkansa ilman ylläpitäjähaaraa.
6. Rekisteröityminen, kun sähköpostivahvistus on päällä. Vahvistuksen ollessa päällä signUp ei palauta sessiota, joten jokainen profiilin kirjoitus heti sen jälkeen ajetaan roolilla anon eikä kirjoita hiljaa mitään. Lovable-projekteissa automaattinen vahvistus on usein päällä, mikä piilottaa bugin. Välitä kentät kutsulla signUp({ options: { data } }), anna uuden käyttäjän triggerin validoida ja kirjoittaa ne, ja kohtele tuota metadataa epäluotettavana (tarkistus 4).
7. Testit, jotka menevät läpi väärästä syystä. Paikallisella pinolla ja hostatulla projektilla oli eri oletusoikeudet, joten “anon ei voi lisätä” meni paikallisesti läpi, koska oikeus puuttui, ei siksi että RLS toimi. Negatiivisella testillä on merkitystä vain, kun positiivinen oikeus on olemassa. Vertaa pg_default_acl-taulua paikallisesti ja tuotannossa.
8. Elävä tietokanta, ei migraatiotiedostot. Migraation tai projektin siirron jälkeen vertaa sitä, mikä on oikeasti käytössä: pg_policies, pg_get_functiondef jokaiselle vartijalle ja yllä olevat oikeudet. Toisessa sovelluksessa uusi migraatio kopioi vanhan funktion rungon ja kumosi hiljaa myöhemmän korjauksen.

Onko Lovable-sovellus GDPR:n mukainen?

Lovable ei tee sovelluksesta GDPR:n mukaista tai vastaista; sen ratkaisee, mitä sovellus tekee henkilötiedoilla, eikä tietoturvakatselmointi vastaa siihen. Nämä ovat kuusi aukkoa, jotka tarkistan Lovable Cloud -sovelluksesta, kukin korjauksineen:

1. Listaa jokainen käsittelijä. Lovable Cloud ajaa tietokannan, autentikoinnin, tallennuksen ja funktiot Supabasessa, Lovable hostaa sivuston ja voi lähettää kirjautumissähköpostit, ja Lovable AI Gateway välittää tekstiä mallintarjoajalle. Lisää jokainen sähköposti-, tekoäly- tai scraping-palvelu, jota funktiosi kutsuvat. Jokainen henkilötietoja saava palvelu tarvitsee tietojenkäsittelysopimuksen (DPA), ja EU:n ulkopuolinen lisäksi siirtoperusteen. Hosting-alue ei näy koodissa, joten kysy sitä.
2. Poista käyttäjä, jolla on sisältöä. Käyttäjän kirjoittaman sisällön viiteavaimet voivat estää poiston, jolloin poistopyyntöä ei voi toteuttaa. Aseta avaimet cascade- tai set null -tilaan, lisää poistotriggeri, joka poistaa myös käyttäjän sähköpostilokit ja kirjautumistunnisteet, ja pidä tietokantatesti, joka poistaa tällaisen käyttäjän.
3. Aseta säilytysaika. Sähköpostilokit, katseluseuranta, epäonnistuneiden sähköpostien jonot ja pehmeästi poistetut rivit säilyttävät henkilötietoja usein ilman päättymispäivää. Ajastettu työ, joka poistaa pehmeästi poistetut rivit lopullisesti kiinteän ajan jälkeen ja poistaa niiden tiedostot, korjaa suurimman osan.
4. Sähköpostiseuranta vain suostumuksella. Avausten ja klikkausten kirjaaminen vastaanottajakohtaisesti vaatii ePrivacy-sääntöjen mukaan suostumuksen: suostumuslippu, oletuksena pois päältä, ja aikaleima palvelimen eikä asiakkaan asettamana.
5. Pidä osoitteet poissa funktioiden lokeista. Edge functionien lokeja ei siivota, joten console.log, jossa on vastaanottajan osoite, jättää osoitteen sinne. Kirjaa tunnisteet ja määrät.
6. Ota sähköpostivahvistus käyttöön. Automaattisella vahvistuksella kuka tahansa voi rekisteröityä osoitteella, joka ei ole hänen, ja tuoda oikean ihmisen osoitteen sovellukseen. Yllä olevan listan kohta 6 kattaa rekisteröitymisen puolen.

Näin tarkistat oman sovelluksesi: etsi funktioista API-avaimet listataksesi palvelut, poista testikäyttäjä, jolla on sisältöä, etsi funktioiden lokeista @ ja pyydä jokaiselta palveluntarjoajalta tietojenkäsittelysopimus. Tämä ei ole oikeudellista neuvontaa.

Miten estät sen palaamisen?

Jokainen yllä oleva tarkistus on kysely tai testi, joten pidä ne repossa ja aja ennen jokaista julkaisua. Supabasen pgTAP-testit kattavat oikeudet, politiikat ja funktiot; kahden yrityksen testi kuuluu niiden viereen. Jos sovelluksessasi on rooleja ja oikeusnäkymä, ei myöskään politiikkakohtainen testi riitä: todistan jokaisen oikeusruudun tuotannon kopiota vasten, kuten kuvataan tekstissä miten testata Supabase RLS, jossa 30 ruutua 87:stä ei tehnyt mitään. Ilmainen Supabase tietoturvatarkistus ajaa 46 OWASP Top 10:2025 -sääntöä projektin rooleja, oikeuksia, politiikkoja ja autentikointiasetuksia vasten, joten käytä sitä ensimmäiseen läpikäyntiin; kahden yrityksen testi ja kaikki käyttöliittymääsi koskeva pysyvät käsityönä.

Mitä tämä lista ei kata: maksut ja webhookit, salaisuudet Git-historiassasi, tietoturvaotsakkeet hostilla, varmuuskopiot. Ne ovat tärkeitä, mutta ne ovat eri tarkistuslista.

Jos perit Lovable- tai Supabase-sovelluksen etkä ole varma, mitkä näistä se läpäisee, projektin pelastus alkaa tästä auditoinnista. Tilintarkastusyhtiön ajanseurannan tapaus näyttää, miltä roolitarkistukset näyttävät tuotantosovelluksessa.