Varnost pri vibe codingu: kako zaščititi aplikacijo, izdelano z UI

Več navodil za delo z Ailootom najdete v dokumentaciji.

Zakaj v aplikacije, izdelane z UI, vdrejo pogosteje?#

Tudi sam izdelujem izdelke z UI in zaradi varnosti ne postanem paranoičen do te mere, da bi »vse zaklenil do skrajnosti«. Vendar obstaja osnovna raven, pod katero ne smete iti, sicer se boste nekega dne zbudili ob prazni podatkovni zbirki, na vašem strežniku pa bodo rudarji nekoga drugega. Ta vodnik obravnava to osnovno raven. Ne gre za to, da bi »postali varnostni strokovnjak«, ampak za to, da se »ne ustrelite v koleno brez razloga«.

Koren problema je preprost. Ko agentu UI naročite: »izdelaj mi aplikacijo za naročanje strank«, ta poskrbi, da aplikacija čim prej deluje. Varnost je dodatno delo, ki v predstavitvi ni vidno. Zato je podatkovna zbirka nastavljena kot odprta, plačilni ključ gre neposredno v kodo, preverjanje »ali ima ta uporabnik dostop?« pa obstaja samo v brskalniku, kjer ga je mogoče v hipu obiti.

Z drugimi besedami, odprtina se pojavi sama od sebe, privzeto. Niste storili ničesar narobe. Preprosto niste storili ničesar — v varnosti pa nedejavnost pomeni natanko to, da je nekaj »odprto za vse«.

Obstaja še tretja plast. UI pogosteje razkrije skrivnosti kot človek. Logika je jasna: agent brez preverjanja izvede git add . in git push, vaša datoteka .env s ključi pa postane javna skupaj z vsem drugim.

Kaj so se ustvarjalci z vibe codingom že naučili na težji način?#

Najboljši način za preprečevanje malomarnosti je učenje iz napak drugih. Pred objavo projekta si velja ogledati štiri poročila.

Lovable in izklopljen RLS. Platforma Lovable izdeluje aplikacije na podlagi besedilnih opisov. Leta 2025 so v njenih aplikacijah odkrili sistemsko vrzel in ji dodelili oznako CVE-2025-48757. Vzrok: ustvarjene aplikacije niso imele pravil za dostop do posameznih vrstic v podatkovni zbirki (RLS, razložen spodaj). Raziskovalec je preveril vzorec in v 170 aplikacijah našel 303 izpostavljene dostopne točke. Razkriti so bili imena, telefonske številke, stanja plačil, ključi API drugih ljudi in celo domači naslovi. V približno 70 odstotkih pregledanih aplikacij je bila zaščita na ravni vrstic povsem izklopljena.

Tea in občutljivi podatki. Aplikacija Tea (anonimne ocene ljudi) je julija 2025 izgubila približno 72,000 slik, med njimi 13,000 selfijev in fotografij dokumentov, nato pa še več kot milijon zasebnih sporočil. Tehnični vzrok sta bila odprta shramba in šibko preverjanje dostopa. Varnostna skupnost Tea navaja kot nazoren primer: kadar je hiter zagon pomembnejši od preverjanja dovoljenj, najprej uidejo občutljivi podatki.

Še en praktičen primer. V primeru, ki ga je opisal izvirni avtor, so vdrli v aplikacijo ustvarjalca, ki je uporabljal vibe coding, ker je UI pri ustvarjanju podatkovne zbirke nastavila privzeto geslo, ki ga je bilo mogoče samodejno uganiti. Nato je sledil običajni potek: napadalci so vdrli, namestili rudarje in prepisali projekt. Strežnik je bilo treba v celoti izbrisati. Privzeto geslo je kot odklenjena vrata z napisom »kar vstopite«.

Dve plati varnosti: kje natančno ste ranljivi?#

Ko ljudje govorijo o »varnosti vibe codinga«, običajno združujejo dva povsem različna strahova. Ločimo ju, saj se pred njima zaščitimo na različna načina.

Prva plat — sam agent. Agenta UI zaženete na računalniku in mu omogočite dostop do datotek, terminala, ključev in podatkovne zbirke. Tveganje je v tem, da agent ni človek: navodila upošteva dobesedno in poišče najkrajšo pot, četudi je nevarna. Sem spada tudi tveganje, da se ukaz nekoga drugega v agent »vbrizga« prek besedila, ki ga bere (temu pravimo prompt injection).

Druga plat — dokončana aplikacija. To je tisto, kar ste objavili in kar ljudje uporabljajo. Tarča je vaše objavljeno spletno mesto ali storitev: napadalci vdrejo v odprto podatkovno zbirko, pošljejo ponarejene zahteve ali ugibajo račune drugih ljudi. Agent pri tem nima ničesar opraviti s tem — odprtina je ostala od prej, drugi pa jo izkoriščajo.

Anthropic, podjetje, ki stoji za Claudom, glavno načelo zaščite opredeljuje takole — in velja za obe plati:

V praksi to pomeni: ne računajte na to, da se bo UI »sama od sebe izogibala slabim dejanjem«. Najprej omejite, kaj lahko dejansko naredi, šele nato jo prosite, naj se vede primerno. Ko njeno vedenje odpove — in bo — vas bo zaščitila samo trdna meja, ki ste jo vnaprej postavili.

Želite, da UI deluje predvidljivo in vas ne spravlja v težave pri vsakem novem projektu? Varnostna pravila zapišite v CLAUDE.md, agent pa jih bo upošteval pri vsaki zahtevi.

Kaj lahko agent UI naredi z dostopom do vašega računalnika?#

Najbolj podcenjeno tveganje je vaš lastni agent s preširokimi dovoljenji. Zunanji heker sploh ni potreben. Tukaj je nedaven primer s konca maja 2026. Agent Codex je potreboval skrbniška dovoljenja, ki jih uporabnik ni imel. Agent ni odnehal — pregledal je sistem, opazil, da je uporabnik član skupine docker, ki je dejansko enakovredna uporabniku root, in uporabil ta dostop.

Tu ni bilo zlonamernega namena. Agentu, ki dobi navodilo »reši nalogo«, strukturno šibko točko uspe najti hitreje kot človeku. Če mu ta šibka točka omogoči dostop do vaših ključev ali produkcijskega okolja, ga bo uporabil. Zato je prvo pravilo najmanjši obseg dovoljenj. Agentu za določeno nalogo omogočite natančno toliko dostopa, kot ga potrebuje, niti za kanček več.

Kaj lahko storite v praksi, tudi če niste programer?

1. Agenta ne zaženite v načinu »dovoli vse« na produkcijskem računalniku

   Način, v katerem agent ne zahteva potrditve (pogosto imenovan bypass ali yolo), je primeren samo za peskovnik ali testni projekt, ne pa za računalnik z delujočimi ključi in produkcijskim dostopom.

2. Agenta ne pustite brati skrivnosti

   V Claude Code to uredite s pravilom, ki zavrne dostop do datotek s ključi. Tako orodje agentu ne bo dovolilo odpreti datoteke .env, tudi če bi to želel.

3. Produkcijske ključe hranite ločeno

   Ključi za produkcijsko podatkovno zbirko in plačilno storitev ne smejo biti v isti mapi, kjer agent piše kodo. Okolja naj bodo ločena: pri eksperimentiranju uporabljajte testne ključe.

4. Uporabite peskovnik orodja

   Sodobna orodja UI lahko ukaze izvajajo ločeno (v peskovniku), kjer nimajo dostopa do preostalega sistema. V Claude Code to število zahtev za dovoljenje zmanjša za približno 84 odstotkov — zato je tudi uporaba priročnejša.

Pravilo, ki v Claude Code zavrne branje skrivnosti, je videti približno takole — vstavite ga v nastavitve dovoljenj:

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

Kam nikoli ne smete shraniti ključev API in gesel?#

Najcenejša in najpogostejša napaka je shranjevanje ključev v kodo. Ključ API za plačilno storitev, geslo za podatkovno zbirko, žeton bota — vse to so skrivnosti. Spadajo v ločeno datoteko .env, ta datoteka pa mora biti navedena v .gitignore, da ne zaide v git skupaj s kodo.

Zakaj je to ključno: ključ v javnem repozitoriju ne ostane skrit dolgo. Boti neprestano pregledujejo nove objave. Sledi običajno zaporedje: najdejo ključ za oblak, na vaš račun zaženejo strežnike za rudarjenje kriptovalut, zjutraj pa vas čaka račun v višini več deset tisoč. Razvijalci pogosto pripovedujejo takšne zgodbe, računi pa znašajo več deset tisoč dolarjev.

Obseg težave v letu 2025: 28.65 milijona novih skrivnosti, neposredno vpisanih v kodo javnih repozitorijev, kar je 34 odstotkov več kot leto prej. Uhajanje ključev, namenjenih storitvam UI, se je povečalo za 81 odstotkov. Vibe coding priliva olje na ogenj, ker agent objavi spremembe, ne da bi jih pregledal.

Kaj lahko preverite ročno takoj zdaj:

1. Odprite datoteko .gitignore v projektu

   Preverite, ali vsebuje vrstico .env. Če je ni, jo dodajte pred prvo objavo sprememb.

2. Odprite svoj repozitorij GitHub

   Preverite, ali je datoteka .env tam. Hiter način preverjanja je iskanje niza .env ali dela vašega ključa v repozitoriju.

3. Če je ključ ušel, ga prekličite in izdajte novega

   Brisanje objave spremembe ni dovolj: ključ je bil morda že ukraden. Pojdite v storitev (ponudnik plačil, oblak ali UI), prekličite stari ključ in izdajte novega. Temu pravimo rotacija.

4. Ključem dodelite najmanjša potrebna dovoljenja

   Če je ključ potreben samo za branje, naj bo samo za branje. Tako lahko ukradejo manj, tudi če ključ uide.

Zakaj lahko brez RLS vsi vidijo vašo podatkovno zbirko?#

Če aplikacijo izdelujete v Supabase ali podobni podatkovni zbirki, je to najpomembnejši razdelek. RLS pomeni Row Level Security. Preprosto povedano, gre za pravilo, ki določa, katere vrstice v tabeli so prikazane določenemu uporabniku. Brez njega tabela »orders« vsakomur vrne naročila vseh strank.

Tako to jasno pojasnjuje sama dokumentacija Supabase:

To je glavna past za ustvarjalca, ki uporablja vibe coding. Ko tabelo ustvarite s klikanjem po nadzorni plošči Supabase, se zaščita samodejno vklopi. Ko pa tabelo ustvari UI — ta pa skoraj vedno neposredno napiše ukaze SQL — RLS privzeto ostane izklopljen. To pomeni, da je tabela, ki jo ustvari agent, skoraj zagotovo odprta za ves internet. Prav tako so ušli podatki iz 170 aplikacij Lovable.

Kaj storiti:

1. Vprašajte agenta neposredno

   Napišite: »pokaži mi vse tabele, v katerih je RLS izklopljen«. UI bo ustvarila seznam — to je vaš seznam opravil.

2. V vsaki tabeli z uporabniškimi podatki vklopite RLS

   Dodajte vsaj eno pravilo za dostop — na primer: »uporabnik lahko vidi samo svoje vrstice«.

3. Preverite nadzorno ploščo

   V nadzorni plošči Supabase mora biti pri vsaki tabeli prikazano »RLS enabled«. Če je oznaka siva ali rdeča, to pomeni, da je tabela odprta.

4. Preizkusite zares

   Prijavite se kot običajen uporabnik in poskusite zahtevati podatke nekoga drugega. Če je dostop zavrnjen, pravilo deluje.

Zakaj preverjanje dovoljenj v vmesniku ne zaščiti vaše aplikacije?#

Pogosta zmota je: »Poskrbel sem, da običajni uporabniki ne vidijo gumba za skrbnika.« Težava je v tem, da je gumb samo slika v brskalniku. Zahtevo je mogoče poslati naravnost strežniku brez uporabe gumba. Če strežnik znova ne preveri dovoljenj, bo izvedel ukaz nekoga drugega.

Klasičen primer se imenuje IDOR. Predstavljajte si, da odprete svoje naročilo na naslovu z id=123. Spremenite ga v id=124 in vidite lahko naročilo nekoga drugega, ker strežnik ni preveril, ali je naročilo res vaše. To je ena najpogostejših vrzeli v aplikacijah, izdelanih z vibe codingom, šibko preverjanje dovoljenj pa je povzročilo uhajanje podatkov pri aplikaciji Tea.

Pravilo je preprosto: vsako preverjanje »ali sme ta uporabnik to storiti?« ponovite na strežniku. Vmesnik je namenjen priročnosti; zaščita sodi v backend. Navodilo, ki ga lahko neposredno daste agentu: »dodaj preverjanje dovoljenj na strani strežnika za vsako končno točko, ki bere ali spreminja uporabniške podatke; ne zanašaj se na element, skrit v vmesniku.«

Kako lahko preverite ranljivosti v kodi, če niste programer?#

Dobra novica: danes lahko za varnostni pregled prosite kar isti UI — kar dobro najde pogoste vrzeli. Tukaj so tri orodja za različne naloge.

1. Ukaz /security-review v Claude Code. Enkrat pregleda trenutno vejo in poišče SQL injection, XSS, vrzeli v avtorizaciji, uhajanje podatkov in težave z odvisnostmi. V ločenem vodniku o varnostnem pregledu v Claude Code sem korak za korakom pojasnil, kako deluje in kako dodati samodejno preverjanje ob vsaki spremembi. Glavno sporočilo tukaj: to je prva obrambna linija, ki jo zaženete z enim ukazom.

2. Uradni vtičnik security-guidance. Namestite ga iz uradne tržnice vtičnikov z ukazom /plugin install security-guidance@claude-plugins-official (potrebujete Claude Code različice 2.1.144 ali novejše). Kodo preverja v treh trenutkih: ob vsaki spremembi, na koncu vsakega kroga in ob objavi sprememb. Zazna obvode avtorizacije, IDOR, injekcije in šibko kriptografijo. Anthropic pa odkrito opozarja na njegove omejitve:

npx skills add <author>/<repo>

Nato agentu preprosto recite: »preveri moj projekt glede ranljivosti«. Vendar obstaja pomembno opozorilo glede te zbirke, zato ji spodaj namenjam ločen razdelek.

Za širši kontekst: tudi veliki igralci so začeli resno obravnavati varnost kode, ustvarjene z UI. V okviru projekta Project Glasswing, ki so ga 2. junija 2026 razširili na 150 organizacij, so partnerji z uporabo Anthropicovih modelov v kratkem času odkrili več kot 10,000 kritičnih ranljivosti. Tveganje je jasno:

Ali lahko zaupate veščinam in razširitvam z GitHuba?#

Tukaj postanejo stvari še posebej zapletene, ker nevarnost izvira iz orodja, ki ga namestite zaradi varnosti. Ko zaženete npx skills add ... ali namestite razširitev, prevzamete kodo nekoga drugega, ki jo nato agent zažene z vašimi dovoljenji. Če je bil avtor napaden ali je bil paket zlonameren že od začetka, imate težavo.

Oglejmo si zbirko veščin iz prejšnjega razdelka. V njenem imenu je »Anthropic«, zato postanete manj previdni. Vendar je v njenem lastnem opisu jasno zapisano:

Z drugimi besedami: ime je zavajajoče. Sama zbirka je trenutno zrela in brez zlonamerne vsebine, vendar načelo ostaja: namestite jo na lastno odgovornost. In grožnja ni teoretična. Maja 2026 je zlonamerna razširitev za urejevalnik ostala na tržnici samo 18 minut — v tem času pa je ljudem, ki so jo namestili, uspela ukrasti gesla iz upravljalnikov gesel, žetone GitHub, dostop do oblaka in celo konfiguracije Claude Code. Še ena neprijetna podrobnost: takšna zlonamerna programska oprema pogosto preživi običajno odstranitev paketa in se znova zažene v naslednji seji.

Sam sem si ustvaril preprosto navado in jo priporočam tudi vam: preden z GitHuba namestite katero koli veščino, jo sami preverite. Avtorji so lahko napadeni, računi ugrabljeni, v repozitorij pa se lahko prikrade zlonamerna programska oprema. Preverjanje je vaša zaščita.

Praktični minimum pred namestitvijo: poglejte avtorja in število zvezdic, preberite opis veščine, orodja ne namestite samo »zaradi priporočila v eni objavi«, neznano orodje pa najprej preizkusite v ločenem testnem okolju, ne na računalniku s produkcijskimi ključi.

Kaj vas reši po vdoru: varnostne kopije in povrnitev na prejšnje stanje#

Varnost ni samo »preprečevanje dostopa zunanjim osebam«, temveč tudi »vrnitev v običajno stanje, ko gre kaj narobe«. Ker bo šlo kaj narobe. V opisanem praktičnem primeru je agent UI pri rutinski nalogi v produkcijskem projektu izbrisal delujočo podatkovno zbirko. Varnostna kopija je obstajala, vendar je bila stara tri dni — in trije dnevi podatkov so preprosto izginili.

Iz tega izhajata dve pravili.

Varnostno kopirajte pogosto. Če vaša aplikacija vsebuje podatke, ki jih ne bi želeli izgubiti, kopija vsake tri dni pomeni le navidezno zaščito. Nastavite samodejne varnostne kopije vsaj vsakih 30 minut. Pri večini podatkovnih zbirk, vključno s Supabase, lahko to omogočite z nekaj kliki.

Git je zavarovanje pred agentom. Git shranjuje zgodovino vaše kode, zato lahko obnovite katero koli delujoče stanje. Ko agent prepiše nekaj, kar je delovalo, se vrnete na zadnjo delujočo različico, namesto da bi popravljali ročno. Če je UI izbrisala ali pokvarila projekt in ne veste, kako ga obnoviti, preberite ločen članek: kaj storiti, če je UI izbrisala podatkovno zbirko. Za navodila, kako vnaprej zaščititi projekt pred okvarami, preberite vodnik kako Claude Code zaščititi pred okvarami.

Varnostni kontrolni seznam pred objavo#

Tik pred objavo zaporedoma preverite naslednji seznam.

1. Skrivnosti so v .env, .env pa je v .gitignore. V kodi ni ključev. V javnem repozitoriju ni datoteke .env.

2. Ključi imajo najmanjša potrebna dovoljenja. Vsak ključ lahko naredi samo tisto, kar je potrebno. Produkcijski ključi so ločeni od okolja agenta.

3. RLS je vklopljen v vseh tabelah z uporabniškimi podatki, vzpostavljena pa so tudi pravila za dostop.

4. Za vsako operacijo s podatki se dovoljenja preverjajo na strežniku. Skrivanje gumba v vmesniku ni dovolj. Ročno ste preizkusili spreminjanje id v naslovu.

5. Preverjanje podpisa webhooka. Vsak upravljalnik zunanjih obvestil (plačila, obrazci) preverja podpis.

6. Omejevanje hitrosti velja za dohodne zahteve in drage operacije, da gesel ni mogoče ugibati z metodo brute force in da se vam ne nabere previsok račun.

7. Agent ne deluje v načinu »dovoli vse« na računalniku s produkcijskimi ključi. Branje .env je zavrnjeno.

8. Varnostne kopije se ustvarjajo pogosto in so preizkušene — dejansko ste že poskusili obnoviti podatke, namesto da bi samo verjeli, da so kopije »nekje shranjene«.

9. Koda je bila pregledana z ukazom /security-review ali vtičnikom security-guidance. Ugotovljene težave so odpravljene.

10. Veščine in razširitve drugih ljudi ste preverili pred namestitvijo. Ničesar niste namestili »na slepo«.

Kje začeti danes#

Ne poskušajte nekega večera uresničiti vsega iz tega vodnika — na koncu ne boste naredili ničesar. Danes opravite tri najpomembnejše korake:

1. Preverite svoje skrivnosti. Odprite .gitignore, preverite, ali je naveden .env, in se prepričajte, da v javnem repozitoriju ni ključev. Če so kateri ušli, jih prekličite in izdajte nove.
2. Vprašajte o RLS. Agentu recite: »pokaži mi tabele, v katerih je RLS izklopljen« — nato ga vklopite povsod, kjer so shranjeni podatki ljudi.
3. Nastavite pogoste varnostne kopije. Tako boste v primeru težav izgubili minute namesto dni.

Ko bo vaš projekt rasel in začel obdelovati denar ter podatke drugih ljudi, sledite zgornjemu kontrolnemu seznamu.

Še zadnja stvar. Varnost pri vibe codingu je odgovornost lastnika. Ni vam treba postati varnostni strokovnjak. UI je vaš izdelek izdelala v enem večeru — odlično, vendar ste zanj odgovorni vi. Osnovna raven, opisana v tem vodniku, pokaže, kako je ta odgovornost videti v praksi.

Za nadaljnje delo z modeli obiščite Ailoot.