---
title: "Lovable'i rakenduse turvalisus: 12 kontrolli + 8 lisa"
description: "Lovable'i rakenduse turvanimekiri Supabase'ile. Iga kontrolli juures päring või test, pluss 8 auku, mida enamik nimekirju ei märka."
url: "https://madsalt.tech/et/blog/lovable-app-security-checklist/"
author: "Denys Zaichenko"
language: "et"
published: 2026-10-18
updated: 2026-10-25
---

# Lovable'i rakenduse turvalisus: 12 kontrolli + 8 lisa

Lühidalt

Lovable'i rakendus on sama turvaline kui selle Supabase'i andmebaas ja "RLS on sees" tõestab väga vähe. Testige kahe kasutajaga kahes ettevõttes, hoidke rollid kasutaja metaandmetest eemal, hoidke secret key brauserist eemal ning kontrollige õigusi, view'sid, storage'it, funktsioone ja päringupiiranguid eraldi, sest igaüks neist läheb teie poliitikatest mööda omal moel. Allpool on nimekiri, mida ma käivitan, prompt, mille saate Lovable'isse või Claude'i kleepida, ja kaheksa kontrolli, mille lisasin pärast seda, kui kliendi Lovable'i rakendus näitas, mida esimesed kaksteist ei märka.

Olen Denys, full-stack- ja AI-insener. Sel kuul parandasin kliendi rakendust, mis oli ehitatud Lovable'iga. Kõik jooksis nagu tavaliselt Supabase'i peal ja turvaparandusi oli nii palju, et tundus, nagu rakendus koosneks neist. See on nimekiri, mille ma nüüd läbin igas Lovable'i või Supabase'i projektis, enne kui nimetan kliendiandmeid kaitstuks.

## Kas Lovable on turvaline? Siiani teada turvaprobleemid

Platvorm ehitab ja majutab teie rakendust, kuid rakenduse turvalisus sõltub enamasti selle taga olevast Supabase'i andmebaasist, sest rakendus loeb ja kirjutab seda andmebaasi otse brauserist. Avalikult teada juhtumid näitavad mõlemat liiki probleeme:

| Millal                        | Mis juhtus                                                                                                                                                                                                                                     | Allikas                                                                                                                                                |
| ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ |
| märts 2025                    | CVE-2025-48757: 1645 Lovable'i näiterakenduse skannimine leidis 170 neist 303 lõpp-punkti, mis andsid andmeid igaühele, kellel oli avalik võti, sest RLS puudus või oli liiga lõdv                                                             | [Matt Palmeri avalikustus](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/), mai 2025                                                 |
| veebruar 2026                 | Üks Lovable'is majutatud rakendus paljastas 18 697 kasutajakirjet; selle funktsioonide juurdepääsukontroll lasi anonüümsed külastajad sisse ja blokeeris sisseloginud kasutajad. Lovable ütles, et osa koodist ei olnud Lovable'i genereeritud | [The Register](https://www.theregister.com/software/2026/02/27/ai-built-app-on-lovable-exposed-18k-users-researcher-claims/5038511), 27. veebruar 2026 |
| 3. veebruar – 20. aprill 2026 | Platvormi regressioon lubas teistel Lovable'i kasutajatel lugeda avalike projektide vestlusajalugu ja lähtekoodi                                                                                                                               | [Lovable'i intsidendipostitus](https://lovable.dev/blog/our-response-to-the-april-2026-incident), 22. aprill 2026                                      |

Kaks esimest on rakenduse tasandi augud, sellised, mida allolevad kontrollid püüavad. Kolmas oli Lovable'i enda viga ja Lovable parandas selle; teie osa on hoida võtmed vestlustest ja koodist eemal (kontroll 3) ning vahetada välja kõik, mis seal olid. Lovable käivitab enne avaldamist turvaskanni, kuid selle põhjal tegutsemine on teie asi, ja CVE avaldamise ajal kontrollis see skanni vaid seda, et poliitika on olemas, mitte et see on õige. Seega taandub "kas Lovable on turvaline" sellele, kas teie andmebaas läbib allolevad kontrollid.

## Miks "RLS on sees" Lovable'i rakenduses ei piisa?

Lovable'i rakendus suhtleb andmebaasiga otse brauserist. Vahel pole teie enda backend'i: leht kutsub Supabase'i Data API-t avaliku võtmega ja Postgres otsustab, mida tagastada (milliseid skeeme see API serveerib, on eraldi seadistus, mida käsitleb märkus [Supabase exposed schemas](https://madsalt.tech/et/notes/supabase-exposed-schemas/)). Seega peab iga reegel, mis kliendiandmeid kaitseb, elama andmebaasis, ning andmebaasil on mitu ust.

Row level security on üks neist. Õigused (grants) otsustavad, kas roll saab tabelit üldse puudutada, poliitikad otsustavad, milliseid ridu, ja kolm asja jätavad poliitikad täielikult vahele: secret key, view'd, mis on loodud ilma `security_invoker`'ita, ning `SECURITY DEFINER` funktsioonid. See pole hüpoteetiline. Lovable'i enda [turvajuhend](https://docs.lovable.dev/tips-tricks/security-best-practices) palub üle vaadata RLS-poliitikad, mille see seadistab, ja ülalpool mainitud [CVE-2025-48757](https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps) on see, mis juhtub, kui keegi seda ei tee.

![Neli teed, kuidas päring andmeteni jõuab. Ainult esimest kontrollivad teie RLS-poliitikad. Tavaline päring: Brauser → Õigus → RLS-poliitika → Oma read; Secret key edge function'is: Brauser → Edge function → Secret key → Kõik read; View ilma security_invoker'ita: Brauser → View → Omaniku õigused → Kõik read; SECURITY DEFINER funktsioon: Brauser → RPC → Omaniku õigused → Kõik read.](https://madsalt.tech/charts/et/lovable-app-security-checklist-paths.svg)

*Joonis 1. Teie poliitikad kontrollivad ainult esimest teed. Ülejäänud kolm töötavad õigustega, mis RLS-ist mööda lähevad. Allikas: Supabase'i dokumentatsioon RLS-i ja API turvamise kohta, oktoober 2026.*

## Prompt: kleepige see Lovable'isse või Claude'i

Võite selle kleepida sellisena. Seejärel kontrollige tulemust ise: AI armastab öelda "valmis", kui see seda pole, ja prompt, mis paneb vea kaduma, võib seda teha juurdepääsu laiendades.

```text
Auditeeri seda projekti turvalisuse osas, paranda leitu ja ütle, mida muutsid:

1. Testi kahe kasutajaga kahes ettevõttes. Kasutaja A proovib B kirjeid lugeda, muuta ja kustutada id järgi, API, otsingu ja ekspordi kaudu. Kõik katsed peavad ebaõnnestuma.
2. RLS igal tabelil, poliitikad kontrollivad rea omanikku või ettevõtet. "Sisse logitud" ei piisa.
3. Service role key ei ole kunagi frontendis. Edge function'id, mis seda kasutavad, kontrollivad ise kasutajat ja filtreerivad ettevõtte järgi, sest võti jätab RLS-i vahele.
4. Rolle, paketti ja ettevõtte id-d ei võeta kunagi user metadata'st, kasutajad saavad seda muuta. Hoia neid tabelis, kuhu kirjutab ainult server.
5. Kui päring saadab kaks id-d (projekt + ülesanne), kontrolli, et ülesanne kuulub sellele projektile.
6. Võta anon'ilt ja authenticated'ilt ära kõik tabeliõigused, anna tagasi ainult need, mida poliitikad vajavad. RLS ei peata TRUNCATE'i. Iga tabelit loov migratsioon sisaldab selle GRANT-i: alates 30. oktoobrist 2026 Supabase uutele tabelitele õigusi enam automaatselt ei anna ja rakendus saab vea 42501.
7. Kõik view'd security_invoker = true, muidu jätavad need RLS-i vahele.
8. Storage bucket'id: kasutajad loevad ja kirjutavad ainult oma faile, privaatsete andmete jaoks pole avalikke bucket'eid.
9. SECURITY DEFINER funktsioonid: NULL tähendab keeldumist, mitte lubamist.
10. Päringupiirangud sisselogimisele, registreerimisele, lähtestamisele ja OTP-le, hoitud andmebaasis, mitte mälus.
11. Valideeri kogu sisend serveris.
12. Käivita Supabase'i security advisor, paranda iga hoiatus.
```

## 12 kontrolli ja kuidas igaüht tõestada

### 1. Kaks kasutajat kahes ettevõttes

Looge kasutaja A ettevõttes 1 ja kasutaja B ettevõttes 2, kummalgi mõned kirjed. Logige sisse A-na ja proovige B kirjeid lugeda, muuta ja kustutada id järgi, API kaudu, otsingu kaudu ja iga ekspordi kaudu. Iga katse peab tagastama mitte midagi või vea. See on üks test, mis püüab kinni suurema osa allpool olevast, sest see kontrollib, mida ründaja teeb, mitte seda, mida teie kirjutasite.

![Kaks kasutajat, kaks ettevõtet. Ettevõtte 1 kasutaja A läheb ettevõtte 2 kirjete kallale. Iga tee peab tagastama mitte midagi. Id järgi API kaudu: Kasutaja A → B kirje id → Loe, muuda, kustuta → 0 rida või viga; Otsingu kaudu: Kasutaja A → Otsi B teksti → Tulemused → B ridu pole; Ekspordi kaudu: Kasutaja A → Eksport → Fail → B ridu pole.](https://madsalt.tech/charts/et/lovable-app-security-checklist-test.svg)

*Joonis 2. Kahe ettevõtte test. Läbimine tähendab, et ükski tee ei tagasta midagi ettevõttest 2.*

Lisage kolmas kasutaja, kes kuulub mõlemasse ettevõttesse. Poliitika kujul "helistaja on rea ettevõtte liige" laseb sellel kasutajal lugeda ettevõtte 2 ridu, kui ta töötab ettevõttes 1. Ühes teises Supabase'i rakenduses tagastas mu sond sellise kasutaja peal teise ettevõtte dokumendi, kuni päring hakkas filtreerima ka päringu ettevõtte järgi. Kirjutasin selle lahti kui [kasutaja kahes org-is, keda RLS ei isoleerinud](https://madsalt.tech/et/notes/supabase-rls-user-in-two-organizations/).

### 2. RLS igal tabelil, seotud omaniku või ettevõttega

`auth.uid() is not null` tähendab "mis tahes sisseloginud kasutaja", mis avalikul registreerimislehel tähendab kedagi tahes. Iga poliitika võrdleb rea omanikku või ettevõtet helistajaga. Loetlege tabelid, kus RLS on veel väljas:

```sql
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 ole kunagi frontendis

Service role key ja uuem `sb_secret_` võti jätavad mööda kõik poliitikad. Otsige ehitatud JavaScriptist mõlemat ja vahetage välja iga võti, mis kunagi välja saadeti. Edge function'id, mis seda kasutavad, peavad ise kontrollima, kes kasutaja on, ja ise filtreerima ettevõtte järgi, sest selle võtmega ei tee seda miski muu.

### 4. Rollid, pakett ja ettevõtte id ei tule kunagi kasutaja metaandmetest

`raw_user_meta_data` on kõik, mille klient `signUp`-ile saatis, ja kasutajad saavad seda hiljem muuta. Ühes teises rakenduses luges uue kasutaja trigger sealt kutsutud rolli, nii et igaüks, kes registreerus, sai edasi anda omaniku rolli ja saada Owneriks. Hoidke rolle, pakette ja ettevõtte id-sid tabelis, kuhu kirjutab ainult server, või `app_metadata`'s. Täielik lugu: [registreerimise metaandmetest võetud roll](https://madsalt.tech/et/notes/supabase-raw-user-meta-data-role/).

### 5. Kaks id-d ühes päringus: kontrollige, et need kuuluvad kokku

Kui päring kannab projekti id-d ja ülesande id-d, ei piisa projekti autoriseerimisest. Kasutaja, kellel on õigused projektis A, saadab A ja projekti B jaotise id, ning rida satub B-sse. RLS ei püüa seda kinni, sest insert tembeldab ründaja enda projekti id, mida poliitika just kontrollib. Kontrollige enne kirjutamist, et alam kuulub vanema alla.

### 6. Õigused: võtke ära, andke tagasi ainult vajalik

Õigused ja poliitikad on kaks eraldi kihti. Poliitikate lisamine ei võta õigust tagasi, mistõttu Supabase'i [RLS-i juhend](https://supabase.com/docs/guides/database/postgres/row-level-security) käsib need selgelt ära võtta ja tagasi anda. Ühes teises projektis oli `supabase/postgres` 17.6.1 kujutis andnud rollidele `anon` ja `authenticated` õigused TRUNCATE, REFERENCES, TRIGGER ja MAINTAIN igal `public` tabelil ja ükski poliitika TRUNCATE'i ei puuduta. Data API-l pole TRUNCATE lõpp-punkti, seega pole see ühe päringuga kustutamine, kuid ükski kliendi roll seda ei vaja ja iga funktsioon, mis käivitab SQL-i selle rolli all, pärib selle.

```sql
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;
```

Üks kuupäev muudab seda kontrolli. Supabase [lõpetab uutele tabelitele õiguste automaatse andmise](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically): uutel projektidel alates 30. maist 2026 ja kõigil olemasolevatel projektidel alates 30. oktoobrist 2026, sealhulgas neil, mille Lovable lõi. Pärast seda on tabel, mille Lovable või migratsioon loob ilma selge `GRANT`-ita, rakendusele nähtamatu: päring ebaõnnestub veaga 42501 ja tabelit kasutav funktsioon läheb katki. Seega kannab iga tabelit loov migratsioon nüüd oma õigusi, `enable row level security` ja poliitikate kõrval.

Kaks asja jäävad samaks. Olemasolevad tabelid säilitavad õigused, mis neil on, seega on mittevajalike äravõtmine endiselt teie töö. Ja muudatus võtab tagasi ainult select, insert, update ja delete: Lovable'i projektis tulid uute vaikeseadetega uued tabelid endiselt koos õigustega TRUNCATE, REFERENCES, TRIGGER ja MAINTAIN rollidele `anon` ja `authenticated`. Kõigepealt kõik ära võtta, siis anda, on endiselt ohutu järjekord.

### 7. Iga view koos `security_invoker = true`

View töötab omaniku õigustega ja Supabase'is on omanik tavaliselt `postgres`, mistõttu kaitstud tabeli peale ehitatud view annab välja kõik read, mida poliitikad kinni hoiavad. Postgres 15 ja uuemas:

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

### 8. Storage: ainult oma failid, privaatsete andmete jaoks pole avalikku bucket'it

Avalik bucket serveerib mis tahes faili igaühele, kellel on URL. Privaatsed failid kuuluvad privaatsesse bucket'isse, kus `storage.objects` poliitikad kontrollivad omanikku või ettevõtet, tavaliselt tee esimesest kaustast. Pärast projekti kolimist lugege kokku kehtivad storage'i poliitikad: ühes rakenduses ebaõnnestus pärast kolimist iga üleslaadimine, sest poliitikate migratsioon ei käivitunud kunagi ja tabelil oli RLS sees nulli poliitikaga.

### 9. SECURITY DEFINER funktsioonid: NULL tähendab keeldumist

PL/pgSQL-is `if not (has_permission or assignee_id = auth.uid())` ei tõsta viga, kui `assignee_id` on null: kogu tingimus on null ja `if` jätab selle vahele. Sama avaldis on poliitika sees ohutu, sest poliitika käsitleb nulli keeldumisena. Ühes rakenduses lasi see rollil, millel olid kõik õigused väljas, toimida kõigi 3683 ülesandega, sest ühelgi polnud vastutajat. Mähkige tingimus `coalesce(…, false)` sisse. Üksikasjad: [NULL PL/pgSQL-i IF NOT-is jättis 3683 ülesande kontrollita](https://madsalt.tech/et/notes/plpgsql-if-not-null-fails-open/).

### 10. Andmebaasis hoitavad päringupiirangud

Piirake sisselogimist, registreerimist, parooli lähtestamist ja OTP-d ning hoidke loendurit Postgresis. Lovable'i rakenduses elasid piirangud edge function'i sees olevas muutujas. Katsetasin hostitud projekti 17. oktoobril 2026: iga päring jooksis uues isolate'is, nii et mälusisene loendur oli alati 1 ja piirang ei saanud kunagi käivituda. Kohalik `supabase functions serve` kasutab isolate'i uuesti, mistõttu sama kood läbis kõik kohalikud testid.

![Kus loendur elab, otsustab, kas see töötab. Päringupiirang hostitud Supabase'i edge function'is. Loendur funktsiooni mälus: Päring → Uus isolate → Loendur = 1 → Pole kunagi piiratud; Loendur Postgresis: Päring → claim_rate_limit → Ühine rida → 429 piiril.](https://madsalt.tech/charts/et/lovable-app-security-checklist-ratelimit.svg)

*Joonis 3. Minu sond hostitud Supabase'i edge function'i vastu, 17. oktoober 2026: iga päring käivitas uue isolate'i.*

Võti loeb sama palju kui hoidla. Hostitud platvormil on viimane `X-Forwarded-For` samm Supabase'i enda proxy, nii et selle järgi võtmestamine paneb kõik helistajad ühte ämbrisse, ning `x-client-ip` seab klient. Minu sondis kandis tegelikku klienti `cf-connecting-ip`. Parandus oli `SECURITY DEFINER` funktsioon `claim_rate_limit(bucket, key, max, window)`, mida saab käivitada ainult service role, serialiseeritud advisory lockiga, mis hoiab IP või kasutaja id räsi, mitte toorväärtust.

### 11. Valideerige kogu sisend serveris

Ükskõik mida vorm kontrollib, API võtab vastu kõik, mida klient saadab. Pikkused, vormingud, enumid ja omand kontrollitakse andmebaasis (piirangud, triggerid) või edge function'is, mitte kunagi ainult Reactis.

### 12. Supabase'i Security Advisor, iga hoiatus

Avage Advisors, siis Security Advisor, ja parandage iga leid. See märgib tabelid, kus RLS on väljas, view'd, mis jätavad RLS-i vahele, poliitikad, mis loevad kasutaja metaandmeid, lubavad `using (true)` poliitikad ja funktsioonid muutuva `search_path`-iga. See ei näe kontrolle 1, 5, 9 ega 10, sest need puudutavad loogikat, mitte konfiguratsiooni.

## Mida Lovable'i rakendus mulle õpetas, mida need 12 ei märka?

Need tulid kliendi rakendusest ja selle ülevaatustest. Ükski neist ei ilmu skanneris.

1. **Väljad, mida klient ei tohi seada.** Klient saatis ise `status: 'approved'`, mis jättis modereerimise vahele. UPDATE-poliitika, mille `with check` on lõdvem kui `using`, lubab ka rea teisele omanikule liigutada. Poliitika ei saa väärtust arvutada, nii et `BEFORE INSERT OR UPDATE` trigger tuletab `status`'e, rolli, hinna ja ettevõtte uuesti serveri enda andmetest ning ignoreerib seda, mida klient saatis.
2. **Iga kirjutamistee, mitte ainult peamine insert.** Pärast peamise inserti parandamist istus sama möödapääs manustes, kommentaarides, kustutatud kirje taastamises ja loendurites. Loetlege kaitstud veeru iga kirjutaja enne esimese parandamist.
3. **Lubatud nimekirjad, mitte keelatud nimekirjad.** Võltsitud kirjed nõudsid viit ülevaatusringi, sest iga parandus blokeeris ühe kombinatsiooni ja jättis naabri lahti. Trigger, mis lubab ainult loetletud tüübi ja staatuse kombinatsioone, sulges kogu klassi korraga.
4. **Funktsioonid on samuti API.** Iga skeemi `public` funktsiooni saab `/rpc` kaudu kutsuda iga roll, kellel on EXECUTE, ja RLS funktsioonidele ei kehti. Andke igale `SECURITY DEFINER` funktsioonile `set search_path = ''`, võtke EXECUTE ära rollidelt `public`, `anon` ja `authenticated` ning andke see ainult rollile, kes seda vajab.
5. **EXECUTE äravõtmine võib avalikud lehed katki teha.** Postgres kontrollib EXECUTE'i igal funktsioonil, mida kasutab iga rollile kehtiv poliitika, isegi harus, mis kunagi ei käivituks. Kui `anon` kaotas EXECUTE'i funktsioonil `is_admin()`, ebaõnnestus iga anonüümne lugemine veaga 42501. Ainult administraatorile mõeldud poliitikad panna `to authenticated` ja avalikud lugemised saavad oma poliitika ilma administraatori haruta.
6. **Registreerimine sisselülitatud e-posti kinnitusega.** Kui kinnitus on sees, ei tagasta `signUp` sessiooni, nii et iga profiili kirjutamine kohe pärast seda jookseb kui `anon` ja ei kirjuta vaikselt midagi. Lovable'i projektides on sageli automaatne kinnitus sees, mis peidab vea. Andke väljad edasi `signUp({ options: { data } })` kaudu, laske uue kasutaja triggeril need valideerida ja kirjutada ning käsitlege neid metaandmeid kui ebausaldusväärseid (kontroll 4).
7. **Testid, mis läbivad valel põhjusel.** Kohalikul pinul ja hostitud projektil olid erinevad vaikeõigused, nii et "anon ei saa sisestada" läbis kohalikult, sest õigus puudus, mitte sellepärast, et RLS töötas. Negatiivne test tähendab midagi ainult siis, kui positiivne õigus on olemas. Võrrelge `pg_default_acl` kohalikult ja tootmises.
8. **Elav andmebaas, mitte migratsioonifailid.** Pärast migratsiooni või projekti kolimist võrrelge seda, mis tegelikult töötab: `pg_policies`, `pg_get_functiondef` iga kaitse jaoks ja ülaltoodud õigused. Ühes teises rakenduses kopeeris uus migratsioon vana funktsiooni keha ja tühistas vaikselt hilisema parandust.

## Kas Lovable'i rakendus vastab GDPR-ile?

Lovable ei tee rakendust GDPR-iga kooskõlas olevaks ega vastuolus olevaks; selle otsustab, mida rakendus isikuandmetega teeb, ja turvaülevaatus sellele ei vasta. Need on kuus lünka, mida ma Lovable Cloudi rakenduses kontrollin, igaüks koos parandusega:

1. **Loetlege kõik volitatud töötlejad.** Lovable Cloud käitab andmebaasi, autentimist, salvestust ja funktsioone Supabase'is, Lovable majutab saiti ja saab saata sisselogimiskirju ning Lovable AI Gateway annab teksti edasi mudelipakkujale. Lisage iga e-posti-, tehisintellekti- või scraping-teenus, mida teie funktsioonid kutsuvad. Igaüks, kes saab isikuandmeid, vajab andmetöötluslepingut (DPA) ja väljaspool ELi asuv lisaks edastamise alust. Majutuse piirkonda koodis ei ole, nii et küsige seda.
2. **Kustutage kasutaja, kellel on sisu.** Selle kasutaja kirjutatud sisu võõrvõtmed võivad kustutamise blokeerida ja siis ei saa kustutamistaotlust täita. Pange need võtmed cascade'i või set null'i peale, lisage kustutamistrigger, mis eemaldab ka kasutaja e-postilogid ja sisselogimistokenid, ning hoidke andmebaasitesti, mis sellise kasutaja kustutab.
3. **Määrake säilitustähtaeg.** E-postilogid, vaatamiste jälgimine, ebaõnnestunud kirjade järjekorrad ja pehmelt kustutatud read hoiavad isikuandmeid sageli lõpptähtajata. Ajastatud töö, mis kustutab pehmelt kustutatud read kindla aja järel lõplikult koos nende failidega, sulgeb suurema osa.
4. **E-kirjade jälgimine ainult nõusolekuga.** Avamiste ja klikkide salvestamine adressaadi kaupa nõuab ePrivacy reeglite järgi nõusolekut: nõusoleku lipp, vaikimisi väljas, ajatempliga, mille paneb server, mitte klient.
5. **Hoidke aadressid funktsioonide logidest eemal.** Edge function'ite logisid ei puhastata, nii et `console.log` adressaadi aadressiga jätab selle sinna. Logige ID-sid ja arve.
6. **Lülitage e-posti kinnitus sisse.** Automaatse kinnitusega saab igaüks registreeruda aadressiga, mis talle ei kuulu, ja tuua rakendusse päris inimese aadressi. Ülaltoodud loendi punkt 6 katab registreerimise poole.

Kuidas oma rakendust kontrollida: otsige funktsioonidest API võtmeid, et teenused üles lugeda, kustutage sisuga testkasutaja, otsige funktsioonide logidest `@` ja küsige igalt pakkujalt andmetöötluslepingut. See ei ole õigusnõu.

## Kuidas hoida see tagasi tulemast?

Iga ülaltoodud kontroll on päring või test, nii et hoidke need repos ja käivitage enne iga deploy'd. Supabase'i [pgTAP testid](https://supabase.com/docs/guides/database/extensions/pgtap) katavad õigused, poliitikad ja funktsioonid; kahe ettevõtte test kuulub nende kõrvale. Kui teie rakendusel on rollid ja õiguste ekraan, ei piisa ka testist poliitika kohta: ma tõestan iga õiguse ruudu tootmise koopia vastu, nagu kirjeldatud kirjutises [kuidas Supabase'i RLS-i testida](https://madsalt.tech/et/blog/how-to-test-supabase-rls/), kus 87 ruudust 30 ei teinud midagi. Tasuta [Supabase turvakontroll](https://madsalt.tech/et/tools/supabase-security-check/) käitab 46 OWASP Top 10:2025 reeglit projekti rollide, õiguste, poliitikate ja autentimisseadete vastu, nii et kasutage seda esmaseks läbivaatuseks; kahe ettevõtte test ja kõik, mis puudutab teie kasutajaliidest, jäävad käsitööks.

Mida see nimekiri ei kata: maksed ja webhook'id, saladused teie Giti ajaloos, turvapäised hostil, varukoopiad. Need on olulised, kuid see on teine kontrollnimekiri.

Kui pärisite Lovable'i või Supabase'i rakenduse ja pole kindel, millised neist kontrollidest see läbib, algab [projekti päästmine](https://madsalt.tech/et/services/project-rescue/) just sellest auditist. [Audiitorfirma ajaarvestuse juhtum](https://madsalt.tech/et/work/audit-firm-time-tracking/) näitab, kuidas rollikontrollid tootmisrakenduses välja näevad.

Leidsite augu, mida see nimekiri ei märka?

Kuulaksin hea meelega. Võrdlen hea meelega märkmeid Lovable'i ja Supabase'i rakenduste turvamise kohta.

[Võtke ühendust](https://madsalt.tech/et/#contact)