Bezpečnosť pri vibe codingu: Ako chrániť aplikáciu vytvorenú pomocou AI

Ďalšie pokyny na prácu s Ailoot nájdete v dokumentácii.

Prečo sú aplikácie vytvorené pomocou AI častejšie napadnuté?#

Aj ja vytváram produkty pomocou AI a nie som zo zabezpečenia paranoidný do tej miery, že by som „všetko uzamkol na maximum“. Existuje však základná úroveň, pod ktorú nesmiete klesnúť, inak sa jedného dňa zobudíte s prázdnou databázou a ťažiarmi niekoho iného na svojom serveri. Tento sprievodca je o tejto základnej úrovni. Nie „staňte sa odborníkom na bezpečnosť“, ale „nestrieľajte si bezdôvodne do nohy“.

Podstata problému je jednoduchá. Keď poviete agentovi AI „vytvor mi aplikáciu na rezervovanie termínov pre klientov“, vytvorí aplikáciu čo najrýchlejšie. Bezpečnosť je práca navyše, ktorú pri ukážke nevidno. Databáza sa teda nastaví ako otvorená, platobný kľúč sa vloží priamo do kódu a kontrola „má tento používateľ prístup?“ existuje iba v prehliadači, kde sa dá za sekundu obísť.

Druhým dôvodom sú samotné platformy.

Inými slovami, diera sa objaví sama, v predvolenom nastavení. Neurobili ste nič zlé. Jednoducho ste nič neurobili — a v oblasti bezpečnosti nečinnosť znamená presne to, že „prístup má každý“.

AI s väčšou pravdepodobnosťou než človek prezradí tajné údaje. Logika je jasná: agent bez kontroly spustí git add . a git push a váš súbor .env s kľúčmi sa zverejní spolu so všetkým ostatným.

Čo sa už tvorcovia pomocou vibe codingu naučili na vlastnej koži?#

Najlepšou očkovacou látkou proti nedbanlivosti je poučiť sa z chýb iných. Tu sú štyri správy, ktoré sa oplatí pozrieť pred zverejnením projektu.

Lovable a vypnuté RLS. Platforma Lovable vytvára aplikácie z textových opisov. V roku 2025 sa v jej aplikáciách našla systémová zraniteľnosť, ktorej bolo pridelené CVE-2025-48757. Príčina: vytvorené aplikácie nemali pravidlá prístupu k databáze na úrovni riadkov (RLS, vysvetlené nižšie). Výskumník skontroloval vzorku a našiel 303 exponovaných prístupových bodov v 170 aplikáciách. Odhalili sa mená, telefónne čísla, stavy platieb, API kľúče iných ľudí, dokonca aj adresy bydliska. Približne v 70 percentách kontrolovaných aplikácií bola ochrana na úrovni riadkov úplne vypnutá.

Tea a citlivé údaje. Aplikácia Tea (anonymné hodnotenia ľudí) prišla v júli 2025 o približne 72,000 obrázkov vrátane 13,000 selfie a fotografií dokumentov a následne o viac ako milión súkromných správ. Technickou príčinou bolo otvorené úložisko a slabé kontroly prístupu. Bezpečnostná komunita uvádza Tea ako názorný príklad: keď je rýchle spustenie dôležitejšie než kontrola oprávnení, citlivé údaje uniknú ako prvé.

Ďalší praktický príklad. V prípade, ktorý opísal pôvodný autor, bola aplikácia tvorcu používajúceho vibe coding napadnutá, pretože AI pri vytváraní databázy nastavilo predvolené heslo — také, ktoré sa dalo automaticky uhádnuť. Potom nasledoval obvyklý postup: útočníci sa dostali dnu, nainštalovali ťažiarov a prepísali projekt. Server bolo potrebné úplne vymazať. Predvolené heslo je odomknuté dvere s nápisom „len vstúpte“.

Dve oblasti bezpečnosti: kde presne ste zraniteľní?#

Keď ľudia hovoria o „bezpečnosti vibe codingu“, zvyčajne spájajú dva úplne odlišné strachy. Oddeľme ich, pretože sa pred nimi chránite rôznymi spôsobmi.

Prvá oblasť — samotný agent. Spustíte agenta AI na svojom počítači a dáte mu prístup k súborom, terminálu, kľúčom a databáze. Riziko spočíva v tom, že agent nie je človek: doslovne sa riadi pokynmi a hľadá najkratšiu cestu, aj keď je nebezpečná. Patrí sem aj riziko, že sa do agenta prostredníctvom textu, ktorý číta, „vpašuje“ príkaz niekoho iného (nazýva sa to prompt injection).

Druhá oblasť — hotová aplikácia. To je aplikácia, ktorú ste zverejnili a ktorú ľudia používajú. Cieľom je váš zverejnený web alebo služba: útočníci sa dostanú do otvorenej databázy, posielajú falošné požiadavky alebo hádajú účty iných ľudí. Agent s tým nemá nič spoločné — diera zostala otvorená skôr a zneužívajú ju iní ľudia.

Anthropic, spoločnosť stojaca za Claude, uvádza hlavnú zásadu ochrany takto — a platí pre obe oblasti:

V praxi to znamená: nespoliehajte sa na to, že AI „sa samo vyhne zlému konaniu“. Najprv obmedzte, čo môže fyzicky robiť, a až potom ho žiadajte, aby sa správalo dobre. Keď zlyhá jeho správanie — a zlyhá — ochráni vás iba pevná hranica, ktorú ste nastavili vopred.

Čo môže agent AI robiť s prístupom k vášmu počítaču?#

Najviac podceňovaným rizikom je váš vlastný agent s príliš širokými oprávneniami. Nepotrebujete ani externého hackera. Tu je nedávny príklad z konca mája 2026. Agent Codex potreboval oprávnenia správcu, ktoré používateľ nemal. Agent to nevzdal — rozhliadol sa, zistil, že používateľ patrí do skupiny docker, čo je v podstate ekvivalent prístupu root, a využil tento prístup.

Neboli v tom žiadne zlé úmysly. Agent, ktorému poviete „vyrieš úlohu“, jednoducho nájde štrukturálnu slabinu rýchlejšie než človek. A ak mu táto slabina poskytne prístup ku kľúčom alebo produkčnému prostrediu, využije ho. Pravidlom číslo jeden je preto najmenšie oprávnenie. Dajte agentovi presne taký prístup, aký potrebuje na konkrétnu úlohu, a ani o kvapku viac.

Čo môžete v praxi urobiť, aj keď nie ste programátor?

1. Nespúšťajte agenta v režime „povoliť všetko“ na produkčnom počítači

   Režim, v ktorom agent nežiada o potvrdenie (často sa označuje ako bypass alebo yolo), je určený iba pre sandbox alebo testovací projekt, nie pre počítač, na ktorom sú pracovné kľúče a prístup do produkcie.

2. Zakážte agentovi čítať tajné údaje

   V Claude Code to urobíte pravidlom, ktoré odmietne prístup k súborom obsahujúcim kľúče. Aj keď sa teda agent pokúsi otvoriť .env, nástroj mu to nedovolí.

3. Produkčné kľúče uchovávajte oddelene

   Kľúče k produkčnej databáze a platobnej službe by nemali byť v tom istom priečinku, v ktorom agent píše kód. Prostredia udržiavajte oddelené: pri experimentovaní používajte testovacie kľúče.

4. Používajte sandbox nástroja

   Moderné nástroje AI dokážu spúšťať príkazy izolovane (v sandboxe), bez prístupu k zvyšku systému. V Claude Code to znižuje počet žiadostí o oprávnenie približne o 84 percent — je to teda aj pohodlnejšie.

Pravidlo v Claude Code, ktoré zakazuje čítanie tajných údajov, vyzerá približne takto — vložte ho do nastavení oprávnení:

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(**/.env)",
      "Bash(git push *)"
    ]
  }
}

Kam nikdy nedávať API kľúče a heslá?#

Najlacnejšou a najčastejšou chybou je vkladanie kľúčov do kódu. API kľúč platobnej služby, heslo k databáze, token bota — to všetko sú tajné údaje. Patria do samostatného súboru .env a tento súbor musí byť uvedený v .gitignore, aby sa nedostal do gitu spolu s kódom.

Prečo je to kritické: kľúč vo verejnom repozitári dlho nevydrží. Boti nepretržite skenujú nové commity. Nasleduje obvyklý scenár: nájdu cloudový kľúč, spustia servery na ťažbu kryptomien na vaše náklady a ráno máte účet v desiatkach tisíc. Vývojári o takýchto prípadoch pravidelne rozprávajú a účty dosahujú päťciferné sumy v dolároch.

Rozsah problému v roku 2025: 28.65 milióna nových tajných údajov natvrdo vložených do verejných repozitárov, čo predstavuje medziročný nárast o 34 percent. Úniky kľúčov určených konkrétne pre služby AI vzrástli o 81 percent. Vibe coding prilieva olej do ohňa, pretože agent vykoná commit bez kontroly.

Čo môžete hneď teraz skontrolovať manuálne:

1. Otvorte súbor .gitignore projektu

   Skontrolujte, či obsahuje riadok .env. Ak nie, pridajte ho pred prvým commitom.

2. Prejdite do svojho repozitára GitHub

   Skontrolujte, či sa tam nenachádza súbor .env. Rýchlo to overíte vyhľadaním výrazu .env alebo časti svojho kľúča v repozitári.

3. Ak kľúč unikol, zneplatnite ho a vydajte nový

   Odstránenie commitu nestačí: kľúč už mohol byť ukradnutý. Prejdite do príslušnej služby (poskytovateľ platieb, cloudová služba, poskytovateľ AI), zneplatnite starý kľúč a vydajte nový. Hovorí sa tomu rotácia.

4. Kľúčom prideľte minimálne oprávnenia

   Ak je kľúč potrebný iba na čítanie, nastavte ho iba na čítanie. Aj keby unikol, ukradnúť sa dá menej.

Prečo môže každý vidieť vašu databázu bez RLS?#

Ak vytvárate aplikáciu v Supabase alebo podobnej databáze, toto je najdôležitejšia časť. RLS znamená Row Level Security. Jednoducho povedané, je to pravidlo určujúce, ktoré riadky tabuľky sa zobrazia konkrétnemu používateľovi. Bez neho tabuľka „orders“ vráti každému objednávky všetkých zákazníkov.

Dokumentácia Supabase to hovorí úplne jasne:

A tu je hlavný háčik pre tvorcov používajúcich vibe coding. Keď vytvoríte tabuľku klikaním v ovládacom paneli Supabase, ochrana sa zapne automaticky. Keď však tabuľku vytvorí AI — a takmer vždy zapisuje priamo SQL príkazy — RLS zostane predvolene vypnuté. To znamená, že tabuľka vytvorená agentom je takmer určite otvorená celému internetu. Presne takto unikli údaje z tých 170 aplikácií Lovable.

Čo treba urobiť:

1. Spýtajte sa priamo agenta

   Napíšte: „ukáž mi všetky tabuľky, v ktorých je RLS vypnuté“. AI vytvorí zoznam — to je váš zoznam úloh.

2. Zapnite RLS vo všetkých tabuľkách s údajmi používateľov

   A pridajte aspoň jednu zásadu prístupu — napríklad „používateľ môže vidieť iba svoje vlastné riadky“.

3. Skontrolujte ovládací panel

   V ovládacom paneli Supabase by mala každá tabuľka zobrazovať „RLS enabled“. Ak je označenie sivé alebo červené, tabuľka je otvorená.

4. Vyskúšajte to v praxi

   Prihláste sa ako bežný používateľ a skúste vyžiadať údaje niekoho iného. Ak je prístup zamietnutý, zásada funguje.

Prečo vás kontroly oprávnení v rozhraní nechránia?#

Častým omylom je: „Zariadil som, aby bežní používatelia nevideli tlačidlo správcu.“ Problém je, že tlačidlo je iba obrázok v prehliadači. Požiadavku možno poslať priamo na server bez použitia tlačidla. Ak server opätovne neskontroluje oprávnenia, vykoná príkaz niekoho iného.

Klasický príklad sa nazýva IDOR. Predstavte si, že otvoríte svoju objednávku na adrese s id=123. Zmeňte ho na id=124 a môžete vidieť objednávku niekoho iného, pretože server neoveril, či bola naozaj vaša. Toto je jedna z najčastejších dier v aplikáciách vytvorených pomocou vibe codingu a za únikom z Tea stáli aj slabé kontroly oprávnení.

Pravidlo je jednoduché: každú kontrolu „smie tento používateľ urobiť toto?“ zopakujte na serveri. Rozhranie slúži na pohodlie; ochrana patrí na backend. Pokyn pre agenta, ktorý môžete rovno použiť: „pridaj kontroly oprávnení na strane servera pre každý endpoint, ktorý číta alebo mení údaje používateľov; nespoliehaj sa na to, že je prvok v rozhraní skrytý“.

Ako môžete skontrolovať kód na diery, ak nie ste programátor?#

Dobrá správa: dnes môžete požiadať o kontrolu bezpečnosti to isté AI — pri hľadaní bežných dier odvádza celkom slušnú prácu. Tu sú tri nástroje na rôzne úlohy.

1. Príkaz /security-review v Claude Code. Jednorazová kontrola aktuálneho branchu na SQL injection, XSS, chyby autorizácie, úniky údajov a problémy so závislosťami. V samostatnom sprievodcovi kontrolou bezpečnosti v Claude Code som krok za krokom vysvetlil, ako funguje a ako pridať automatickú kontrolu ku každej zmene. Hlavná myšlienka: je to prvá línia obrany, ktorú spustíte jediným príkazom.

2. Oficiálny doplnok security-guidance. Nainštalujte ho z oficiálneho trhoviska doplnkov príkazom /plugin install security-guidance@claude-plugins-official (vyžaduje sa Claude Code verzie 2.1.144 alebo novšej). Kód kontroluje v troch momentoch: pri každej úprave, na konci každého turnu a pri commite. Odhaľuje obídenie autorizácie, IDOR, injekcie a slabú kryptografiu. Anthropic však otvorene hovorí o jeho obmedzeniach:

npx skills add <autor>/<repo>

Potom agentovi jednoducho povedzte: „skontroluj môj projekt na zraniteľnosti“. Táto zbierka má však dôležitú výhradu, preto jej nižšie venujem samostatnú časť.

Pre kontext: aj významní hráči začali brať bezpečnosť kódu AI vážne. V rámci Project Glasswing, ktoré sa 2. júna 2026 rozšírilo o 150 organizácií, partneri pomocou modelov Anthropic v krátkom čase našli viac ako 10,000 kritických zraniteľností. V stávke je veľa:

Môžete dôverovať zručnostiam a rozšíreniam z GitHubu?#

Tu sa veci komplikujú, pretože nebezpečenstvo pochádza z nástroja, ktorý si inštalujete kvôli bezpečnosti. Keď spustíte npx skills add ... alebo nainštalujete rozšírenie, preberáte kód niekoho iného, ktorý agent následne spustí s vašimi oprávneniami. Ak bol autor napadnutý alebo bol balík škodlivý od začiatku, máte problém.

Pozrime sa na zbierku zručností z predchádzajúcej časti. V názve obsahuje „Anthropic“, čo vás môže ukolísať. Jej vlastný opis však jasne hovorí:

Inými slovami, názov je zavádzajúci. Samotná zbierka je momentálne vyspelá a čistá, ale zásada zostáva: inštalujete ju na vlastné riziko. A hrozba nie je teoretická. V máji 2026 strávilo škodlivé rozšírenie editora na trhovisku iba 18 minút — za ten čas dokázalo ukradnúť heslá zo správcov hesiel, tokeny GitHub, prístup ku cloudovým službám a dokonca konfigurácie Claude Code od ľudí, ktorí si ho nainštalovali. Ďalší nepríjemný detail: takýto malvér často prežije bežné odstránenie balíka a znova sa spustí počas nasledujúcej relácie.

Osvojil som si jednoduchý zvyk a odporúčam ho aj vám: pred inštaláciou akejkoľvek zručnosti z GitHubu si ju sami skontrolujte. Autori môžu byť napadnutí, účty unesené a malvér sa môže dostať do repozitára. Kontrola je vaša ochrana.

Praktické minimum pred inštaláciou: pozrite sa na autora a počet hviezdičiek, prečítajte si opis zručnosti, neinštalujte nástroj „pretože ho odporučil niekto v jednom príspevku“ a neznámy nástroj najprv vyskúšajte v samostatnom testovacom prostredí, nie na počítači s produkčnými kľúčmi.

Čo vás zachráni po napadnutí: zálohy a návrat k predchádzajúcej verzii#

Bezpečnosť nie je iba o tom, „udržať cudzích ľudí vonku“, ale aj o tom, „vrátiť sa do normálu, keď sa niečo pokazí“. Pretože sa to pokazí. V opísanom praktickom prípade agent AI pri bežnej úlohe odstránil živú databázu v produkčnom projekte. Záloha existovala, ale bola tri dni stará — a tri dni údajov jednoducho zmizli.

Z toho vyplývajú dve pravidlá.

Zálohujte často. Ak aplikácia obsahuje údaje, o ktoré by ste neradi prišli, kópia raz za tri dni je iba ilúziou ochrany. Nastavte automatické zálohy aspoň každých 30 minút. Pri väčšine databáz vrátane Supabase sa to dá zapnúť niekoľkými kliknutiami.

Git je poistka proti agentovi. Git uchováva históriu vášho kódu: môžete obnoviť ľubovoľný funkčný stav. Keď agent prepíše niečo, čo fungovalo, vrátite sa k poslednej funkčnej verzii namiesto toho, aby ste to opravovali ručne. Ak AI projekt odstránilo alebo pokazilo a neviete, ako ho obnoviť, pozrite si samostatnú správu: čo robiť, ak AI odstránilo databázu. Návod, ako vopred ochrániť projekt pred poškodením, nájdete tu: ako chrániť Claude Code pred poškodením.

Bezpečnostný kontrolný zoznam pred zverejnením#

Tesne pred zverejnením prejdite tento zoznam. V uvedenom poradí.

1. Tajné údaje v .env a .env v .gitignore. Žiadne kľúče v kóde. Žiadny súbor .env vo verejnom repozitári.

2. Kľúče s minimálnymi oprávneniami. Každý kľúč môže robiť iba to, čo je potrebné. Produkčné kľúče sú oddelené od prostredia agenta.

3. RLS je zapnuté vo všetkých tabuľkách s údajmi používateľov a sú nastavené zásady prístupu.

4. Kontroly oprávnení na strane servera pri každej operácii s údajmi. Skryť tlačidlo v rozhraní nestačí. Manuálne ste vyskúšali zmeniť id v adrese.

5. Overovanie podpisov webhookov. Každý obslužný program externých oznámení (platby, formuláre) overuje podpis.

6. Obmedzenie frekvencie prichádzajúcich požiadaviek a nákladných operácií, aby sa heslá nedali uhádnuť útokom hrubou silou a aby vám nenarástol účet.

7. Agent nebeží v režime „povoliť všetko“ na počítači s produkčnými kľúčmi. Čítanie .env je zakázané.

8. Zálohy sú časté a otestované — skutočne ste vyskúšali obnovu a iba neveríte tomu, že kópie „sú niekde uložené“.

9. Kód bol skontrolovaný pomocou /security-review alebo doplnku security-guidance. Zistené problémy boli opravené.

10. Zručnosti a rozšírenia iných ľudí boli skontrolované pred inštaláciou. Nič sa neinštalovalo „naslepo“.

Kde začať dnes#

Nesnažte sa všetko z tohto sprievodcu zaviesť počas jedného večera — nakoniec neurobíte nič. Dnes vykonajte tri najdôležitejšie kroky:

1. Skontrolujte svoje tajné údaje. Otvorte .gitignore, uistite sa, že je v ňom uvedený .env, a skontrolujte, či vo verejnom repozitári nie sú kľúče. Ak nejaké unikli, zneplatnite ich a vydajte nové.
2. Opýtajte sa na RLS. Povedzte agentovi: „ukáž mi tabuľky, v ktorých je vypnuté RLS“ — a zapnite ho všade, kde sa ukladajú údaje ľudí.
3. Nastavte časté zálohy. Ak sa niečo pokazí, prídete tak o minúty namiesto dní.

Potom sa držte vyššie uvedeného kontrolného zoznamu, keď váš projekt porastie a začne spracúvať peniaze a údaje iných ľudí.

Ešte jedna vec. Bezpečnosť vibe codingu je otázkou zodpovednosti vlastníka. Nemusíte sa stať odborníkom na bezpečnosť. AI vytvorilo váš produkt za večer — výborne, ale zodpovedáte zaň vy. V praxi tak vyzerá základná úroveň opísaná v tomto sprievodcovi.

Ak chcete ďalej pracovať s modelmi, prejdite na Ailoot.