Vibe coding: bezpečnostní rizika a 5 děr, které jsem ověřil

Jsem Denys, full-stack a AI inženýr. Opravuji aplikace postavené v Lovable, Bolt, Cursoru nebo Claude Code a většina z nich běží na Supabase. Tento článek shrnuje, co o bezpečnosti vibe codingu říká publikovaný výzkum a co jsem viděl, když jsem běžné chyby záměrně znovu postavil.

Jaká jsou bezpečnostní rizika vibe codingu?

Hlavním rizikem je porušené řízení přístupu: data, která může číst nebo měnit kterýkoli návštěvník, protože pravidlo, které ho mělo zastavit, chybí, je příliš volné nebo je obejité. Následuje injekce a slabá autentizace. Tři nezávislé studie ukazují stejným směrem:

Studie	Co se testovalo	Co se zjistilo
Deng, Fan a Meng, arXiv 2606.23130, červen 2026	200 nasazených aplikací postavených s Claude Code a Lovable, audit ručně i agenty	182 z 200 aplikací (91 %) mělo alespoň jednu zranitelnost; 65,77 % z 1 186 nálezů bylo Critical nebo High; porušené řízení přístupu bylo největší kategorií, ve 64 % aplikací
Escape, říjen 2025	5 600 veřejných aplikací z Lovable, Base44, Create.xyz a dalších, pasivní sken	Více než 2 000 zranitelností s vysokým dopadem, více než 400 odhalených tajemství, 175 případů odhalených osobních údajů; hlavní příčinou byla špatně nastavená oprávnění, zejména Supabase RLS
Veracode GenAI Code Security Report, 2025 a 2026	80 programovacích úloh zadaných více než 100 modelům	Jen 55 % úloh dalo v roce 2025 bezpečný kód; průměrná úspěšnost v roce 2026 byla 56 %, napříč velikostmi modelů i roky stejná

Studie měří různé věci, takže procenta nejdou sečíst do jednoho čísla. Společný mají tvar: kód funguje a mezery jsou na hranici důvěry.

Které díry jsem reprodukoval?

Na lokálním Supabase (CLI 2.109.1, Postgres 17.6, PostgREST 14.14) jsem založil jednu tabulku orders se třemi řádky fiktivních zákazníků. Pak jsem volal Data API tak, jak to dělá prohlížeč, s veřejným klíčem (publishable key), který nese každý frontend na Supabase, a měnil vždy jednu věc.

Nastavení	Co dostal veřejný klíč	Proč
Tabulka bez RLS	Všechny 3 řádky a vložení vrátilo 201 Created	Výchozí granty dovolují anon číst i zapisovat a nic řádky nefiltruje
RLS zapnuté, bez politiky	[], prázdný seznam	RLS bez politiky zamítne vše pro anon i authenticated
Politika using (true)	Všechny 3 řádky	Politika existuje, takže tabulka vypadá chráněně, ale povoluje každý řádek
View nad chráněnou tabulkou	Všechny 3 řádky	View běží s právy svého vlastníka, pokud nemá security_invoker = true; s ním vrátí []
Secret key ve frontendovém kódu	Všechny 3 řádky	Secret key se mapuje na service_role, která má BYPASSRLS

Druhý řádek je nebezpečný moment. RLS je zapnuté a aplikace ukazuje prázdný seznam, takže vypadá rozbitě. Nejrychlejší prompt, který to „opraví“, je politika, která povolí všechno, tedy třetí řádek. Tato smyčka, chyba a pak oprava, která rozšíří přístup, je vzorec, který v aplikacích z vibe codingu potkávám nejčastěji, a proto „RLS je zapnuté“ samo o sobě říká málo.

Proč kód psaný AI selhává v řízení přístupu?

Agent je odměňován za kód, který běží. Prázdný seznam nebo 401 vypadá jako chyba a oprava, která ho odstraní, je často ta, která přístup otevře. Studie z arXivu vede svých 1 186 nálezů k osmi opakujícím se způsobům selhání, seskupeným jako vady paměti, cíle a znalostí agentů, a zjistila, že lepší prompting počet děr snížil, ale neodstranil.

Druhým důvodem je architektura. Aplikace z Lovable nebo Bolt obvykle nemá vlastní backend: prohlížeč mluví s databází přímo přes Data API. Každé pravidlo, které chrání data zákazníků, musí žít v Postgresu jako granty, politiky a funkce, a nic z toho není vidět v náhledu aplikace, kde jste přihlášeni jako vlastník. Supabase tu mění jednu výchozí hodnotu: od 30. října 2026 se nové tabulky ve stávajících projektech už automaticky nezpřístupňují Data API. Na mém stacku odpověděla tabulka bez grantu 42501 permission denied s nápovědou, která jmenuje chybějící GRANT. To zastaví první řádek tabulky výše pro nové tabulky, ale ne zbylé čtyři, ani tabulky, které už existují.

Co dalšího se kazí mimo databázi?

Stejné studie uvádějí rizika, která s RLS nemají nic společného:

• Tajemství v bundlu. Escape našel více než 400 odhalených tajemství, včetně klíčů OpenAI a administrátorských klíčů plateb. Cokoli doručené do prohlížeče je veřejné.
• Ochrany tras jen v Reactu. Stránka, která přesměruje odhlášené uživatele, má za sebou pořád API, které odpoví komukoli.
• Limity požadavků, které se nikdy nespustí. Na hostovaném projektu Supabase, který jsem zkoumal, se počítadlo uložené v paměti edge funkce s každým požadavkem vynulovalo. Popsal jsem to ve svém checklistu zabezpečení Lovable aplikace.
• Staré knihovny. Escape napočítal 254 zranitelných instancí JavaScriptových knihoven ve veřejných assetech, často zděděných ze šablon.

Jak zkontrolovat aplikaci z vibe codingu?

1. Otevřete aplikaci, DevTools → Network a najděte požadavky na /rest/v1/. Zkopírujte jeden jako cURL, odstraňte hlavičku Authorization, nechte apikey a spusťte ho. Pokud se vrátí data, vrátí se komukoli.
2. Prohledejte sestavený JavaScript na sb_secret_ a service_role. Shoda je klíč, který je třeba vyměnit ještě dnes.
3. Spusťte bezplatnou Kontrolu zabezpečení Supabase. Čte katalog projektu a mezi svými 46 pravidly hlásí „RLS vypnuté u zpřístupněných tabulek“, „Politiky, které povolují každý řádek“, „Pohledy, které obcházejí RLS“ a „Výchozí oprávnění, která otevírají nové objekty API“: první čtyři řádky tabulky výše.
4. Testujte se dvěma uživateli ve dvou firmách, což je jediný test, který za vás skener neudělá. Jak ho dělám, je v checklistu pro Lovable a jak testovat Supabase RLS ukazuje metodu na produkční aplikaci s obrazovkou oprávnění.

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

Co tento test neukazuje

Moje reprodukce je jedna tabulka na lokálním stacku, postavená tak, aby ukázala každý mechanismus, ne sken skutečných aplikací. Čísla o rozšířenosti pocházejí ze tří studií, každá s vlastním vzorkem a metodou, odkazy výše. A čistý výsledek těchto pěti kontrol z aplikace bezpečnou neudělá: chyby v logice, například stráž, která pustí chybějící hodnotu, potřebují vlastní testy. Jedna taková je v poznámce o NULL, které přeskočilo kontrolu oprávnění.