--- title: "Vibe coding: säkerhetsrisker och 5 hål jag återskapade" description: "Vad som går fel i vibe-kodade appar, med siffror från tre studier och fem åtkomsthål jag återskapade lokalt på Supabase, och hur du kontrollerar din." url: "https://madsalt.tech/sv/blog/vibe-coding-security-risks/" author: "Denys Zaichenko" language: "sv" published: 2026-10-24 --- # Vibe coding: säkerhetsrisker och 5 hål jag återskapade Kort sagt Koden en AI skriver fungerar oftast. Det som brister är vem som kommer åt datan. I en granskning 2026 av 200 driftsatta vibe-kodade appar hade 91 % minst en sårbarhet, och bruten åtkomstkontroll var den största gruppen. Jag återskapade fem av åtkomsthålen på en lokal Supabase-stack: med bara den publika nyckeln gav en tabell utan RLS, en alltid sann policy, en vy och en läckt secret key alla 3 av 3 rader. Kontrollera din app för dessa först. 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](https://arxiv.org/abs/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](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/), 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](https://www.veracode.com/resources/analyst-reports/2026-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. ![Vad en publik nyckel fick från en tabell. Lokal Supabase, 3 rader falska beställningar, en förfrågan vardera. Tabell utan RLS: Publishable key → orders, RLS av → 3 av 3 rader; RLS på, ingen policy än: Publishable key → orders, RLS på → 0 rader; Policy using (true): Publishable key → using (true) → 3 av 3 rader; Vy utan security_invoker: Publishable key → order_summary-vyn → 3 av 3 rader; Secret key i webbläsarkoden: Secret key → BYPASSRLS → 3 av 3 rader.](https://madsalt.tech/charts/sv/vibe-coding-security-risks.svg) *Figur 1. Min reproduktion på en lokal Supabase-stack (Postgres 17.6, PostgREST 14.14), 23 oktober 2026.* | 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](https://supabase.com/changelog/45329-breaking-change-tables-not-exposed-to-data-and-graphql-api-automatically) 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](https://madsalt.tech/sv/blog/lovable-app-security-checklist/). - **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](https://madsalt.tech/sv/tools/supabase-security-check/). 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](https://madsalt.tech/sv/blog/lovable-app-security-checklist/), och [hur du testar Supabase RLS](https://madsalt.tech/sv/blog/how-to-test-supabase-rls/) visar metoden på en produktionsapp med en behörighetsskärm. ```bash curl 'https://.supabase.co/rest/v1/orders?select=*' \ -H 'apikey: ' ``` ## 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](https://madsalt.tech/sv/notes/plpgsql-if-not-null-fails-open/). Byggde du din app med ett AI-verktyg? Jag jämför gärna erfarenheter om vad som bör kontrolleras först. Ingen säljpitch. [Hör av dig](https://madsalt.tech/sv/#contact)