Vibe coding turvariskid: 5 auku, mille ise kordasin

Olen Denys, full-stack- ja AI-insener. Parandan rakendusi, mis on ehitatud Lovable’i, Bolt’i, Cursor’i või Claude Code’iga, ja enamik neist töötab Supabase’i peal. See artikkel koondab, mida avaldatud uuringud vibe coding’u turvalisuse kohta ütlevad ja mida ma nägin, kui sagedasi vigu tahtlikult uuesti ehitasin.

Millised turvariskid on vibe coding’ul?

Peamine risk on katkine juurdepääsukontroll: andmed, mida iga külastaja saab lugeda või muuta, sest reegel, mis peaks teda peatama, puudub, on liiga lõdv või jäetakse mööda. Järgnevad süstimine ja nõrk autentimine. Kolm sõltumatut uuringut osutavad samasse suunda:

Uuring	Mida testiti	Mida leiti
Deng, Fan ja Meng, arXiv 2606.23130, juuni 2026	200 avaldatud rakendust, mis on ehitatud Claude Code’i ja Lovable’iga, auditeeritud käsitsi ja agentidega	182 rakendusel 200-st (91%) oli vähemalt üks haavatavus; 65,77% 1186 leiust olid Critical või High; katkine juurdepääsukontroll oli suurim kategooria, 64% rakendustest
Escape, oktoober 2025	5600 avalikku rakendust Lovable’ist, Base44-st, Create.xyz-ist ja mujalt, passiivne skaneerimine	üle 2000 suure mõjuga haavatavuse, üle 400 paljastatud saladuse, 175 juhtu paljastatud isikuandmetega; peamine põhjus oli valesti seadistatud õigused, eriti Supabase’i RLS
Veracode GenAI Code Security Report, 2025 ja 2026	80 kodeerimisülesannet, mis anti üle 100 mudelile	2025. aastal andis turvalist koodi vaid 55% ülesannetest; 2026. aastal oli keskmine läbimismäär 56%, mudeli suurusest ja aastatest sõltumata sama

Uuringud mõõdavad erinevaid asju, seega protsendid ei liitu üheks arvuks. Neid ühendab kuju: kood töötab ja augud asuvad usalduspiiril.

Milliseid auke ma kordasin?

Seadistasin kohalikul Supabase’i pinul (CLI 2.109.1, Postgres 17.6, PostgREST 14.14) ühe tabeli orders, kolme võltskliendi reaga. Seejärel kutsusin Data API-t nii, nagu brauser seda teeb, publishable key’ga, mille iga Supabase’i frontend kaasa annab, ja muutsin korraga ühte asja.

Seadistus	Mida avalik võti sai	Miks
Tabel ilma RLS-ita	Kõik 3 rida ja lisamine tagastas 201 Created	Vaikeõigused lubavad rollil anon lugeda ja kirjutada ning miski ei filtreeri ridu
RLS sees, poliitikat pole	[], tühi loend	RLS ilma poliitikata keelab kõik rollidele anon ja authenticated
Poliitika using (true)	Kõik 3 rida	Poliitika on olemas, seega tabel näib kaitstud, kuid see lubab iga rea
View kaitstud tabeli peal	Kõik 3 rida	View töötab omaniku õigustega, kui sellel pole security_invoker = true; sellega on tulemus []
Secret key frontendi koodis	Kõik 3 rida	Secret key vastab rollile service_role, millel on BYPASSRLS

Teine rida on ohtlik hetk. RLS on sees ja rakendus näitab tühja loendit, seega tundub, et see on katki. Kiireim prompt, mis seda “parandab”, on poliitika, mis lubab kõik, ehk kolmas rida. See ring, viga ja siis parandus, mis laiendab juurdepääsu, on muster, mida kohtan vibe coding’uga loodud rakendustes kõige sagedamini, ja just seepärast ütleb “RLS on sees” üksi vähe.

Miks AI kirjutatud kood juurdepääsukontrollis läbi kukub?

Agenti premeeritakse koodi eest, mis jookseb. Tühi loend või 401 näeb välja nagu viga ja parandus, mis selle kaotab, on sageli see, mis juurdepääsu avab. arXiv uuring viib oma 1186 leiu tagasi kaheksale korduvale veatüübile, mis on grupeeritud agentide mälu-, eesmärgi- ja teadmisedefektideks, ning leidis, et parem promptimine vähendas aukude arvu, kuid ei kõrvaldanud neid.

Teine põhjus on arhitektuur. Lovable’i või Bolt’i rakendusel pole tavaliselt oma backend’i: brauser räägib andmebaasiga otse Data API kaudu. Iga reegel, mis kliendiandmeid kaitseb, peab elama Postgresis, õiguste (grants), poliitikate ja funktsioonidena, ja midagi sellest pole rakenduse eelvaates näha, kus olete sisse logitud omanikuna. Supabase muudab siin ühte vaikeväärtust: alates 30. oktoobrist 2026 ei anta olemasolevate projektide uutele tabelitele enam automaatselt Data API õigusi. Minu pinul vastas tabel ilma õiguseta 42501 permission denied vihjega, mis nimetab puuduva GRANT-i. See peatab ülaltoodud tabeli esimese rea uute tabelite puhul, kuid mitte ülejäänud nelja ega juba olemasolevaid tabeleid.

Mis veel läheb andmebaasist väljaspool valesti?

Samad uuringud loetlevad riske, millel pole RLS-iga pistmist:

• Saladused bundle’is. Escape leidis üle 400 paljastatud saladuse, sealhulgas OpenAI võtmed ja maksete admin-võtmed. Kõik, mis brauserisse saadetakse, on avalik.
• Marsruudikaitsed ainult Reactis. Leht, mis suunab sisselogimata kasutajad ümber, jätab selle taha API, mis vastab igaühele.
• Päringupiirangud, mis kunagi ei käivitu. Hostitud Supabase’i projektil, mida sondeerisin, nullus edge function’i mälus hoitud loendur igal päringul. Kirjutasin selle lahti oma Lovable’i rakenduse turvanimekirjas.
• Vanad teegid. Escape luges avalikes varades kokku 254 haavatavat JavaScripti teegi eksemplari, sageli päritud mallidest.

Kuidas vibe coding’uga loodud rakendust kontrollida?

1. Avage rakendus, avage DevTools → Network ja leidke päringud aadressile /rest/v1/. Kopeerige üks cURL-ina, eemaldage päis Authorization, jätke apikey alles ja käivitage. Kui andmed tulevad tagasi, tulevad need igaühele.
2. Otsige ehitatud JavaScriptist sb_secret_ ja service_role. Vaste on võti, mida tuleb täna vahetada.
3. Käivitage tasuta Supabase’i turvakontroll. See loeb projekti kataloogi ja märgib oma 46 reegli hulgas “RLS keelatud avalikel tabelitel”, “Poliitikad, mis lubavad kõik read”, “Vaated, mis mööduvad RLS-ist” ja “Vaikeõigused, mis avavad uued objektid API-le”: ülaltoodud tabeli esimesed neli rida.
4. Testige kahe kasutajaga kahes ettevõttes, ainus test, mida skanner teie eest teha ei saa. Kuidas mina seda teen, on Lovable’i nimekirjas ja kuidas Supabase’i RLS-i testida näitab meetodit tootmisrakendusel, kus on õiguste ekraan.

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

Mida see ei näita

Minu reproduktsioon on üks tabel kohalikul pinul, ehitatud iga mehhanismi näitamiseks, mitte päris rakenduste skaneerimine. Levimuse arvud pärinevad kolmest uuringust, igaühel oma valim ja meetod, lingitud ülal. Ja puhas tulemus nendes viies kontrollis ei muuda rakendust turvaliseks: loogikavead, näiteks kaitse, mis laseb puuduva väärtuse läbi, vajavad oma teste. Üks selline on NULL, mis jättis õiguste kontrolli vahele.