Vibe coding: bezpečnostné riziká a 5 dier, ktoré som overil

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, 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, 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, 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.

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 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.
• 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. Čí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 a ako testovať Supabase RLS ukazuje metódu na produkčnej aplikácii s obrazovkou oprávnení.

curl 'https://<project>.supabase.co/rest/v1/orders?select=*' \
  -H 'apikey: <the publishable key from your page>'

Č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í.