--- title: "Vibe coding: bezpečnostné riziká a 5 dier, ktoré som overil" description: "Čo sa kazí v aplikáciách z vibe codingu: čísla z troch štúdií a päť dier v prístupe, ktoré som reprodukoval na lokálnom Supabase, a ako skontrolovať svoju." url: "https://madsalt.tech/sk/blog/vibe-coding-security-risks/" author: "Denys Zaichenko" language: "sk" published: 2026-10-24 --- # Vibe coding: bezpečnostné riziká a 5 dier, ktoré som overil TL;DR Kód, ktorý AI napíše, zvyčajne beží. Zlyháva to, kto sa dostane k dátam. V audite 200 nasadených aplikácií z vibe codingu z roku 2026 malo 91 % aspoň jednu zraniteľnosť a najväčšou skupinou bolo porušené riadenie prístupu. Päť dier v prístupe som reprodukoval na lokálnom Supabase: len s verejným kľúčom vydala tabuľka bez RLS, politika vždy pravdivá, view aj uniknutý secret key všetky 3 z 3 riadkov. Skontrolujte svoju aplikáciu najprv na toto. Som Denys, full-stack a AI inžinier. Opravujem aplikácie postavené v Lovable, Bolt, Cursore alebo Claude Code a väčšina z nich beží na Supabase. Tento článok zhŕňa, čo o bezpečnosti vibe codingu hovorí publikovaný výskum a čo som videl, keď som bežné chyby zámerne postavil znova. ## Aké sú bezpečnostné riziká vibe codingu? Hlavným rizikom je porušené riadenie prístupu: dáta, ktoré môže čítať alebo meniť ktorýkoľvek návštevník, pretože pravidlo, ktoré ho malo zastaviť, chýba, je príliš voľné alebo je obídené. Nasleduje injekcia a slabá autentifikácia. Tri nezávislé štúdie ukazujú rovnakým smerom: | Štúdia | Čo sa testovalo | Čo sa zistilo | | --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [Deng, Fan a Meng, arXiv 2606.23130](https://arxiv.org/abs/2606.23130), jún 2026 | 200 nasadených aplikácií postavených s Claude Code a Lovable, audit ručne aj agentmi | 182 z 200 aplikácií (91 %) malo aspoň jednu zraniteľnosť; 65,77 % z 1 186 nálezov bolo Critical alebo High; porušené riadenie prístupu bolo najväčšou kategóriou, v 64 % aplikácií | | [Escape](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/), október 2025 | 5 600 verejných aplikácií z Lovable, Base44, Create.xyz a ďalších, pasívny sken | Viac než 2 000 zraniteľností s vysokým dopadom, viac než 400 odhalených tajomstiev, 175 prípadov odhalených osobných údajov; hlavnou príčinou boli zle nastavené oprávnenia, najmä Supabase RLS | | [Veracode GenAI Code Security Report](https://www.veracode.com/resources/analyst-reports/2026-genai-code-security-report/), 2025 a 2026 | 80 programovacích úloh zadaných viac než 100 modelom | Len 55 % úloh dalo v roku 2025 bezpečný kód; priemerná úspešnosť v roku 2026 bola 56 %, naprieč veľkosťami modelov aj rokmi rovnaká | Štúdie merajú rôzne veci, takže percentá sa nedajú sčítať do jedného čísla. Spoločný majú tvar: kód funguje a medzery sú na hranici dôvery. ## Ktoré diery som reprodukoval? Na lokálnom Supabase (CLI 2.109.1, Postgres 17.6, PostgREST 14.14) som založil jednu tabuľku `orders` s tromi riadkami fiktívnych zákazníkov. Potom som volal Data API tak, ako to robí prehliadač, s verejným kľúčom (publishable key), ktorý nesie každý frontend na Supabase, a menil vždy jednu vec. ![Čo dostal jeden verejný kľúč z jednej tabuľky. Lokálny Supabase, 3 riadky fiktívnych objednávok, vždy jedna požiadavka. Tabuľka bez RLS: Publishable key → orders, RLS vypnuté → 3 z 3 riadkov; RLS zapnuté, zatiaľ bez politiky: Publishable key → orders, RLS zapnuté → 0 riadkov; Politika using (true): Publishable key → using (true) → 3 z 3 riadkov; View bez security_invoker: Publishable key → view order_summary → 3 z 3 riadkov; Secret key v kóde prehliadača: Secret key → BYPASSRLS → 3 z 3 riadkov.](https://madsalt.tech/charts/sk/vibe-coding-security-risks.svg) *Obrázok 1. Moja reprodukcia na lokálnom Supabase (Postgres 17.6, PostgREST 14.14), 23. októbra 2026.* | Nastavenie | Čo dostal verejný kľúč | Prečo | | ------------------------------- | ------------------------------------------------ | --------------------------------------------------------------------------------------------- | | Tabuľka bez RLS | Všetky 3 riadky a vloženie vrátilo `201 Created` | Predvolené granty dovoľujú `anon` čítať aj zapisovať a nič riadky nefiltruje | | RLS zapnuté, bez politiky | `[]`, prázdny zoznam | RLS bez politiky zamietne všetko pre `anon` aj `authenticated` | | Politika `using (true)` | Všetky 3 riadky | Politika existuje, takže tabuľka vyzerá chránene, ale povoľuje každý riadok | | View nad chránenou tabuľkou | Všetky 3 riadky | View beží s právami svojho vlastníka, pokiaľ nemá `security_invoker = true`; s ním vráti `[]` | | Secret key vo frontendovom kóde | Všetky 3 riadky | Secret key sa mapuje na `service_role`, ktorá má `BYPASSRLS` | Druhý riadok je nebezpečný moment. RLS je zapnuté a aplikácia ukazuje prázdny zoznam, takže vyzerá pokazene. Najrýchlejší prompt, ktorý to „opraví“, je politika, ktorá povolí všetko, teda tretí riadok. Táto slučka, chyba a potom oprava, ktorá rozšíri prístup, je vzorec, ktorý v aplikáciách z vibe codingu stretávam najčastejšie, a preto „RLS je zapnuté“ samo osebe hovorí málo. ## Prečo kód písaný AI zlyháva v riadení prístupu? Agent je odmeňovaný za kód, ktorý beží. Prázdny zoznam alebo `401` vyzerá ako chyba a oprava, ktorá ho odstráni, je často tá, ktorá prístup otvorí. Štúdia z arXivu vedie svojich 1 186 nálezov k ôsmim opakujúcim sa spôsobom zlyhania, zoskupeným ako chyby pamäte, cieľa a znalostí agentov, a zistila, že lepší prompting počet dier znížil, ale neodstránil. Druhým dôvodom je architektúra. Aplikácia z Lovable alebo Bolt zvyčajne nemá vlastný backend: prehliadač komunikuje s databázou priamo cez Data API. Každé pravidlo, ktoré chráni dáta zákazníkov, musí žiť v Postgrese ako granty, politiky a funkcie, a nič z toho nie je vidno v náhľade aplikácie, kde ste prihlásení ako vlastník. Supabase tu mení jednu predvolenú hodnotu: od [30. októbra 2026](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) sa nové tabuľky v existujúcich projektoch už automaticky nesprístupňujú Data API. Na mojom stacku odpovedala tabuľka bez grantu `42501 permission denied` s nápovedou, ktorá menuje chýbajúci `GRANT`. To zastaví prvý riadok tabuľky vyššie pre nové tabuľky, ale nie ostatné štyri, ani tabuľky, ktoré už existujú. ## Čo ďalšie sa kazí mimo databázy? Rovnaké štúdie uvádzajú riziká, ktoré s RLS nemajú nič spoločné: - **Tajomstvá v bundli.** Escape našiel viac než 400 odhalených tajomstiev, vrátane kľúčov OpenAI a administrátorských kľúčov platieb. Čokoľvek doručené do prehliadača je verejné. - **Ochrany trás len v Reacte.** Stránka, ktorá presmeruje odhlásených používateľov, má za sebou stále API, ktoré odpovie komukoľvek. - **Limity požiadaviek, ktoré sa nikdy nespustia.** Na hostovanom projekte Supabase, ktorý som skúmal, sa počítadlo uložené v pamäti edge funkcie s každou požiadavkou vynulovalo. Opísal som to vo svojom [checkliste bezpečnosti aplikácie z Lovable](https://madsalt.tech/sk/blog/lovable-app-security-checklist/). - **Staré knižnice.** Escape napočítal 254 zraniteľných inštancií JavaScriptových knižníc vo verejných assetoch, často zdedených zo šablón. ## Ako skontrolovať aplikáciu z vibe codingu? 1. Otvorte aplikáciu, DevTools → Network a nájdite požiadavky na `/rest/v1/`. Skopírujte jednu ako cURL, odstráňte hlavičku `Authorization`, nechajte `apikey` a spustite ju. Ak sa vrátia dáta, vrátia sa komukoľvek. 2. Prehľadajte zostavený JavaScript na `sb_secret_` a `service_role`. Zhoda je kľúč, ktorý treba vymeniť ešte dnes. 3. Spustite bezplatnú [Kontrolu zabezpečenia Supabase](https://madsalt.tech/sk/tools/supabase-security-check/). Číta katalóg projektu a medzi svojimi 46 pravidlami hlási „RLS vypnuté pri sprístupnených tabuľkách“, „Politiky, ktoré povoľujú každý riadok“, „Pohľady, ktoré obchádzajú RLS“ a „Predvolené oprávnenia, ktoré otvárajú nové objekty pre API“: prvé štyri riadky tabuľky vyššie. 4. Testujte s dvoma používateľmi v dvoch firmách, čo je jediný test, ktorý za vás skener neurobí. Ako ho robím, je v [checkliste pre Lovable](https://madsalt.tech/sk/blog/lovable-app-security-checklist/) a [ako testovať Supabase RLS](https://madsalt.tech/sk/blog/how-to-test-supabase-rls/) ukazuje metódu na produkčnej aplikácii s obrazovkou oprávnení. ```bash curl 'https://.supabase.co/rest/v1/orders?select=*' \ -H 'apikey: ' ``` ## Čo tento test neukazuje Moja reprodukcia je jedna tabuľka na lokálnom stacku, postavená tak, aby ukázala každý mechanizmus, nie sken skutočných aplikácií. Čísla o rozšírenosti pochádzajú z troch štúdií, každá s vlastnou vzorkou a metódou, odkazy vyššie. A čistý výsledok týchto piatich kontrol z aplikácie bezpečnú neurobí: chyby v logike, napríklad stráž, ktorá pustí chýbajúcu hodnotu, potrebujú vlastné testy. Jedna taká je v poznámke o [NULL, ktoré preskočilo kontrolu oprávnení](https://madsalt.tech/sk/notes/plpgsql-if-not-null-fails-open/). Postavili ste aplikáciu s AI nástrojom? Rád porovnám skúsenosti, čo kontrolovať ako prvé. Bez ponuky. [Ozvite sa](https://madsalt.tech/sk/#contact)