--- title: "Vibe coding -tietoturvariskit: 5 aukkoa, jotka toistin" description: "Mikä menee pieleen vibe coding -sovelluksissa: kolmen tutkimuksen luvut ja viisi paikallisesti toistamaani pääsyaukkoa sekä oman sovelluksesi tarkistus." url: "https://madsalt.tech/fi/blog/vibe-coding-security-risks/" author: "Denys Zaichenko" language: "fi" published: 2026-10-24 --- # Vibe coding -tietoturvariskit: 5 aukkoa, jotka toistin TL;DR Tekoälyn kirjoittama koodi yleensä toimii. Pieleen menee se, kuka pääsee käsiksi dataan. Vuoden 2026 auditoinnissa 200 käyttöön otetusta vibe coding -sovelluksesta 91 %:ssa oli vähintään yksi haavoittuvuus, ja rikkinäinen pääsynhallinta oli suurin ryhmä. Toistin viisi pääsyaukkoa paikallisella Supabase-stackilla: pelkällä julkisella avaimella taulu ilman RLS:ää, aina tosi politiikka, view ja vuotanut secret key antoivat kukin kaikki 3 riviä 3:sta. Tarkista sovelluksesi ensin näiden varalta. 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](https://arxiv.org/abs/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](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/), 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](https://www.veracode.com/resources/analyst-reports/2026-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. ![Mitä yksi julkinen avain sai yhdestä taulusta. Paikallinen Supabase, 3 riviä tekaistuja tilauksia, yksi pyyntö kutakin. Taulu ilman RLS:ää: Publishable key → orders, RLS pois → 3/3 riviä; RLS päällä, ei vielä politiikkaa: Publishable key → orders, RLS päällä → 0 riviä; Politiikka using (true): Publishable key → using (true) → 3/3 riviä; View ilman security_invoker: Publishable key → order_summary-view → 3/3 riviä; Secret key selaimen koodissa: Secret key → BYPASSRLS → 3/3 riviä.](https://madsalt.tech/charts/fi/vibe-coding-security-risks.svg) *Kuva 1. Toistoni paikallisella Supabase-stackilla (Postgres 17.6, PostgREST 14.14), 23. lokakuuta 2026.* | 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](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) 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](https://madsalt.tech/fi/blog/lovable-app-security-checklist/). - **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](https://madsalt.tech/fi/tools/supabase-security-check/). 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](https://madsalt.tech/fi/blog/lovable-app-security-checklist/), ja [Supabase RLS:n testaus](https://madsalt.tech/fi/blog/how-to-test-supabase-rls/) näyttää menetelmän tuotantosovelluksessa, jossa on oikeuksien hallintanäkymä. ```bash curl 'https://.supabase.co/rest/v1/orders?select=*' \ -H 'apikey: ' ``` ## 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](https://madsalt.tech/fi/notes/plpgsql-if-not-null-fails-open/). Rakensitko sovelluksesi tekoälytyökalulla? Vertaan mielelläni kokemuksia siitä, mitä kannattaa tarkistaa ensin. Ei myyntipuhetta. [Ota yhteyttä](https://madsalt.tech/fi/#contact)