--- title: "Bezpečnosť Lovable aplikácie: 12 kontrol a 8 navyše" description: "Checklist bezpečnosti Lovable aplikácie na Supabase z opravy aplikácie klienta. Ku každej kontrole patrí dotaz alebo test, plus 8 dier navyše." url: "https://madsalt.tech/sk/blog/lovable-app-security-checklist/" author: "Denys Zaichenko" language: "sk" published: 2026-10-18 updated: 2026-10-25 --- # Bezpečnosť Lovable aplikácie: 12 kontrol a 8 navyše TL;DR Aplikácia z Lovable je rovnako bezpečná ako jej databáza Supabase a „RLS je zapnuté“ dokazuje veľmi málo. Testujte s dvoma používateľmi v dvoch firmách, roly držte mimo metadát používateľa, tajný kľúč mimo prehliadača a granty, views, storage, funkcie a limity požiadaviek kontrolujte osobitne, pretože každé z nich obchádza vaše politiky po svojom. Nižšie je zoznam, ktorý prechádzam, prompt, ktorý môžete vložiť do Lovable alebo Claude, a osem kontrol, ktoré som pridal potom, čo mi aplikácia klienta ukázala, čo prvých dvanásť míňa. Som Denys, full-stack a AI inžinier. Tento mesiac som opravoval klientovu aplikáciu postavenú v Lovable. Všetko bežalo na Supabase, ako zvyčajne, a bezpečnostných opráv bolo toľko, že sa zdalo, akoby bola aplikácia z nich poskladaná. Toto je zoznam, ktorý teraz prechádzam pri každom projekte v Lovable alebo na Supabase, než vyhlásim dáta zákazníkov za chránené. ## Je Lovable bezpečný? Doterajšie bezpečnostné problémy Platforma aplikáciu stavia a hostuje, ale to, či je aplikácia bezpečná, závisí hlavne od databázy Supabase za ňou, pretože aplikácia túto databázu číta aj zapisuje priamo z prehliadača. Verejné záznamy ukazujú oba druhy problémov: | Kedy | Čo sa stalo | Zdroj | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | Marec 2025 | CVE-2025-48757: sken 1 645 ukážkových aplikácií z Lovable našiel 303 endpointov v 170 z nich, ktoré vydávali dáta komukoľvek s verejným kľúčom, pretože RLS chýbalo alebo bolo príliš voľné | [Zverejnenie Matta Palmera](https://mattpalmer.io/posts/2025/05/statement-on-CVE-2025-48757/), máj 2025 | | Február 2026 | Jedna aplikácia hostovaná na Lovable odhalila 18 697 záznamov používateľov; kontrola prístupu v jej funkciách púšťala dnu anonymných návštevníkov a blokovala prihlásených používateľov. Lovable uviedol, že časť kódu negeneroval Lovable | [The Register](https://www.theregister.com/software/2026/02/27/ai-built-app-on-lovable-exposed-18k-users-researcher-claims/5038511), 27. februára 2026 | | 3. februára – 20. apríla 2026 | Regresia na platforme umožnila ostatným používateľom Lovable čítať históriu chatu a zdrojový kód verejných projektov | [Príspevok Lovable o incidente](https://lovable.dev/blog/our-response-to-the-april-2026-incident), 22. apríla 2026 | Prvé dva prípady sú diery na úrovni aplikácie, presne také, aké zachytia kontroly nižšie. Tretí bol chybou samotného Lovable a Lovable ju opravil; vaším dielom je držať kľúče mimo chatov a kódu (kontrola 3) a rotovať všetky, ktoré tam boli. Lovable pred publikáciou spúšťa bezpečnostný sken, ale konať podľa neho je na vás, a v čase zverejnenia CVE tento sken kontroloval, že politika existuje, nie že je správna. Otázka „je Lovable bezpečný“ sa teda scvrkáva na to, či vaša databáza prejde kontrolami nižšie. ## Prečo v aplikácii z Lovable nestačí „RLS je zapnuté“? Aplikácia z Lovable komunikuje s databázou priamo z prehliadača. Žiadny váš vlastný backend medzi tým nie je: stránka volá Supabase Data API verejným kľúčom a o tom, čo sa vráti, rozhoduje Postgres (ktoré schémy toto API ponúka, to je samostatné nastavenie, popísané v [Supabase exposed schemas](https://madsalt.tech/sk/notes/supabase-exposed-schemas/)). Každé pravidlo, ktoré chráni dáta zákazníkov, preto musí žiť v databáze, a databáza má niekoľko dverí. Row level security sú jedny z nich. Granty rozhodujú, či sa rola vôbec smie dotknúť tabuľky, politiky rozhodujú, ktoré riadky, a tri veci politiky preskočia úplne: tajný kľúč, views vytvorené bez `security_invoker` a funkcie `SECURITY DEFINER`. Nie je to teória. Vlastný [bezpečnostný sprievodca](https://docs.lovable.dev/tips-tricks/security-best-practices) Lovable vás žiada, aby ste skontrolovali RLS politiky, ktoré nastavilo, a [CVE-2025-48757](https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps) vyššie ukazuje, čo sa stane, keď to nikto nekontroluje. ![Štyri cesty požiadavky k vašim dátam. Len prvú kontrolujú vaše politiky RLS. Bežná požiadavka: Prehliadač → Grant → Politika RLS → Vlastné riadky; Tajný kľúč v edge funkcii: Prehliadač → Edge funkcia → Tajný kľúč → Každý riadok; View bez security_invoker: Prehliadač → View → Práva vlastníka → Každý riadok; Funkcia SECURITY DEFINER: Prehliadač → RPC → Práva vlastníka → Každý riadok.](https://madsalt.tech/charts/sk/lovable-app-security-checklist-paths.svg) *Obrázok 1. Len prvú cestu kontrolujú vaše politiky. Ostatné tri bežia s právami, ktoré RLS preskakujú. Zdroj: dokumentácia Supabase k RLS a zabezpečeniu API, október 2026.* ## Prompt: vložte ho do Lovable alebo Claude Môžete ho vložiť tak, ako je. Výsledok si potom skontrolujte sami: AI rada povie „hotovo“, aj keď to tak nie je, a prompt, po ktorom chyba zmizne, to môže urobiť rozšírením prístupu. ```text Skontroluj tento projekt z hľadiska bezpečnosti, oprav, čo nájdeš, a napíš mi, čo si zmenil: 1. Testuj s dvoma používateľmi v dvoch firmách. Používateľ A skúsi čítať, upraviť a zmazať záznamy používateľa B podľa id, cez API, vyhľadávanie a exporty. Všetko musí zlyhať. 2. RLS na každej tabuľke, politiky kontrolujú vlastníka riadku alebo firmu. „Prihlásený“ nestačí. 3. Kľúč service role nikdy vo frontende. Edge funkcie, ktoré ho používajú, samy kontrolujú používateľa a filtrujú podľa firmy, kľúč RLS obchádza. 4. Roly, plán a id firmy nikdy z metadát používateľa, používatelia ich môžu upraviť. Drž ich v tabuľke, ktorú zapisuje iba server. 5. Keď požiadavka posiela dve id (projekt + úloha), skontroluj, že úloha patrí k tomu projektu. 6. Odober anon a authenticated všetky oprávnenia k tabuľkám a vráť iba to, čo politiky potrebujú. RLS nezastaví TRUNCATE. Každá migrácia, ktorá vytvára tabuľku, obsahuje jej GRANT: od 30. októbra 2026 Supabase nové tabuľky automaticky nesprístupňuje a aplikácia dostane chybu 42501. 7. Všetky views so security_invoker = true, inak RLS preskakujú. 8. Storage buckety: používatelia čítajú a zapisujú iba vlastné súbory, žiadne verejné buckety pre súkromné dáta. 9. Funkcie SECURITY DEFINER: NULL musí znamenať zamietnutie, nie povolenie. 10. Limity požiadaviek na prihlásenie, registráciu, reset hesla a OTP, uložené v DB, nie v pamäti. 11. Validuj všetok vstup na serveri. 12. Spusti Supabase security advisor a oprav každé varovanie. ``` ## 12 kontrol a ako každú dokázať ### 1. Dvaja používatelia v dvoch firmách Vytvorte používateľa A vo firme 1 a používateľa B vo firme 2, každého s niekoľkými záznamami. Prihláste sa ako A a skúste záznamy B čítať, upraviť a zmazať podľa id, cez API, cez vyhľadávanie a cez každý export. Každý pokus musí nevrátiť nič, alebo skončiť chybou. Je to jediný test, ktorý zachytí väčšinu toho, čo nasleduje, pretože testuje, čo robí útočník, nie to, čo ste napísali. ![Dvaja používatelia, dve firmy. Používateľ A z firmy 1 skúša záznamy firmy 2. Každá cesta musí vrátiť nič. Podľa id cez API: Používateľ A → Id záznamu B → Čítať, upraviť, zmazať → 0 riadkov alebo chyba; Cez vyhľadávanie: Používateľ A → Hľadať text B → Výsledky → Žiadne riadky B; Cez export: Používateľ A → Export → Súbor → Žiadne riadky B.](https://madsalt.tech/charts/sk/lovable-app-security-checklist-test.svg) *Obrázok 2. Test dvoch firiem. Úspech znamená, že každá cesta vráti z firmy 2 nič.* Pridajte tretieho používateľa, ktorý patrí do oboch firiem. Politika v tvare „volajúci je členom firmy riadku“ dovolí tomuto používateľovi čítať riadky firmy 2, zatiaľ čo pracuje vo firme 1. V inej aplikácii na Supabase vrátila moja sonda na takom používateľovi dokument druhej firmy, kým dotaz nefiltroval aj podľa firmy požiadavky. Opísal som to v poznámke [používateľ v dvoch org, ktorého RLS neizolovalo](https://madsalt.tech/sk/notes/supabase-rls-user-in-two-organizations/). ### 2. RLS na každej tabuľke, obmedzené na vlastníka alebo firmu `auth.uid() is not null` znamená „akýkoľvek prihlásený používateľ“, čo na verejnej registračnej stránke znamená kohokoľvek. Každá politika porovnáva vlastníka alebo firmu riadku s volajúcim. Vypíšte tabuľky, ktoré majú RLS stále vypnuté: ```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. Tajný kľúč nikdy vo frontende Kľúč service role a novší kľúč `sb_secret_` obchádzajú každú politiku. Prehľadajte zostavený JavaScript na oba a vymeňte každý kľúč, ktorý kedy bol nasadený. Edge funkcie, ktoré ho používajú, musia samy overiť, kto je používateľ, a filtrovať podľa firmy, pretože s týmto kľúčom to neurobí nič iné. ### 4. Roly, plán a id firmy nikdy z metadát používateľa `raw_user_meta_data` je čokoľvek, čo klient poslal do `signUp`, a používatelia to môžu neskôr zmeniť. V inej aplikácii čítal trigger nového používateľa pozvanú rolu odtiaľ, takže ktokoľvek, kto sa zaregistroval, mohol odovzdať rolu vlastníka a stať sa Ownerom. Roly, plány a id firiem držte v tabuľke, ktorú zapisuje iba server, alebo v `app_metadata`. Celý príbeh: [rola prevzatá z metadát pri registrácii](https://madsalt.tech/sk/notes/supabase-raw-user-meta-data-role/). ### 5. Dve id v jednej požiadavke: skontrolujte, že k sebe patria Keď požiadavka nesie id projektu a id úlohy, autorizovať projekt nestačí. Používateľ s právami k projektu A pošle A plus id sekcie z projektu B a riadok skončí v B. RLS to nezachytí, pretože insert označí riadok útočníkovým vlastným id projektu, a to politika práve kontroluje. Pred zápisom overte, že podriadený záznam patrí k nadradenému. ### 6. Granty: odoberte všetko, vráťte len potrebné Granty a politiky sú dve oddelené vrstvy. Pridaním politík sa grant nevezme späť, a preto vám [sprievodca RLS](https://supabase.com/docs/guides/database/postgres/row-level-security) od Supabase radí odobrať a explicitne vrátiť. V inom projekte dal image `supabase/postgres` 17.6.1 rolám `anon` a `authenticated` oprávnenia TRUNCATE, REFERENCES, TRIGGER a MAINTAIN na každú tabuľku v `public` a na TRUNCATE sa žiadna politika nevzťahuje. Data API nemá endpoint pre TRUNCATE, takže to nie je zmazanie jednou požiadavkou, ale žiadna klientska rola to nepotrebuje a každá funkcia, ktorá spúšťa SQL pod touto rolou, to zdedí. ```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; ``` Jeden dátum túto kontrolu mení. Supabase [prestáva nové tabuľky automaticky sprístupňovať](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically): nové projekty od 30. mája 2026 a všetky existujúce projekty od 30. októbra 2026, vrátane tých, ktoré vytvorilo Lovable. Potom je tabuľka, ktorú Lovable alebo migrácia vytvorí bez explicitného `GRANT`, pre aplikáciu neviditeľná: požiadavka zlyhá s chybou 42501 a funkcia, ktorá tabuľku používa, prestane fungovať. Každá migrácia, ktorá vytvára tabuľku, preto odteraz nesie aj jej granty, popri `enable row level security` a politikách. Dve veci zostávajú rovnaké. Existujúce tabuľky si granty ponechajú, takže odobrať, čo nepotrebujete, je stále vaša práca. A zmena berie späť iba select, insert, update a delete: v projekte z Lovable prichádzali nové tabuľky aj s novými predvolenými hodnotami stále s TRUNCATE, REFERENCES, TRIGGER a MAINTAIN pre `anon` a `authenticated`. Najprv odobrať všetko a potom udeliť je stále bezpečné poradie. ### 7. Každé view so `security_invoker = true` View beží s právami svojho vlastníka a v Supabase je vlastníkom zvyčajne `postgres`, takže view nad chránenou tabuľkou vydá každý riadok, ktorý politiky zadržiavajú. Na Postgres 15 a novšom: ```sql alter view public.customer_summary set (security_invoker = true); ``` ### 8. Storage: iba vlastné súbory, žiadny verejný bucket pre súkromné dáta Verejný bucket vydá ktorýkoľvek súbor komukoľvek, kto pozná URL. Súkromné súbory patria do súkromného bucketu s politikami na `storage.objects`, ktoré kontrolujú vlastníka alebo firmu, zvyčajne podľa prvého priečinka cesty. Po presune projektu spočítajte živé politiky storage: v jednej aplikácii po presune zlyhal každý upload, pretože migrácia politík nikdy nebežala a tabuľka mala zapnuté RLS s nulou politík. ### 9. Funkcie SECURITY DEFINER: NULL znamená zamietnutie V PL/pgSQL `if not (has_permission or assignee_id = auth.uid())` nevyhodí chybu, keď je `assignee_id` null: celá podmienka je null a `if` ju preskočí. Rovnaký výraz je vnútri politiky bezpečný, pretože tá berie null ako zamietnutie. V jednej aplikácii to dovolilo role so všetkými oprávneniami vypnutými konať so všetkými 3683 úlohami, pretože žiadna nemala riešiteľa. Obaľte podmienku do `coalesce(…, false)`. Podrobnosti: [NULL v PL/pgSQL IF NOT preskočil kontrolu pri 3683 úlohách](https://madsalt.tech/sk/notes/plpgsql-if-not-null-fails-open/). ### 10. Limity požiadaviek uložené v databáze Obmedzte prihlásenie, registráciu, reset hesla a OTP a počítadlo držte v Postgrese. V aplikácii z Lovable žili limity v premennej vnútri edge funkcie. Hostovaný projekt som otestoval 17. októbra 2026: každá požiadavka bežala v novom isolate, takže počítadlo v pamäti bolo vždy 1 a limit sa nikdy nemohol spustiť. Lokálny `supabase functions serve` isolate znovu používa, takže rovnaký kód prešiel každým lokálnym testom. ![Kde žije počítadlo, určuje, či zaberie. Limit požiadaviek v hostovanej edge funkcii Supabase. Počítadlo v pamäti funkcie: Požiadavka → Nový isolate → Počítadlo = 1 → Nikdy obmedzené; Počítadlo v Postgrese: Požiadavka → claim_rate_limit → Zdieľaný riadok → 429 pri limite.](https://madsalt.tech/charts/sk/lovable-app-security-checklist-ratelimit.svg) *Obrázok 3. Moja sonda hostovanej edge funkcie Supabase, 17. októbra 2026: každá požiadavka spustila nový isolate.* Kľúč záleží rovnako ako úložisko. Na hostovanej platforme je posledný hop v `X-Forwarded-For` vlastná proxy Supabase, takže kľúčovanie podľa neho dá všetkých volajúcich do jedného koša, a `x-client-ip` nastavuje klient. V mojej sonde niesol skutočného klienta `cf-connecting-ip`. Oprava bola funkcia `SECURITY DEFINER` `claim_rate_limit(bucket, key, max, window)`, ktorú smie spustiť iba service role, serializovaná advisory zámkom, ukladajúca hash IP alebo id používateľa namiesto surovej hodnoty. ### 11. Validujte všetok vstup na serveri Nech formulár kontroluje čokoľvek, API prijme všetko, čo klient pošle. Dĺžky, formáty, enumy a vlastníctvo sa kontrolujú v databáze (constraints, triggery) alebo v edge funkcii, nikdy len v Reacte. ### 12. Supabase Security Advisor, každé varovanie Otvorte Advisors a potom Security Advisor a opravte každý nález. Označuje tabuľky s vypnutým RLS, views, ktoré RLS preskakujú, politiky čítajúce metadáta používateľa, príliš povoľné politiky `using (true)` a funkcie s premenlivým `search_path`. Kontroly 1, 5, 9 a 10 vidieť nemôže, pretože sa týkajú logiky, nie konfigurácie. ## Čo ma aplikácia z Lovable naučila, čo tých 12 míňa? Toto vzišlo z klientovej aplikácie a jej revízií. Nič z toho sa neobjaví v skeneri. 1. **Polia, ktoré klient nesmie nastavovať.** Klient si sám poslal `status: 'approved'`, čím preskočil moderáciu. UPDATE politika, ktorej `with check` je voľnejší než jej `using`, tiež dovolí používateľovi presunúť riadok k inému vlastníkovi. Politika hodnotu vypočítať nevie, a preto trigger `BEFORE INSERT OR UPDATE` znovu odvodí `status`, rolu, cenu a firmu z vlastných dát servera a ignoruje, čo poslal klient. 2. **Každá cesta zápisu, nie iba hlavný insert.** Potom, čo bol opravený hlavný insert, rovnaký prienik sedel v prílohách, komentároch, obnovení soft-deleted položky a počítadlách. Vypíšte všetkých zapisovateľov chráneného stĺpca, než opravíte prvého. 3. **Allow-listy, nie deny-listy.** Sfalšované záznamy dali päť kôl revízie, pretože každá oprava zablokovala jednu kombináciu a susednú nechala otvorenú. Trigger, ktorý povoľuje iba vymenované kombinácie typu a stavu, uzavrel celú triedu naraz. 4. **Funkcie sú tiež API.** Každá funkcia v `public` je volateľná cez `/rpc` akoukoľvek rolou s EXECUTE a RLS sa na funkcie nevzťahuje. Každej funkcii `SECURITY DEFINER` dajte `set search_path = ''`, odoberte EXECUTE od `public`, `anon` a `authenticated` a udeľte ho iba role, ktorá ho potrebuje. 5. **Odobratie EXECUTE môže rozbiť verejné stránky.** Postgres kontroluje EXECUTE pri každej funkcii použitej v každej politike, ktorá sa na rolu vzťahuje, aj vo vetve, ktorá by sa nikdy nespustila. Akonáhle `anon` stratil EXECUTE na `is_admin()`, každé anonymné čítanie skončilo chybou 42501. Politiky len pre adminov patria `to authenticated` a verejné čítania dostanú vlastnú politiku bez admin vetvy. 6. **Registrácia so zapnutým potvrdením e-mailu.** So zapnutým potvrdením `signUp` nevracia session, takže akýkoľvek zápis profilu hneď po ňom beží ako `anon` a ticho nezapíše nič. Projekty v Lovable majú často zapnuté auto-confirm, čo chybu skryje. Polia odovzdajte v `signUp({ options: { data } })`, nechajte ich validovať a zapísať triggerom nového používateľa a tie metadáta berte ako nedôveryhodné (kontrola 4). 7. **Testy, ktoré prechádzajú z nesprávneho dôvodu.** Lokálny stack a hostovaný projekt mali iné predvolené oprávnenia, takže „anon nemôže vkladať“ lokálne prešlo, pretože chýbal grant, nie preto, že RLS fungovalo. Negatívny test má zmysel, iba keď existuje pozitívny grant. Porovnajte `pg_default_acl` lokálne a v produkcii. 8. **Živá databáza, nie súbory migrácií.** Po migrácii alebo presune projektu porovnajte, čo je naozaj živé: `pg_policies`, `pg_get_functiondef` pri každej stráži a granty vyššie. V inej aplikácii nová migrácia skopírovala telo starej funkcie a ticho vrátila neskoršiu opravu. ## Je aplikácia z Lovable v súlade s GDPR? Lovable aplikáciu do súladu s GDPR nedostane ani ju z neho nevyvedie; rozhoduje to, čo aplikácia robí s osobnými údajmi, a bezpečnostná revízia na to neodpovie. Toto je šesť medzier, ktoré v aplikácii na Lovable Cloud kontrolujem, každá s opravou: 1. **Vypíšte všetkých sprostredkovateľov.** Lovable Cloud prevádzkuje databázu, autentifikáciu, úložisko a funkcie na Supabase, Lovable hostuje web a môže posielať prihlasovacie e-maily a Lovable AI Gateway odovzdáva text poskytovateľovi modelu. Doplňte každú e-mailovú, AI alebo scrapingovú službu, ktorú vaše funkcie volajú. Každá, ktorá dostáva osobné údaje, potrebuje zmluvu o spracúvaní osobných údajov (DPA), a tá mimo EÚ navyše mechanizmus prenosu. Región hostingu v kóde nikde nie je, takže sa naň opýtajte. 2. **Zmažte používateľa, ktorý má obsah.** Cudzie kľúče z toho, čo používateľ napísal, môžu zmazanie zablokovať, a potom žiadosť o vymazanie nejde splniť. Nastavte týmto kľúčom cascade alebo set null, pridajte trigger pri zmazaní, ktorý odstráni aj e-mailové logy a prihlasovacie tokeny používateľa, a držte databázový test, ktorý takého používateľa zmaže. 3. **Stanovte dobu uchovávania.** E-mailové logy, sledovanie zobrazení, fronty neúspešných e-mailov a soft-deleted riadky si osobné údaje často držia bez konca. Plánovaná úloha, ktorá soft-deleted riadky po pevnej dobe zmaže natrvalo aj s ich súbormi, uzavrie väčšinu. 4. **Sledovanie e-mailov len so súhlasom.** Zaznamenávať otvorenia a kliknutia podľa jednotlivých príjemcov vyžaduje podľa pravidiel ePrivacy súhlas: príznak súhlasu, predvolene vypnutý, s časovou pečiatkou od servera, nie od klienta. 5. **Držte adresy mimo logov funkcií.** Logy edge functions sa nečistia, takže `console.log` s adresou príjemcu ju tam nechá. Logujte ID a počty. 6. **Zapnite potvrdenie e-mailu.** S automatickým potvrdením sa ktokoľvek môže zaregistrovať s adresou, ktorá mu nepatrí, a dostať do aplikácie adresu skutočného človeka. Bod 6 v zozname vyššie rieši stranu registrácie. Ako skontrolovať vlastnú aplikáciu: nájdite vo funkciách API kľúče a vypíšte služby, zmažte testovacieho používateľa s obsahom, hľadajte `@` v logoch funkcií a vyžiadajte si od každého poskytovateľa zmluvu o spracúvaní. Nejde o právnu radu. ## Ako zariadiť, aby sa to nevrátilo? Každá kontrola vyššie je dotaz alebo test, takže ich držte v repozitári a spúšťajte pred každým nasadením. [Testy pgTAP](https://supabase.com/docs/guides/database/extensions/pgtap) od Supabase pokryjú granty, politiky a funkcie; test dvoch firiem patrí vedľa nich. Ak má vaša aplikácia roly a obrazovku oprávnení, nestačí ani test na každú politiku: každé políčko oprávnení dokazujem proti kópii produkcie, opísané v [ako testovať Supabase RLS](https://madsalt.tech/sk/blog/how-to-test-supabase-rls/), kde 30 z 87 políčok nerobilo nič. Bezplatná [Kontrola zabezpečenia Supabase](https://madsalt.tech/sk/tools/supabase-security-check/) spúšťa 46 pravidiel OWASP Top 10:2025 proti rolám, grantom, politikám a nastaveniam autentifikácie projektu, takže ju použite na prvý prechod; test dvoch firiem a všetko okolo vášho UI zostáva ručné. Čo tento zoznam nepokrýva: platby a webhooky, tajomstvá v histórii Gitu, bezpečnostné hlavičky na hostingu, zálohy. Sú dôležité, ale sú to iný checklist. Ak ste zdedili aplikáciu z Lovable alebo na Supabase a nie ste si istí, ktorými z týchto kontrol prechádza, od tohto auditu sa začína [záchrana projektu](https://madsalt.tech/sk/services/project-rescue/). [Prípadová štúdia sledovania času pre audítorskú firmu](https://madsalt.tech/sk/work/audit-firm-time-tracking/) ukazuje, ako vyzerajú kontroly rolí v produkčnej aplikácii. Našli ste dieru, ktorú tento zoznam míňa? Rád si ju vypočujem. Rád si vymením skúsenosti so zabezpečením aplikácií v Lovable a na Supabase. [Ozvite sa](https://madsalt.tech/sk/#contact)