--- title: "Lovable lietotnes drošība: 12 pārbaudes un 8 manas" description: "Lovable lietotnes drošības kontrolsaraksts Supabase datubāzei no klienta projekta. Katrai pārbaudei vaicājums vai tests, plus 8 robi, ko saraksti izlaiž." url: "https://madsalt.tech/lv/blog/lovable-app-security-checklist/" author: "Denys Zaichenko" language: "lv" published: 2026-10-18 updated: 2026-10-25 --- # Lovable lietotnes drošība: 12 pārbaudes un 8 manas Īsumā Lovable lietotne ir tik droša, cik droša ir tās Supabase datubāze, un "RLS ir ieslēgts" pierāda ļoti maz. Testējiet ar diviem lietotājiem divos uzņēmumos, turiet lomas ārpus lietotāja metadatiem, turiet slepeno atslēgu ārpus pārlūka un atsevišķi pārbaudiet piešķirtās tiesības, skatus, storage, funkcijas un ātruma ierobežojumus, jo katrs no tiem apiet jūsu politikas savā veidā. Zemāk ir saraksts, ko palaižu, uzvedne, ko varat ielīmēt Lovable vai Claude, un astoņas pārbaudes, ko pievienoju pēc tam, kad klienta Lovable lietotne parādīja, ko pirmās divpadsmit izlaiž. Es esmu Denys, full-stack un AI inženieris. Šomēnes es labojau klienta lietotni, kas izveidota ar Lovable. Viss darbojās uz Supabase, kā parasti, un drošības labojumu bija tik daudz, ka šķita, ka lietotne no tiem sastāv. Šo sarakstu es tagad izeju katrā Lovable vai Supabase projektā, pirms saku, ka klientu dati ir aizsargāti. ## Vai Lovable ir drošs? Līdz šim zināmās drošības problēmas Platforma izveido un mitina jūsu lietotni, taču lietotnes drošība lielākoties ir atkarīga no tās aizmugurē esošās Supabase datubāzes, jo lietotne šo datubāzi lasa un raksta tieši no pārlūka. Publiski zināmie gadījumi parāda abu veidu problēmas: | Kad | Kas notika | Avots | | ------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 2025. gada marts | CVE-2025-48757: 1645 Lovable demonstrācijas lietotņu skenēšana atrada 303 endpoint 170 no tām, kas atdeva datus ikvienam ar publisko atslēgu, jo RLS trūka vai bija pārāk vaļīgs | [Matt Palmer atklājums](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/), 2025. gada maijs | | 2026. gada februāris | Viena Lovable mitināta lietotne atklāja 18 697 lietotāju ierakstus; piekļuves pārbaude tās funkcijās ielaida anonīmus apmeklētājus un bloķēja pieteikušos lietotājus. Lovable norādīja, ka daļu koda Lovable nav ģenerējis | [The Register](https://www.theregister.com/software/2026/02/27/ai-built-app-on-lovable-exposed-18k-users-researcher-claims/5038511), 2026. gada 27. februāris | | No 2026. gada 3. februāra līdz 20. aprīlim | Platformas regresija ļāva citiem Lovable lietotājiem lasīt publisko projektu tērzēšanas vēsturi un pirmkodu | [Lovable incidenta ieraksts](https://lovable.dev/blog/our-response-to-the-april-2026-incident), 2026. gada 22. aprīlis | Pirmie divi ir lietotnes līmeņa robi, tādi, kādus noķer zemāk esošās pārbaudes. Trešā bija paša Lovable kļūda, un Lovable to izlaboja; jūsu daļa ir turēt atslēgas ārpus tērzēšanas un koda (3. pārbaude) un nomainīt visas, kas tur bija. Lovable pirms publicēšanas palaiž drošības skenēšanu, taču rīkoties pēc tās rezultātiem ir jūsu ziņā, un brīdī, kad CVE tika publicēts, šī skenēšana pārbaudīja, vai politika pastāv, nevis vai tā ir pareiza. Tāpēc jautājums "vai Lovable ir drošs" beidzas ar to, vai jūsu datubāze iztur zemāk esošās pārbaudes. ## Kāpēc ar "RLS ir ieslēgts" Lovable lietotnē nepietiek? Lovable lietotne runā ar datubāzi tieši no pārlūka. Starp tiem nav jūsu pašu backend: lapa izsauc Supabase Data API ar publisku atslēgu, un Postgres izlemj, ko atdot (kuras shēmas šis API sniedz, ir atsevišķs iestatījums, ko aplūko piezīme [Supabase exposed schemas](https://madsalt.tech/lv/notes/supabase-exposed-schemas/)). Tāpēc katram noteikumam, kas sargā klientu datus, jādzīvo datubāzē, un datubāzei ir vairākas durvis. Row level security ir viena no tām. Piešķirtās tiesības (grants) nosaka, vai loma vispār drīkst pieskarties tabulai, politikas nosaka, kuras rindas, un trīs lietas politikas apiet pavisam: slepenā atslēga, skati, izveidoti bez `security_invoker`, un `SECURITY DEFINER` funkcijas. Tas nav hipotētiski. Paša Lovable [drošības ceļvedis](https://docs.lovable.dev/tips-tricks/security-best-practices) liek pārskatīt RLS politikas, ko tas iestata, un augstāk minētais [CVE-2025-48757](https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps) ir tas, kas notiek, kad neviens to nedara. ![Četri veidi, kā pieprasījums sasniedz datus. Tikai pirmo pārbauda jūsu RLS politikas. Parasts pieprasījums: Pārlūks → Tiesības → RLS politika → Savas rindas; Slepenā atslēga edge function: Pārlūks → Edge function → Slepenā atslēga → Visas rindas; Skats bez security_invoker: Pārlūks → Skats → Īpašnieka tiesības → Visas rindas; SECURITY DEFINER funkcija: Pārlūks → RPC → Īpašnieka tiesības → Visas rindas.](https://madsalt.tech/charts/lv/lovable-app-security-checklist-paths.svg) *1. attēls. Jūsu politikas pārbauda tikai pirmo ceļu. Pārējie trīs darbojas ar tiesībām, kas apiet RLS. Avots: Supabase dokumentācija par RLS un API aizsardzību, 2026. gada oktobris.* ## Uzvedne: ielīmējiet to Lovable vai Claude Varat ielīmēt kā ir. Pēc tam rezultātu pārbaudiet paši: AI mīl teikt "gatavs", kad tā nav, un uzvedne, kas liek kļūdai pazust, var to panākt, paplašinot piekļuvi. ```text Pārbaudi šo projektu drošības ziņā, izlabo atrasto un pastāsti, ko mainīji: 1. Testē ar diviem lietotājiem divos uzņēmumos. A lietotājs mēģina lasīt, rediģēt un dzēst B ierakstus pēc id, caur API, meklēšanu un eksportiem. Visiem mēģinājumiem jāizgāžas. 2. RLS katrā tabulā, politikas pārbauda rindas īpašnieku vai uzņēmumu. "Pieteicies" nepietiek. 3. Service role key nekad nav frontendā. Edge function, kas to izmanto, pati pārbauda lietotāju un filtrē pēc uzņēmuma, jo atslēga apiet RLS. 4. Lomas, plānu, uzņēmuma id nekad neņem no user metadata, lietotāji to var rediģēt. Glabā tabulā, ko raksta tikai serveris. 5. Ja pieprasījums sūta divus id (projekts + uzdevums), pārbaudi, vai uzdevums pieder šim projektam. 6. Atsauc visas tabulu privilēģijas no anon un authenticated, atdod atpakaļ tikai to, ko prasa politikas. RLS neaptur TRUNCATE. Katra migrācija, kas izveido tabulu, ietver tās GRANT: no 2026. gada 30. oktobra Supabase jaunām tabulām tiesības vairs nepiešķir automātiski, un lietotne saņem kļūdu 42501. 7. Visi skati ar security_invoker = true, citādi tie apiet RLS. 8. Storage buckets: lietotāji lasa un raksta tikai savus failus, privātiem datiem nav publisku buckets. 9. SECURITY DEFINER funkcijas: NULL nozīmē aizliegt, nevis atļaut. 10. Ātruma ierobežojumi pieteikšanās, reģistrācijas, atiestatīšanas un OTP, glabāti DB, nevis atmiņā. 11. Validē visu ievadi serverī. 12. Palaid Supabase security advisor, izlabo katru brīdinājumu. ``` ## 12 pārbaudes un kā pierādīt katru ### 1. Divi lietotāji divos uzņēmumos Izveidojiet lietotāju A uzņēmumā 1 un lietotāju B uzņēmumā 2, katram dažus ierakstus. Piesakieties kā A un mēģiniet lasīt, rediģēt un dzēst B ierakstus pēc id, caur API, caur meklēšanu un caur katru eksportu. Katram mēģinājumam jāatgriež nekas vai kļūda. Šis ir vienīgais tests, kas noķer lielāko daļu no sekojošā, jo tas pārbauda to, ko dara uzbrucējs, nevis to, ko uzrakstījāt jūs. ![Divi lietotāji, divi uzņēmumi. A lietotājs no 1. uzņēmuma tiek pie 2. uzņēmuma ierakstiem. Katram ceļam jāatgriež nekas. Pēc id caur API: Lietotājs A → B ieraksta id → Lasīt, rediģēt, dzēst → 0 rindu vai kļūda; Caur meklēšanu: Lietotājs A → Meklēt B tekstu → Rezultāti → Nav B rindu; Caur eksportu: Lietotājs A → Eksports → Fails → Nav B rindu.](https://madsalt.tech/charts/lv/lovable-app-security-checklist-test.svg) *2. attēls. Divu uzņēmumu tests. Izturēts nozīmē, ka neviens ceļš neatgriež neko no 2. uzņēmuma.* Pievienojiet trešo lietotāju, kas pieder abiem uzņēmumiem. Politika formā "izsaucējs ir rindas uzņēmuma dalībnieks" ļauj šim lietotājam lasīt 2. uzņēmuma rindas, strādājot 1. uzņēmumā. Citā Supabase lietotnē mana zonde ar tādu lietotāju atgrieza otra uzņēmuma dokumentu, līdz vaicājums tika papildināts ar filtru pēc pieprasījuma uzņēmuma. Šo aprakstīju kā [lietotājs divās org., ko RLS neizolēja](https://madsalt.tech/lv/notes/supabase-rls-user-in-two-organizations/). ### 2. RLS katrā tabulā, piesaistīts īpašniekam vai uzņēmumam `auth.uid() is not null` nozīmē "jebkurš pieteicies lietotājs", kas publiskā reģistrācijas lapā nozīmē jebkuru. Katra politika salīdzina rindas īpašnieku vai uzņēmumu ar izsaucēju. Uzskaitiet tabulas, kurām RLS vēl ir izslēgts: ```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. Slepenā atslēga nekad nav frontendā Service role key un jaunākā `sb_secret_` atslēga apiet katru politiku. Meklējiet abas sagatavotajā JavaScript un nomainiet katru atslēgu, kas jebkad nonākusi pārlūkā. Edge function, kas to izmanto, pati pārbauda, kas ir lietotājs, un pati filtrē pēc uzņēmuma, jo ar šo atslēgu to nedarīs nekas cits. ### 4. Lomas, plāns un uzņēmuma id nekad no lietotāja metadatiem `raw_user_meta_data` ir viss, ko klients nosūtīja uz `signUp`, un lietotāji to vēlāk var mainīt. Citā lietotnē jauna lietotāja trigeris no turienes nolasīja ielūgto lomu, tāpēc ikviens, kas reģistrējās, varēja nodot īpašnieka lomu un kļūt par Owner. Glabājiet lomas, plānus un uzņēmumu id tabulā, ko raksta tikai serveris, vai `app_metadata`. Pilns stāsts: [loma, kas ņemta no reģistrācijas metadatiem](https://madsalt.tech/lv/notes/supabase-raw-user-meta-data-role/). ### 5. Divi id vienā pieprasījumā: pārbaudiet, vai tie pieder kopā Ja pieprasījumā ir projekta id un uzdevuma id, ar projekta autorizēšanu nepietiek. Lietotājs ar tiesībām projektā A nosūta A un sadaļas id no projekta B, un rinda nonāk B. RLS to nenoķer, jo ievietošana atzīmē uzbrucēja paša projekta id, tieši to politika arī pārbauda. Pirms rakstāt, pārbaudiet, ka pakārtotais ieraksts pieder vecākam. ### 6. Piešķirtās tiesības: atsaukt, tad atdot tikai vajadzīgo Piešķirtās tiesības (grants) un politikas ir divi atsevišķi slāņi. Politiku pievienošana tiesības neatņem, tāpēc Supabase [RLS ceļvedis](https://supabase.com/docs/guides/database/postgres/row-level-security) liek tās atsaukt un atdot skaidri. Citā projektā `supabase/postgres` 17.6.1 attēls bija devis `anon` un `authenticated` TRUNCATE, REFERENCES, TRIGGER un MAINTAIN uz katras tabulas `public`, un neviena politika uz TRUNCATE neattiecas. Data API nav TRUNCATE endpoint, tāpēc tā nav dzēšana ar vienu pieprasījumu, taču nevienai klienta lomai tas nav vajadzīgs, un jebkura funkcija, kas izpilda SQL ar šo lomu, to manto. ```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; ``` Viens datums šo pārbaudi maina. Supabase [pārtrauc automātiski piešķirt tiesības jaunām tabulām](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically): jauniem projektiem kopš 2026. gada 30. maija un visiem esošajiem projektiem no 2026. gada 30. oktobra, arī tiem, ko izveidoja Lovable. Pēc tam tabula, ko Lovable vai migrācija izveido bez skaidra `GRANT`, lietotnei ir neredzama: pieprasījums beidzas ar kļūdu 42501, un funkcija, kas izmanto tabulu, salūst. Tāpēc katra migrācija, kas izveido tabulu, tagad nes savas tiesības blakus `enable row level security` un politikām. Divas lietas paliek nemainīgas. Esošās tabulas saglabā tiesības, kas tām ir, tāpēc nevajadzīgo atsaukšana joprojām ir jūsu darbs. Un izmaiņa atņem tikai select, insert, update un delete: Lovable projektā ar jaunajiem noklusējumiem jaunas tabulas joprojām nāca ar TRUNCATE, REFERENCES, TRIGGER un MAINTAIN priekš `anon` un `authenticated`. Vispirms atsaukt visu, tad piešķirt, joprojām ir drošā secība. ### 7. Katrs skats ar `security_invoker = true` Skats darbojas ar sava īpašnieka tiesībām, un Supabase īpašnieks parasti ir `postgres`, tāpēc skats virs aizsargātas tabulas atdod katru rindu, ko politikas liedz. Postgres 15 un jaunākā versijā: ```sql alter view public.customer_summary set (security_invoker = true); ``` ### 8. Storage: tikai savi faili, nekādu publisko bucket privātiem datiem Publisks bucket atdod jebkuru failu ikvienam, kam ir URL. Privātie faili jāliek privātā bucket ar politikām uz `storage.objects`, kas pārbauda īpašnieku vai uzņēmumu, parasti pēc ceļa pirmās mapes. Pēc projekta pārcelšanas saskaitiet spēkā esošās storage politikas: vienā lietotnē pēc pārcelšanas neizdevās katra augšupielāde, jo politiku migrācija nekad nepalaidās un tabulai bija ieslēgts RLS ar nulli politiku. ### 9. SECURITY DEFINER funkcijas: NULL nozīmē aizliegt PL/pgSQL `if not (has_permission or assignee_id = auth.uid())` neizmet kļūdu, ja `assignee_id` ir null: viss nosacījums ir null, un `if` to izlaiž. Tā pati izteiksme politikā ir droša, jo politika null uzskata par aizliegumu. Vienā lietotnē tas ļāva lomai ar izslēgtām visām atļaujām darboties ar visiem 3683 uzdevumiem, jo nevienam nebija atbildīgā. Ietiniet nosacījumu `coalesce(…, false)`. Sīkāk: [NULL PL/pgSQL IF NOT izlaida pārbaudi 3683 uzdevumiem](https://madsalt.tech/lv/notes/plpgsql-if-not-null-fails-open/). ### 10. Ātruma ierobežojumi, kas glabājas datubāzē Ierobežojiet pieteikšanos, reģistrāciju, paroles atiestatīšanu un OTP, un skaitītāju glabājiet Postgres. Lovable lietotnē ierobežojumi dzīvoja mainīgajā edge function iekšienē. Mitināto projektu pārbaudīju 2026. gada 17. oktobrī: katrs pieprasījums darbojās jaunā isolate, tāpēc skaitītājs atmiņā vienmēr bija 1 un ierobežojums nekad nevarēja iedarboties. Lokālais `supabase functions serve` isolate izmanto atkārtoti, tāpēc tas pats kods izturēja visus lokālos testus. ![Kur dzīvo skaitītājs, nosaka, vai tas iedarbojas. Ātruma ierobežojums mitinātā Supabase edge function. Skaitītājs funkcijas atmiņā: Pieprasījums → Jauns isolate → Skaitītājs = 1 → Nekad neierobežo; Skaitītājs Postgres: Pieprasījums → claim_rate_limit → Kopīga rinda → 429 pie limita.](https://madsalt.tech/charts/lv/lovable-app-security-checklist-ratelimit.svg) *3. attēls. Mans mitinātas Supabase edge function tests 2026. gada 17. oktobrī: katrs pieprasījums sāka jaunu isolate.* Atslēga ir tikpat svarīga kā glabātuve. Mitinātajā platformā pēdējais `X-Forwarded-For` lēciens ir pašas Supabase starpniekserveris, tāpēc atslēga uz tā ievieto visus izsaucējus vienā grozā, bet `x-client-ip` iestata klients. Manā zondē īsto klientu nesa `cf-connecting-ip`. Labojums bija `SECURITY DEFINER` funkcija `claim_rate_limit(bucket, key, max, window)`, ko var izpildīt tikai service role, serializēta ar advisory lock, kas glabā IP vai lietotāja id jaucējkodu, nevis neapstrādātu vērtību. ### 11. Validējiet visu ievadi serverī Lai ko pārbauda forma, API pieņem visu, ko sūta klients. Garumus, formātus, enum un piederību pārbauda datubāzē (ierobežojumi, trigeri) vai edge function, nekad tikai React. ### 12. Supabase Security Advisor, katrs brīdinājums Atveriet Advisors, tad Security Advisor, un izlabojiet katru atradumu. Tas norāda tabulas ar izslēgtu RLS, skatus, kas apiet RLS, politikas, kas lasa lietotāja metadatus, pieļāvīgas `using (true)` politikas un funkcijas ar mainīgu `search_path`. Tas neredz 1., 5., 9. un 10. pārbaudi, jo tās ir par loģiku, nevis konfigurāciju. ## Ko Lovable lietotne iemācīja, ko šīs 12 izlaiž? Šie atklājumi nāca no klienta lietotnes un tās pārskatiem. Neviens no tiem neparādās skenerī. 1. **Lauki, ko klients nedrīkst iestatīt.** Klients pats nosūtīja `status: 'approved'`, kas apgāja moderāciju. UPDATE politika, kuras `with check` ir brīvāks par `using`, ļauj arī pārvietot rindu pie cita īpašnieka. Politika nevar aprēķināt vērtību, tāpēc `BEFORE INSERT OR UPDATE` trigeris no servera paša datiem no jauna atvasina `status`, lomu, cenu un uzņēmumu un ignorē to, ko sūtīja klients. 2. **Katrs rakstīšanas ceļš, ne tikai galvenā ievietošana.** Pēc galvenās ievietošanas labošanas tas pats apiešanas ceļš bija pielikumos, komentāros, dzēstas vienības atjaunošanā un skaitītājos. Pirms labojat pirmo, uzskaitiet katru aizsargātās kolonnas rakstītāju. 3. **Atļauju saraksti, nevis aizliegumu saraksti.** Viltotie ieraksti prasīja piecas pārskatu kārtas, jo katrs labojums bloķēja vienu kombināciju un atstāja kaimiņu atvērtu. Trigeris, kas atļauj tikai uzskaitītās tipa un statusa kombinācijas, aizvēra visu klasi uzreiz. 4. **Funkcijas arī ir API.** Katru funkciju shēmā `public` caur `/rpc` var izsaukt jebkura loma ar EXECUTE, un RLS uz funkcijām neattiecas. Katrai `SECURITY DEFINER` funkcijai iestatiet `set search_path = ''`, atsauciet EXECUTE no `public`, `anon` un `authenticated` un piešķiriet to tikai lomai, kurai tas vajadzīgs. 5. **EXECUTE atsaukšana var salauzt publiskās lapas.** Postgres pārbauda EXECUTE katrai funkcijai, ko izmanto katra politika, kas attiecas uz lomu, pat zarā, kas nekad neizpildītos. Kad `anon` zaudēja EXECUTE uz `is_admin()`, katrs anonīmais lasījums izgāzās ar 42501. Administratoru politikas liek `to authenticated`, bet publiskajiem lasījumiem dod savu politiku bez administratora zara. 6. **Reģistrācija ar ieslēgtu e-pasta apstiprināšanu.** Ar ieslēgtu apstiprināšanu `signUp` neatgriež sesiju, tāpēc jebkurš profila ieraksts uzreiz pēc tā darbojas kā `anon` un klusi neieraksta neko. Lovable projektos bieži ir ieslēgta automātiskā apstiprināšana, kas kļūdu paslēpj. Nododiet laukus caur `signUp({ options: { data } })`, ļaujiet jauna lietotāja trigerim tos validēt un rakstīt, un uzskatiet šos metadatus par neuzticamiem (4. pārbaude). 7. **Testi, kas iziet nepareizā iemesla dēļ.** Lokālajam stekam un mitinātajam projektam bija atšķirīgas noklusējuma privilēģijas, tāpēc "anon nevar ievietot" lokāli izgāja, jo trūka tiesību, nevis tāpēc, ka darbojās RLS. Negatīvam testam ir jēga tikai tad, ja pozitīvā tiesība pastāv. Salīdziniet `pg_default_acl` lokāli un produkcijā. 8. **Dzīvā datubāze, nevis migrāciju faili.** Pēc migrācijas vai projekta pārcelšanas salīdziniet to, kas patiešām darbojas: `pg_policies`, `pg_get_functiondef` katram aizsargam un iepriekš minētās tiesības. Citā lietotnē jauna migrācija nokopēja vecu funkcijas pamatteksta versiju un klusi atcēla vēlāku labojumu. ## Vai Lovable lietotne atbilst GDPR? Lovable nepadara lietotni atbilstošu vai neatbilstošu; to izšķir tas, ko lietotne dara ar personas datiem, un drošības pārskats uz to neatbild. Šīs ir sešas nepilnības, ko pārbaudu Lovable Cloud lietotnē, katra ar labojumu: 1. **Uzskaitiet visus apstrādātājus.** Lovable Cloud darbina datubāzi, autentifikāciju, krātuvi un funkcijas uz Supabase, Lovable hostē vietni un var sūtīt pieteikšanās e-pastus, un Lovable AI Gateway nodod tekstu modeļa nodrošinātājam. Pievienojiet katru e-pasta, AI vai scraping pakalpojumu, ko izsauc jūsu funkcijas. Katram, kas saņem personas datus, vajadzīgs datu apstrādes līgums (DPA), un tam, kas atrodas ārpus ES, vēl arī datu nodošanas mehānisms. Hostinga reģions kodā neparādās, tāpēc pajautājiet to. 2. **Izdzēsiet lietotāju, kuram ir saturs.** Ārējās atslēgas no tā, ko lietotājs uzrakstījis, var bloķēt dzēšanu, un tad dzēšanas pieprasījumu nevar izpildīt. Iestatiet šīm atslēgām cascade vai set null, pievienojiet dzēšanas trigeri, kas noņem arī lietotāja e-pasta žurnālus un pieteikšanās tokenus, un paturiet datubāzes testu, kas izdzēš šādu lietotāju. 3. **Nosakiet glabāšanas termiņu.** E-pasta žurnāli, skatījumu uzskaite, neizdevušos e-pastu rindas un mīksti dzēstas rindas bieži glabā personas datus bez beigu datuma. Ieplānots darbs, kas pēc noteikta termiņa galīgi izdzēš mīksti dzēstās rindas un noņem to failus, aizver lielāko daļu. 4. **E-pastu izsekošana tikai ar piekrišanu.** Atvēršanas un klikšķu reģistrēšana katram saņēmējam pēc ePrivacy noteikumiem prasa piekrišanu: piekrišanas karogs, pēc noklusējuma izslēgts, ar laikspiedolu, ko iestata serveris, nevis klients. 5. **Turiet adreses ārpus funkciju žurnāliem.** Edge function žurnāli netiek tīrīti, tāpēc `console.log` ar saņēmēja adresi to tur atstāj. Reģistrējiet ID un skaitus. 6. **Ieslēdziet e-pasta apstiprināšanu.** Ar automātisko apstiprināšanu ikviens var reģistrēties ar adresi, kas viņam nepieder, un ienest lietotnē īsta cilvēka adresi. Augstāk esošā saraksta 6. punkts aptver reģistrācijas pusi. Kā pārbaudīt savu lietotni: meklējiet funkcijās API atslēgas, lai uzskaitītu pakalpojumus, izdzēsiet testa lietotāju ar saturu, meklējiet `@` funkciju žurnālos un palūdziet katram nodrošinātājam datu apstrādes līgumu. Tas nav juridisks padoms. ## Kā neļaut tam atgriezties? Katra pārbaude augstāk ir vaicājums vai tests, tāpēc glabājiet tos repozitorijā un palaidiet pirms katras izvietošanas. Supabase [pgTAP testi](https://supabase.com/docs/guides/database/extensions/pgtap) sedz tiesības, politikas un funkcijas; divu uzņēmumu tests jāliek blakus. Ja jūsu lietotnei ir lomas un atļauju ekrāns, arī ar testu katrai politikai nepietiek: katru atļauju rūtiņu es pierādu pret produkcijas kopiju, kā aprakstīts rakstā [kā testēt Supabase RLS](https://madsalt.tech/lv/blog/how-to-test-supabase-rls/), kur 30 no 87 rūtiņām neko nedarīja. Bezmaksas [Supabase drošības pārbaude](https://madsalt.tech/lv/tools/supabase-security-check/) palaiž 46 OWASP Top 10:2025 noteikumus pret projekta lomām, tiesībām, politikām un autentifikācijas iestatījumiem, tāpēc izmantojiet to pirmajam piegājienam; divu uzņēmumu tests un viss, kas attiecas uz jūsu saskarni, paliek manuāls. Ko šis saraksts neaptver: maksājumus un webhooks, noslēpumus jūsu Git vēsturē, drošības headers uz hosta, rezerves kopijas. Tie ir svarīgi, bet tas ir cits kontrolsaraksts. Ja esat mantojis Lovable vai Supabase lietotni un neesat pārliecināti, kuras no šīm pārbaudēm tā iztur, ar šo auditu sākas [projekta glābšana](https://madsalt.tech/lv/services/project-rescue/). [Revīzijas uzņēmuma darba laika uzskaites gadījums](https://madsalt.tech/lv/work/audit-firm-time-tracking/) rāda, kā lomu pārbaudes izskatās produkcijas lietotnē. Atradāt robu, ko šis saraksts izlaiž? Labprāt to uzzinātu. Labprāt salīdzināšu pieredzi par Lovable un Supabase lietotņu drošināšanu. [Sazināties](https://madsalt.tech/lv/#contact)