Šest rupa koje AI ostavlja u aplikaciji (i kako se zatvaraju)

Ažurirano: 12.10.2026. | Verzija 1.0

Aplikacija radi, dugmad rade, testovi su zeleni. To ne znači da je bezbedna. Nezavisno istraživanje sa 200 zadataka iz stvarnih projekata pokazalo je da je 82,8 odsto rešenja koja su prošla sve funkcionalne testove ipak imalo bezbednosni propust. Testovi mere da li program radi ono što treba, a ne da li sprečava ono što ne sme.

Ovaj tekst je spisak šest propusta koji se ponavljaju, sa merenjima i sa rečenicama koje možete doslovno ubaciti u zahtev prema AI alatu.

Vredi odmah reći i gde je granica ovog teksta. Deo brojeva dolazi od firmi koje prodaju skenere koda, pa su označeni. Nezavisna akademska istraživanja su označena posebno.

Zašto se to uopšte dešava

Model piše ono što ste tražili. Ako niste tražili ogradu, ograde nema. U testu u kojem je pet agenata (Cursor, Claude Code, Codex, Replit, Devin) pravilo iste tri aplikacije, nastalo je 69 ranjivosti. Istraživač koji je test vodio zabeležio je da agenti bezbednosne kontrole uglavnom nisu pogrešno napravili, nego ih nisu ni pokušali napraviti.

Zanimljivo je i šta AI radi dobro. Klasične napade je naučio: po merenju iz 2026, kod sprečava SQL injekciju u 83 odsto slučajeva i ispravno koristi kriptografiju u 87 odsto. Ali kontrole koje zavise od konteksta vaše aplikacije ne postoje.

Rupa 1: tabela u bazi bez pravila pristupa

Najskuplja i najčešća. Baza se otvori prema internetu, a pravilo o tome ko sme da vidi koji red se nikad ne uključi. Zvanična Supabase dokumentacija to kaže izričito: tabela u izloženoj šemi bez zaštite na nivou reda može da se čita i menja od bilo koje uloge koja ima dozvolu.

Koliko je rasprostranjeno: u pregledu objavljenom 1. oktobra 2026, skenirano je oko 300.000 domena koji koriste Supabase i pronađeno 16.326 baza sa tabelama koje se mogu čitati spolja. Više od polovine imalo je naznake ličnih podataka. Pregled je radila firma koja se bavi bezbednošću, i nije reč o propustu u samom Supabase-u, nego o podešavanju pojedinačnih aplikacija.

Ovde je detalj koji objašnjava zašto baš aplikacije napravljene uz AI upadaju u ovu rupu. Tabela napravljena kroz vizuelni uređivač dobija zaštitu podrazumevano, a tabela napravljena programski, preko API-ja ili SQL-a, ne dobija. Agent pravi tabele programski.

U zahtev dodajte: „Za svaku tabelu uključi zaštitu na nivou reda i napiši politike posebno za čitanje, upis, izmenu i brisanje. Pokaži mi spisak tabela i njihovih politika kad završiš."

Rupa 2: provera prava samo u pregledaču

Dugme je sakriveno, pa korisnik ne može da ga klikne. Ali adresa i dalje radi ako je neko otkuca ručno. Zvanična Next.js dokumentacija to kaže otvoreno: provera u posredničkom sloju je koristan prvi filter, ali ne sme da bude jedina odbrana, a većina provera treba da bude što bliže samim podacima.

Isto upozorenje važi za uobičajeni obrazac u kojem komponenta vrati prazan sadržaj ako korisnik nije prijavljen. Aplikacija ima više ulaza, pa to ne sprečava pristup ugnježdenim delovima i serverskim akcijama.

U zahtev dodajte: „Svaku serversku akciju i svaku rutu tretiraj kao javno dostupnu i u njoj posebno proveri ko je korisnik i sme li tu radnju. Ne oslanjaj se na to što je dugme sakriveno."

Rupa 3: ključ koji je otišao u pregledač

Tajni ključ baze ili platnog servisa završi u delu aplikacije koji se šalje korisniku. Odatle ga svako pročita, a taj ključ po pravilu zaobilazi sva pravila pristupa.

Zamka je u imenovanju promenljivih. U popularnim okvirima, prefiks koji označava javnu promenljivu znači da će je alat za pakovanje ugraditi u kod koji ide u pregledač. Dovoljno je da ime tajnog ključa dobije taj prefiks.

Uz to: broj otkrivenih tajni u javnim repozitorijumima i dalje raste, a veliki deo tajni koje su procurele ranije i danas je aktivan, jer niko nije promenio ključ posle incidenta.

U zahtev dodajte: „Nijedan tajni ključ ne sme da ima javni prefiks niti da se pojavi u kodu koji ide u pregledač. Proveri sve promenljive okruženja i reci mi koje su izložene."

Rupa 4: nema ograničenja i osnovnih zaštita

Ovde su agenti najslabiji. U pomenutom testu pet agenata, na jednom tipu napada (zahtev koji server šalje sam sebi ili unutrašnjoj mreži) svih pet je napravilo ranjivost. Prateći pregled navodi da nijedna od petnaest aplikacija nije imala zaštitu od zahteva sa drugog sajta, nijedna nije imala bezbednosna zaglavlja, a samo jedna je uopšte pokušala ograničenje broja poziva. Taj prateći pregled nisam uspeo da potvrdim u originalu, pa ga uzmite kao naznaku, ne kao meru.

Posledica ograničenja koje ne postoji je jednostavna: neko pozove vašu rutu za slanje mejla deset hiljada puta.

U zahtev dodajte: „Dodaj ograničenje broja poziva na rutama za prijavu, registraciju, slanje mejla i obnovu lozinke. Dodaj bezbednosna zaglavlja i zaštitu od zahteva sa drugog sajta."

Rupa 5: poslovna logika koja prima besmislice

Negativna količina, negativna cena, popust veći od sto odsto, datum u prošlosti. U istom testu, četiri od pet agenata dozvolila su porudžbinu sa negativnom količinom, a tri od pet proizvod sa negativnom cenom. Ne zato što su pogrešili, nego zato što u zahtevu nije pisalo da se to zabrani.

Ovo je rupa koju AI alat nikad neće sam zatvoriti, jer pravila vašeg posla zna samo onaj ko taj posao radi.

U zahtev dodajte: „Napiši spisak nedozvoljenih vrednosti za svako polje (negativni iznosi, nula, prazno, predugačak tekst, datum u prošlosti) i napravi test za svaku od njih."

Rupa 6: paket koji ne postoji

Model predloži biblioteku koja zvuči uverljivo, ali ne postoji. Napadač registruje baš to ime i čeka. Sledeći korisnik koji posluša isti predlog instalira napadačev kod.

Ovo je izmereno: u akademskom radu sa 576.000 uzoraka i 16 modela, 19,7 odsto preporučenih paketa nije postojalo, uz preko 200.000 jedinstvenih izmišljenih imena. Kod komercijalnih modela udeo je bio oko 5 odsto, kod otvorenih i do 21,7. Napad je isplativ zato što se ista izmišljena imena ponavljaju.

U zahtev dodajte: „Koristi samo pakete koji su već u spisku zavisnosti. Ako ti treba nov paket, prvo mi reci koji i zašto, da ga proverim."

Šta kažu merenja, ukratko

Nalaz	Brojka	Izvor i vrsta
Rešenja koja prolaze testove, a nisu bezbedna	82,8 %	SusVibes, akademski rad, 200 zadataka iz 108 stvarnih projekata
Funkcionalno tačni programi koji se ipak mogu probiti	oko polovina	BaxBench, akademski rad, 392 zadatka
Bezbednosni prolaz AI koda, promena za godinu dana	55 % na 56 %	Veracode, firma koja prodaje skener
Preporučeni paketi koji ne postoje	19,7 %	Akademski rad, 576.000 uzoraka
Programeri uz AI pišu manje bezbedan kod, a sigurniji su da je bezbedan	potvrđeno	Stanford, 47 učesnika, kontrolisana studija

Poštena napomena: nisam našao nijedno recenzirano istraživanje iz 2025. ili 2026. koje tvrdi da je AI kod jednako bezbedan kao ljudski. To odsustvo je samo po sebi podatak. Sa druge strane, Google-ovo istraživanje stanja isporuke softvera nalazi da uvođenje AI danas pozitivno utiče na brzinu isporuke, ali i dalje ide uz veću nestabilnost, dakle više neuspelih izmena i više doradi.

Kako da proverite svoju aplikaciju danas

1. Uključite proveru koju platforma već ima. Supabase ima savetnika za bezbednost u svom okruženju, sa pravilima koja imaju imena, na primer ono koje prijavljuje tabelu bez zaštite na nivou reda, i ono najpodmuklije, koje prijavljuje da politika postoji ali je zaštita isključena.
2. Otvorite svoj sajt u anonimnom prozoru i pokušajte da otvorite adrese koje bi smeo samo prijavljen korisnik.
3. Pogledajte izvorni kod strane i potražite ključeve. Ono što vidite vi, vidi i svako drugi.
4. Tražite pregled u novom razgovoru, ne u onom u kojem je kod pisan, da agent ne brani sopstveni rad.
5. Razdvojite razvojnu i produkcionu bazu. Ako ih agent vidi obe, jednog dana će obrisati pogrešnu.

Česta pitanja

Da li je vibe coding nebezbedan po sebi? Nije sam po sebi, ali povećava verovatnoću da važne kontrole izostanu, jer ih niko ne traži izričito. Ko zna šta da traži, dobija upotrebljiv rezultat.

Da li pomaže ako u prompt napišem da kod bude bezbedan? Manje nego što se očekuje. U akademskom testu, davanje bezbednosnog nagoveštaja nije popravilo rezultat, čak je blago smanjilo funkcionalnu tačnost. Rade konkretni zahtevi po stavkama, ne opšta želja.

Koliko košta pregled bezbednosti? Za malu aplikaciju, pregled koji pokrije ovih šest tačaka je posao od nekoliko sati. To je neuporedivo jeftinije od prijave curenja podataka.

Da li se ovo odnosi i na aplikacije koje nemaju korisnike spolja? Interni alati su manji rizik, ali ne i nulti, posebno ako sadrže podatke o zaposlenima ili kupcima.

Imam aplikaciju napravljenu pre godinu dana. Šta prvo da proverim? Pravila pristupa bazi i mesto na kojem stoje ključevi. To su dve rupe koje najčešće vode do curenja celog sadržaja.

Sledeći korak

Prođite listu od pet provera iznad na svojoj aplikaciji, danas. Ako koristite Supabase, nastavite na tekst o pravilima pristupa, jer je to rupa broj jedan.

GoSimple · Ivan Dabetić

Izvori (provereno 12.10.2026)

• SusVibes, bezbednost rešenja koja prolaze testove: https://arxiv.org/abs/2512.03262
• BaxBench, funkcionalno tačni ali probojni programi: https://proceedings.mlr.press/v267/vero25a.html
• Veracode, izveštaj o bezbednosti AI koda 2026: https://www.veracode.com/blog/2026-genai-code-security-report-ai-risk/
• Test pet agenata: https://www.securityweek.com/vibe-coding-tested-ai-agents-nail-sqli-but-fail-miserably-on-security-controls/
• Izmišljeni paketi: https://arxiv.org/abs/2406.10279
• Stanford, programeri i lažno samopouzdanje: https://arxiv.org/abs/2211.03622
• Supabase, zaštita na nivou reda: https://supabase.com/docs/guides/database/postgres/row-level-security
• Supabase, savetnik za bezbednost: https://supabase.com/docs/guides/database/database-advisors
• Next.js, autentifikacija i gde idu provere: https://nextjs.org/docs/app/guides/authentication
• Pregled izloženih baza: https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps