Vibe coding: säkerhetsrisker och 5 hål jag återskapade

Jag heter Denys och är full-stack- och AI-ingenjör. Jag rättar till appar som byggts med Lovable, Bolt, Cursor eller Claude Code, och de flesta körs på Supabase. Den här artikeln samlar vad publicerad forskning säger om säkerhet vid vibe coding, och vad jag såg när jag med flit byggde upp de vanliga misstagen igen.

Vilka är säkerhetsriskerna med vibe coding?

Huvudrisken är bruten åtkomstkontroll: data som vilken besökare som helst kan läsa eller ändra eftersom regeln som skulle stoppa dem saknas, är för lös eller kringgås. Injektion och svag autentisering kommer därefter. Tre oberoende studier pekar åt samma håll:

Studie	Vad som testades	Vad den fann
Deng, Fan och Meng, arXiv 2606.23130, juni 2026	200 driftsatta appar byggda med Claude Code och Lovable, granskade för hand och med agenter	182 av 200 appar (91 %) hade minst en sårbarhet; 65,77 % av de 1 186 fynden var Critical eller High; bruten åtkomstkontroll var den största kategorin, i 64 % av apparna
Escape, oktober 2025	5 600 publika appar från Lovable, Base44, Create.xyz och andra, passiv skanning	Över 2 000 sårbarheter med hög påverkan, över 400 exponerade hemligheter, 175 fall av exponerade personuppgifter; huvudorsaken var felkonfigurerade behörigheter, särskilt Supabase RLS
Veracode GenAI Code Security Report, 2025 och 2026	80 kodningsuppgifter givna till över 100 modeller	Bara 55 % av uppgifterna gav säker kod 2025; den genomsnittliga godkändandelen var 56 % 2026, oförändrad över modellstorlekar och år

Studierna mäter olika saker, så procentsatserna går inte att summera till ett tal. Det de delar är mönstret: koden fungerar, och hålen sitter i förtroendegränsen.

Vilka hål återskapade jag?

Jag skapade en tabell, orders, med tre rader falska kunder på en lokal Supabase-stack (CLI 2.109.1, Postgres 17.6, PostgREST 14.14). Sedan anropade jag Data API:et som en webbläsare gör, med den publishable key som varje Supabase-frontend levererar, och ändrade en sak i taget.

Upplägg	Vad den publika nyckeln fick	Varför
Tabell utan RLS	Alla 3 rader, och en insert gav 201 Created	Standardbehörigheterna låter anon läsa och skriva, och inget filtrerar rader
RLS på, ingen policy	[], en tom lista	RLS utan policy nekar allt för anon och authenticated
Policy using (true)	Alla 3 rader	Policyn finns, så tabellen ser skyddad ut, men den släpper in varje rad
Vy över den skyddade tabellen	Alla 3 rader	En vy körs med ägarens rättigheter om den inte har security_invoker = true; med den får du []
Secret key i frontend-kod	Alla 3 rader	Secret key motsvarar service_role, som har BYPASSRLS

Den andra raden är det farliga ögonblicket. RLS är på och appen visar en tom lista, så den ser trasig ut. Den snabbaste prompten som “fixar” det är en policy som släpper in allt, och det är den tredje raden. Den slingan, fel och sedan en rättning som vidgar åtkomsten, är mönstret jag oftast möter i vibe-kodade appar, och det är därför “RLS är på” säger så lite i sig.

Varför brister AI-skriven kod på åtkomstkontroll?

En agent belönas för kod som körs. En tom lista eller en 401 ser ut som en bugg, och rättningen som får den att försvinna är ofta den som öppnar åtkomsten. arXiv-studien spårar sina 1 186 fynd till åtta återkommande felmoder, grupperade som minnes-, mål- och kunskapsdefekter hos agenterna, och fann att bättre prompting minskade antalet hål men inte tog bort dem.

Den andra orsaken är arkitekturen. En Lovable- eller Bolt-app har oftast ingen egen backend: webbläsaren pratar direkt med databasen via Data API:et. Varje regel som skyddar kunddata måste ligga i Postgres, som behörigheter (grants), policyer och funktioner, och inget av det syns i appens förhandsvisning, där du är inloggad som ägare. Supabase ändrar en standard här: från 30 oktober 2026 får nya tabeller i befintliga projekt inte längre automatiskt behörighet till Data API:et. På min stack svarade en tabell utan behörigheten 42501 permission denied med en ledtråd som nämner den saknade GRANT. Det stoppar den första raden i tabellen ovan för nya tabeller, men inte de andra fyra, och inte tabeller som redan finns.

Vad mer går fel utanför databasen?

Samma studier listar risker som inte har med RLS att göra:

• Hemligheter i bundlen. Escape fann över 400 exponerade hemligheter, bland dem OpenAI-nycklar och admin-nycklar för betalning. Allt som skickas till webbläsaren är publikt.
• Ruttskydd bara i React. En sida som skickar vidare utloggade användare har fortfarande ett API bakom sig som svarar vem som helst.
• Rate limits som aldrig slår till. På ett hostat Supabase-projekt jag undersökte nollställdes en räknare i en edge functions minne vid varje förfrågan. Det skrev jag om i min säkerhetschecklista för Lovable-appar.
• Gamla bibliotek. Escape räknade 254 sårbara JavaScript-biblioteksinstanser i publika tillgångar, ofta ärvda från mallar.

Hur kontrollerar du en vibe-kodad app?

1. Öppna appen, öppna DevTools → Network och hitta förfrågningar till /rest/v1/. Kopiera en som cURL, ta bort Authorization-headern, behåll apikey och kör den. Om data kommer tillbaka gör den det för vem som helst.
2. Sök i den byggda JavaScript-filen efter sb_secret_ och service_role. En träff är en nyckel att rotera i dag.
3. Kör den gratis Supabase-säkerhetskontrollen. Den läser projektets katalog och flaggar, bland 46 regler, “RLS avstängt på exponerade tabeller”, “Policyer som släpper in varje rad”, “Vyer som kringgår RLS” och “Standardbehörigheter som öppnar nya objekt för API:t”: de fyra första raderna i tabellen ovan.
4. Testa med två användare i två företag, det enda test en skanner inte kan göra åt dig. Hur jag gör det finns i Lovable-checklistan, och hur du testar Supabase RLS visar metoden på en produktionsapp med en behörighetsskärm.

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

Vad detta inte visar

Min reproduktion är en tabell på en lokal stack, byggd för att visa varje mekanism, inte en skanning av riktiga appar. Förekomsttalen kommer från de tre studierna, var och en med eget urval och egen metod, länkade ovan. Och ett rent resultat på dessa fem kontroller gör inte en app säker: logikfel, som ett skydd som släpper igenom ett saknat värde, behöver egna tester. Ett sådant finns i en NULL som hoppade över en behörighetskontroll.