Vibe coding -tietoturvariskit: 5 aukkoa, jotka toistin

Olen Denys, full-stack- ja tekoäly-insinööri. Korjaan sovelluksia, jotka on tehty Lovablella, Boltilla, Cursorilla tai Claude Codella, ja useimmat niistä pyörivät Supabasella. Tähän artikkeliin olen koonnut, mitä julkaistu tutkimus sanoo vibe coding -tietoturvasta ja mitä näin, kun rakensin yleiset virheet tarkoituksella uudelleen.

Mitkä ovat vibe codingin tietoturvariskit?

Pääriski on rikkinäinen pääsynhallinta: data, jonka kuka tahansa kävijä voi lukea tai muuttaa, koska sääntö, jonka piti pysäyttää hänet, puuttuu, on liian löyhä tai ohitetaan. Injektiot ja heikko tunnistautuminen tulevat seuraavina. Kolme toisistaan riippumatonta tutkimusta osoittaa samaan suuntaan:

Tutkimus	Mitä testattiin	Mitä löytyi
Deng, Fan ja Meng, arXiv 2606.23130, kesäkuu 2026	200 käyttöön otettua sovellusta, jotka on tehty Claude Codella ja Lovablella, auditoitu käsin ja agenteilla	182 sovelluksessa 200:sta (91 %) oli vähintään yksi haavoittuvuus; 65,77 % 1 186 löydöksestä oli Critical tai High; rikkinäinen pääsynhallinta oli suurin luokka, 64 %:ssa sovelluksista
Escape, lokakuu 2025	5 600 julkista sovellusta Lovablesta, Base44:stä, Create.xyz:stä ja muista, passiivinen skannaus	Yli 2 000 vakavaa haavoittuvuutta, yli 400 paljastunutta salaisuutta, 175 henkilötietojen paljastumista; pääsyynä väärin määritetyt oikeudet, erityisesti Supabase RLS
Veracode GenAI Code Security Report, 2025 ja 2026	80 koodaustehtävää yli 100 mallille	Vain 55 % tehtävistä tuotti turvallista koodia vuonna 2025; keskimääräinen läpäisyprosentti oli 56 % vuonna 2026, muuttumaton mallikokojen ja vuosien yli

Tutkimukset mittaavat eri asioita, joten prosentit eivät summaudu yhdeksi luvuksi. Niitä yhdistää kuvio: koodi toimii, ja aukot ovat luottamusrajassa.

Mitkä aukot toistin?

Loin yhden taulun, orders, jossa oli kolme riviä tekaistuja asiakkaita, paikalliselle Supabase-stackille (CLI 2.109.1, Postgres 17.6, PostgREST 14.14). Sitten kutsuin Data API:a niin kuin selain tekee, publishable keyllä, jonka jokainen Supabase-frontend toimittaa mukanaan, ja muutin yhtä asiaa kerrallaan.

Asetelma	Mitä julkinen avain sai	Miksi
Taulu ilman RLS:ää	Kaikki 3 riviä, ja insert palautti 201 Created	Oletusoikeudet antavat anon-roolin lukea ja kirjoittaa, eikä mikään suodata rivejä
RLS päällä, ei politiikkaa	[], tyhjä lista	RLS ilman politiikkaa estää kaiken anon- ja authenticated-rooleilta
Politiikka using (true)	Kaikki 3 riviä	Politiikka on olemassa, joten taulu näyttää suojatulta, mutta se päästää jokaisen rivin
View suojatun taulun päällä	Kaikki 3 riviä	View ajetaan omistajansa oikeuksilla, ellei sillä ole security_invoker = true; sen kanssa tulos on []
Secret key frontend-koodissa	Kaikki 3 riviä	Secret key vastaa roolia service_role, jolla on BYPASSRLS

Toinen rivi on vaarallinen hetki. RLS on päällä ja sovellus näyttää tyhjän listan, joten se näyttää rikkinäiseltä. Nopein prompti, joka “korjaa” sen, on politiikka, joka päästää kaiken läpi, ja se on kolmas rivi. Tuo kehä, virhe ja sitten korjaus, joka laajentaa pääsyä, on kuvio, jonka kohtaan useimmin vibe coding -sovelluksissa, ja siksi “RLS on päällä” kertoo yksinään vähän.

Miksi tekoälyn kirjoittama koodi epäonnistuu pääsynhallinnassa?

Agenttia palkitaan koodista, joka toimii. Tyhjä lista tai 401 näyttää viasta, ja korjaus, joka saa sen katoamaan, on usein se, joka avaa pääsyn. arXiv-tutkimus jäljittää 1 186 löydöstään kahdeksaan toistuvaan virhetapaan, jotka on ryhmitelty agenttien muisti-, tavoite- ja tietopuutteiksi, ja havaitsi, että parempi promptaus vähensi aukkojen määrää mutta ei poistanut niitä.

Toinen syy on arkkitehtuuri. Lovable- tai Bolt-sovelluksella ei yleensä ole omaa backendiä: selain puhuu suoraan tietokannalle Data API:n kautta. Jokaisen asiakasdataa suojaavan säännön on asuttava Postgresissa oikeuksina (grants), politiikkoina ja funktioina, eikä mikään niistä näy sovelluksen esikatselussa, jossa olet kirjautuneena omistajana. Supabase muuttaa tässä yhtä oletusta: 30. lokakuuta 2026 alkaen uudet taulut olemassa olevissa projekteissa eivät enää saa Data API -oikeuksia automaattisesti. Omalla stackillani taulu ilman oikeutta vastasi 42501 permission denied ja vihjeellä, joka nimeää puuttuvan GRANT-lauseen. Se pysäyttää uusien taulujen kohdalla yllä olevan taulukon ensimmäisen rivin, mutta ei neljää muuta, eikä jo olemassa olevia tauluja.

Mikä muu menee pieleen tietokannan ulkopuolella?

Samat tutkimukset listaavat riskejä, joilla ei ole mitään tekemistä RLS:n kanssa:

• Salaisuudet bundlessa. Escape löysi yli 400 paljastunutta salaisuutta, muun muassa OpenAI-avaimia ja maksujen ylläpitoavaimia. Kaikki, mitä selaimelle lähetetään, on julkista.
• Reittisuojat vain Reactissa. Sivu, joka ohjaa uloskirjautuneet pois, on silti API:n edessä, joka vastaa kenelle tahansa.
• Nopeusrajoitukset, jotka eivät koskaan laukea. Tutkimassani hostatussa Supabase-projektissa edge functionin muistissa pidetty laskuri nollautui jokaisella pyynnöllä. Kirjoitin siitä Lovable-sovelluksen tietoturvatarkistuslistassani.
• Vanhat kirjastot. Escape laski 254 haavoittuvaa JavaScript-kirjastoinstanssia julkisissa resursseissa, usein pohjista perittyinä.

Miten vibe coding -sovelluksen tarkistaa?

1. Avaa sovellus, avaa DevTools → Network ja etsi pyynnöt osoitteeseen /rest/v1/. Kopioi yksi cURL-komentona, poista Authorization-header, jätä apikey ja aja se. Jos dataa tulee takaisin, se tulee kenelle tahansa.
2. Etsi rakennetusta JavaScriptistä merkkijonoja sb_secret_ ja service_role. Osuma on avain, joka pitää kiertää tänään.
3. Aja ilmainen Supabase-tietoturvatarkistus. Se lukee projektin katalogin ja liputtaa 46 säännön joukosta “RLS pois päältä julkaistuissa tauluissa”, “Käytännöt, jotka päästävät läpi jokaisen rivin”, “RLS:n ohittavat näkymät” ja “Oletusoikeudet, jotka avaavat uudet objektit API:lle”: yllä olevan taulukon neljä ensimmäistä riviä.
4. Testaa kahdella käyttäjällä kahdessa yrityksessä, ainoa testi, jota skanneri ei voi tehdä puolestasi. Miten teen sen, kerron Lovable-tarkistuslistassa, ja Supabase RLS:n testaus näyttää menetelmän tuotantosovelluksessa, jossa on oikeuksien hallintanäkymä.

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

Mitä tämä ei osoita

Toistoni on yksi taulu paikallisella stackilla, rakennettu näyttämään kukin mekanismi, ei oikeiden sovellusten skannaus. Yleisyysluvut tulevat kolmesta tutkimuksesta, joilla jokaisella on oma otoksensa ja menetelmänsä, linkitettynä yllä. Eikä puhdas tulos näissä viidessä tarkistuksessa tee sovelluksesta turvallista: logiikkavirheet, kuten suoja, joka päästää puuttuvan arvon läpi, tarvitsevat omat testinsä. Yksi sellainen on NULL, joka ohitti oikeustarkistuksen.