Vibe coding, stavění aplikací pomocí konverzace s AI, může usnadnit prototypování. Funkční ukázka ale sama neprokazuje bezpečnost ani udržitelnost. Pro přechod do provozu potřebujete rozumět datům, oprávněním a způsobu obnovy aplikace.
Nejsem proti vibe codingu. Jsem proti představě, že se dá přeskočit pochopení. Tenhle článek je seznam chyb, které vídám nejčastěji, u klientů, kteří přišli s „hotovou“ aplikací, i u účastníků kurzů.
Funkční prototyp není důkaz bezpečnosti. Pozor na klíče v kódu, chybějící serverovou validaci, otevřená oprávnění, žádné verzování, slepé přebírání změn a neověřené zálohy. Bezpečnostní studie níže popisují konkrétní testy a datasety; nelze z nich vypočítat pravděpodobnost, že libovolná AI aplikace je zranitelná. Základy se dají ukázat na kurzu, bezpečný provoz vyžaduje průběžné ověřování.
Proč o tom psát právě teď
Veracode ve studii z roku 2025 testoval přes 100 modelů ve čtyřech programovacích jazycích. Bezpečnostními testy neprošlo 45 % vzorků kódu v tomto testu. Nejde o podíl všech AI aplikací ani o stav každého modelu v roce 2026.
GitGuardian v reportu 2026 uvádí za rok 2025 únik tajných údajů v 3,2 % commitů asistovaných Claude Code, oproti 1,5 % všech veřejných GitHub commitů v porovnávaném základu. Druhá skupina není souborem výhradně lidského kódu. Pozorovaná souvislost sama neprokazuje, že únik způsobil nástroj; o přijetí a zveřejnění změn rozhodují lidé.
Obě zjištění jsou důvodem ke kontrole konkrétní aplikace, nikoli k univerzálnímu procentnímu odhadu rizika. Následujících sedm chyb ukazuje, co ověřovat.
Sedm chyb a jak jim předejít
- Klíče v kódu tajné klíče držte na serveru, zveřejněný klíč zneplatněte.
- Validace jen v prohlížeči vstupy ověřujte na serveru.
- Otevřená databáze zapněte RLS nebo Security Rules a otestujte přístup.
- Žádné verzování používejte Git a ověřte postup návratu.
- Slepé přijímání výstupů čtěte diff a chybovou hlášku.
- Prototyp rovnou v produkci otestujte oprávnění, limity a obnovu ze zálohy.
- Nikdo to neumí opravit mějte přehled, co kde běží a kdo drží přístupy.
Chyba 1: API klíče a hesla přímo v kódu
Pokud do zdrojového kódu vložíte tajný API klíč, může se dostat do repozitáře nebo veřejného balíčku pro prohlížeč. Rozsah zneužití závisí na jeho oprávněních: může umožnit placené API požadavky nebo přístup k datům.
Jak správně: tajné klíče uchovávejte na serveru ve správci tajných údajů nebo vhodně chráněných proměnných prostředí. Proměnná vložená do veřejného browserového balíčku tajná není. Zveřejněný klíč zneplatněte, nahraďte a zkontrolujte jeho použití; samotné smazání ze souboru nestačí.
Chyba 2: důvěra klientovi, žádná validace na serveru
Kontrola formuláře v prohlížeči pomáhá uživateli, ale nenahrazuje kontrolu na serveru. Požadavek lze poslat i mimo formulář, s upravenou cenou, rolí nebo identifikátorem záznamu.
Jak správně: vstupy validujte na důvěryhodné serverové straně. Cenu vypočtěte podle serverového katalogu či pravidel, ne podle hodnoty zaslané klientem. Katalog může být databáze i serverová konstanta, jako v ukázce níže. U každé chráněné operace ověřte oprávnění k danému záznamu.
Praktický příklad: Neplatné množství nezmění data
ověřený modelový test
| Část testu | Zachycená hodnota |
|---|---|
| Vstup | sku: MUG-01; quantity: -2; unitPrice: 1 |
| Serverové pravidlo | quantity je celé číslo 1 až 20 |
| Odpověď funkce | status: 422 |
| Chyba | quantity: integer 1..20 |
| Počet objednávek po požadavku | 0 |
Izolovaná ukázka validace; platná větev používá serverovou konstantu unitPrice: 590, nikoli cenu ze vstupu.
Chyba 3: databáze otevřená světu
Databázová pravidla musí odpovídat způsobu přístupu. U Supabase jde mimo jiné o PostgreSQL Row Level Security; Firebase používá pro podporované služby vlastní Security Rules. Tyto mechanismy nejsou zaměnitelné.
Jak správně: u Supabase povolte RLS na tabulkách vystavených přes API a otestujte přístup anonymního uživatele, vlastníka a jiného účtu. U Firebase postupujte podle Security Rules. Zvlášť kontrolujte privilegovaný serverový přístup; klientská pravidla nemusí chránit operace administrátorského SDK.
Chyba 4: žádné verzování, „včera to fungovalo“
Přepisování jediné živé verze bez historie ztěžuje zjištění, co změnu způsobilo, a návrat k funkčnímu stavu. Počet předchozích úprav sám neurčuje, kdy se chyba objeví.
Jak správně: používejte Git, ukládejte srozumitelné změny a ověřte postup návratu. Historie zdrojového kódu nenahrazuje zálohu databáze ani obnovu nasazené služby. Před změnou databázového schématu řešte také kompatibilitu při návratu.
Praktický příklad: Obnovte konkrétní řádek z historie
ověřený Git příklad
| Krok | Záznam |
|---|---|
| 0f19e38 | Working enquiry button |
| 3378708 | Accidentally empty label |
| Obnova | git restore --source=HEAD~1 -- button.txt |
| Výsledek | buttonLabel=Odeslat poptavku |
Obnoven pracovní soubor; historie commitů zůstala. Lokální Git nenahrazuje externí zálohu.
Chyba 5: slepé přijímání výstupů a „regeneration loop“
Dvě podoby téže chyby: přijmout nezkontrolovaný kód a opakovaně žádat další opravu bez zjištění příčiny. U nové závislosti ověřte skutečný balíček, jeho původ a potřebnost. U chyby uchovejte reprodukční postup a porovnejte změny; počet regenerací není měřítko kvality.
Jak správně: malé kroky, po každém přečíst diff (aspoň zhruba pochopit, CO se změnilo), při chybě nejdřív přečíst chybovou hlášku a poslat ji AI s kontextem, ne „nefunguje to, oprav to“.
Slepé přijímání a kontrolovaný postup
- Slepé přijímání
- nová závislost bez ověření balíčku
- nezkontrolovaný kód
- opakované „oprav to“ bez zjištění příčiny
- Kontrolovaný postup
- malé kroky
- po každém přečtený diff
- chybová hláška s kontextem pro AI
Chyba 6: nasazení bez rozmyslu, prototyp rovnou do produkce
Před veřejným nasazením ověřte limity zneužití, náklady API, zálohy a oddělení testovacích dat. Veřejná adresa administrace sama není bezpečnostní chyba; zásadní je, zda server brání neoprávněným operacím.
Jak správně: otestujte přístup nepřihlášeného i přihlášeného uživatele bez potřebné role, limity zneužití a obnovu ze zálohy. Přihlášení samo nenahrazuje autorizaci. Zaznamenejte výsledky a odpovědnost za provoz; délka kontroly závisí na aplikaci.
Chyba 7: neschopnost aplikaci opravit, když se rozbije
Výpadek platební brány nebo změna externího API může narušit proces firmy. Určete, kdo zjistí příčinu, kde najde logy a jak zajistí náhradní postup, pokud oprava potrvá.
Jak správně: udržujte přehled, co kde běží, kudy tečou data a kdo drží přístupy. Ověřte, že odpovědný člověk dokáže podle dokumentace najít chybu, obnovit službu nebo přivolat potřebnou pomoc.
Znamená to „nedělejte to sami“? Ne.
Pro začátek zvolte malý interní nástroj nebo prototyp s testovacími daty. Vhodnost AI vývoje závisí na složitosti, riziku a dostupné kontrole. Nelze slíbit, že libovolná firma nahradí zakázkový vývoj jedním odpolednem.
Na kurzu vibe codingu lze postup projít na konkrétní aplikaci; aktuální rozsah najdete u nabídky. Pro firmy nabízím školení na míru. Kurz ani ukázková aplikace nejsou certifikací bezpečnosti. Pokud už nástroj provozujete, domluvme kontrolu podle jeho funkcí a dat.
Shrnutí
Vibe coding může urychlit prototypování. Bezpečnost ale posuzujte podle konkrétní architektury, oprávnění, práce s tajnými údaji a výsledků kontrol. Studie Veracode a GitGuardian mají vlastní vzorky a metodiku; jejich čísla nelze přenést na libovolnou aplikaci ani zaměnit za srovnání veškerého AI a čistě lidského kódu. Sedm oblastí výše berte jako začátek pravidelné kontroly, ne jako příslib bezpečného provozu po jednom odpoledni.
Zdroje a odkazy
Primární zdroje ověřeny 2. října 2026. Čísla popisují historické testy a datasety uvedené výše.
- Veracode: 2025 GenAI Code Security Report, 45 % neúspěšných vzorků v konkrétním testu
- GitGuardian: State of Secrets Sprawl 2026, Claude Code asistované commity versus všechny veřejné GitHub commity