Vibe coding: sikkerhetsrisikoer og 5 hull jeg reproduserte

Jeg er Denys, fullstack- og AI-ingeniør. Jeg retter opp apper som er bygget med Lovable, Bolt, Cursor eller Claude Code, og de fleste kjører på Supabase. Denne artikkelen samler det publisert forskning sier om sikkerhet ved vibe coding, og det jeg så da jeg med vilje bygget opp igjen de vanligste feilene.

Hva er sikkerhetsrisikoene ved vibe coding?

Hovedrisikoen er brutt tilgangskontroll: data som alle besøkende kan lese eller endre fordi regelen som skulle stoppe dem mangler, er for løs eller blir omgått. Injeksjon og svak autentisering kommer deretter. Tre uavhengige studier peker i samme retning:

Studie	Hva som ble testet	Hva den fant
Deng, Fan og Meng, arXiv 2606.23130, juni 2026	200 utrullede apper bygget med Claude Code og Lovable, revidert for hånd og med agenter	182 av 200 apper (91 %) hadde minst én sårbarhet; 65,77 % av de 1 186 funnene var Critical eller High; brutt tilgangskontroll var den største kategorien, i 64 % av appene
Escape, oktober 2025	5 600 offentlige apper fra Lovable, Base44, Create.xyz og andre, passiv skanning	Over 2 000 sårbarheter med høy innvirkning, over 400 eksponerte hemmeligheter, 175 tilfeller av eksponerte personopplysninger; hovedårsaken var feilkonfigurerte tilganger, særlig Supabase RLS
Veracode GenAI Code Security Report, 2025 og 2026	80 kodeoppgaver gitt til over 100 modeller	Bare 55 % av oppgavene ga sikker kode i 2025; gjennomsnittlig bestått-andel var 56 % i 2026, uendret på tvers av modellstørrelser og år

Studiene måler ulike ting, så prosentene lar seg ikke slå sammen til ett tall. Det de har felles, er mønsteret: koden fungerer, og hullene sitter i tillitsgrensen.

Hvilke hull reproduserte jeg?

Jeg satte opp én tabell, orders, med tre rader med falske kunder på en lokal Supabase-stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14). Så kalte jeg Data API-et slik en nettleser gjør, med publishable key som hver Supabase-frontend leverer med, og endret én ting om gangen.

Oppsett	Hva den offentlige nøkkelen fikk	Hvorfor
Tabell uten RLS	Alle 3 rader, og en insert ga 201 Created	Standardtilgangene lar anon lese og skrive, og ingenting filtrerer rader
RLS på, ingen policy	[], en tom liste	RLS uten policy nekter alt for anon og authenticated
Policy using (true)	Alle 3 rader	Policyen finnes, så tabellen ser beskyttet ut, men den slipper inn hver rad
View over den beskyttede tabellen	Alle 3 rader	En view kjører med eierens rettigheter med mindre den har security_invoker = true; med den får du []
Secret key i frontend-kode	Alle 3 rader	Secret key tilsvarer service_role, som har BYPASSRLS

Den andre raden er det farlige øyeblikket. RLS er på, og appen viser en tom liste, så den ser ødelagt ut. Den raskeste prompten som “fikser” det, er en policy som slipper alt inn, og det er den tredje raden. Den løkken, feil og så en rettelse som utvider tilgangen, er mønsteret jeg oftest møter i vibe-kodede apper, og det er grunnen til at “RLS er på” sier lite alene.

Hvorfor svikter AI-skrevet kode på tilgangskontroll?

En agent belønnes for kode som kjører. En tom liste eller en 401 ser ut som en feil, og rettelsen som får den til å forsvinne, er ofte den som åpner tilgangen. arXiv-studien sporer de 1 186 funnene til åtte tilbakevendende feilmodi, gruppert som minne-, mål- og kunnskapsdefekter hos agentene, og fant at bedre prompting reduserte antallet hull, men ikke fjernet dem.

Den andre grunnen er arkitekturen. En Lovable- eller Bolt-app har som regel ingen egen backend: nettleseren snakker rett med databasen gjennom Data API-et. Hver regel som beskytter kundedata må ligge i Postgres, som tilganger (grants), policyer og funksjoner, og ingenting av det er synlig i forhåndsvisningen av appen, der du er innlogget som eier. Supabase endrer én standard her: fra 30. oktober 2026 får nye tabeller i eksisterende prosjekter ikke lenger automatisk tilgang til Data API-et. På stacken min svarte en tabell uten tilgangen 42501 permission denied med et hint som nevner den manglende GRANT. Det stopper den første raden i tabellen over for nye tabeller, men ikke de fire andre, og ikke tabeller som allerede finnes.

Hva annet går galt utenfor databasen?

De samme studiene lister risikoer som ikke har noe med RLS å gjøre:

• Hemmeligheter i bundelen. Escape fant over 400 eksponerte hemmeligheter, blant dem OpenAI-nøkler og admin-nøkler for betaling. Alt som sendes til nettleseren, er offentlig.
• Rutevern bare i React. En side som sender utloggede brukere videre, har fortsatt et API bak seg som svarer alle.
• Rate limits som aldri slår inn. På et hostet Supabase-prosjekt jeg undersøkte, ble en teller i minnet til en edge function nullstilt ved hver forespørsel. Det skrev jeg om i sikkerhetsjekklisten min for Lovable-apper.
• Gamle biblioteker. Escape telte 254 sårbare JavaScript-biblioteksinstanser i offentlige ressurser, ofte arvet fra maler.

Hvordan sjekker du en vibe-kodet app?

1. Åpne appen, åpne DevTools → Network og finn forespørsler til /rest/v1/. Kopier en som cURL, fjern Authorization-headeren, behold apikey, og kjør den. Kommer det data tilbake, gjør det det for hvem som helst.
2. Søk i den bygde JavaScript-en etter sb_secret_ og service_role. Et treff er en nøkkel du må rotere i dag.
3. Kjør den gratis Supabase-sikkerhetssjekken. Den leser prosjektets katalog og flagger, blant 46 regler, “RLS slått av på eksponerte tabeller”, “Policyer som slipper inn alle rader”, “Views som omgår RLS” og “Standardrettigheter som åpner nye objekter for API-et”: de fire første radene i tabellen over.
4. Test med to brukere i to selskaper, den ene testen en skanner ikke kan gjøre for deg. Hvordan jeg gjør det, står i Lovable-sjekklisten, og hvordan du tester Supabase RLS viser metoden på en produksjonsapp med en tilgangsskjerm.

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

Hva dette ikke viser

Reproduksjonen min er én tabell på en lokal stack, bygget for å vise hver mekanisme, ikke en skanning av ekte apper. Utbredelsestallene kommer fra de tre studiene, hver med sitt eget utvalg og sin egen metode, lenket over. Og et rent resultat på disse fem sjekkene gjør ikke en app trygg: logikkfeil, som et vern som slipper gjennom en manglende verdi, trenger egne tester. Én slik står i en NULL som hoppet over en tilgangssjekk.