Vilka säkerhetsrutiner behöver du känna till innan du vibe-kodar?

Det finns fem säkerhetsrutiner att känna till innan du vibe-kodar: hantera hemligheter utanför koden, granska inloggning och åtkomst, testa all inmatning, säkra beroenden och kontrollera vad som faktiskt ligger publikt. Hur lätt det går fel visar en granskning där 170 av 1 645 appar byggda med ett populärt AI-verktyg lät vem som helst läsa personuppgifter.

Varför vibe-kodning ändrar säkerhetsbilden

Med AI-assistenter skriver du kod du inte själv har läst igenom, och det är just där säkerhetsfelen gömmer sig. Vibe-kodning, att beskriva vad du vill ha med vanliga ord och låta AI:n skriva koden, är ett ungt begrepp som Andrej Karpathy myntade i februari 2025. Tanken är att du styr på känsla och resultat i stället för att läsa varje rad.

Problemet är att AI ofta skriver dålig kod som ser bra ut.

Granskningen försvinner.

När en app växer fram på en eftermiddag hinner ingen fråga vem som får läsa databasen, och appen ser lika färdig ut oavsett om svaret är rätt.

Det är vad som hände i fallet med svenska Lovable. Som Wikipedias genomgång av vibe-kodning beskriver rapporterades i maj 2025 att 170 av 1 645 appar byggda i verktyget hade ett fel som gjorde personlig information åtkomlig för vem som helst. Det motsvarar ungefär en app av tio. Apparna fungerade som de skulle för sina ägare, och felet syntes bara för den som letade.

Rutin 1: håll hemligheter utanför koden

Lägg aldrig API-nycklar och lösenord i kod som AI genererar eller i kod du delar. Använd miljövariabler och en hemlighetshanterare. En nyckel som har hamnat i en publik kodbas ska räknas som stulen, även om du raderar den efteråt. Det finns automatiska sökrobotar som letar efter just sådana nycklar, och den gamla versionen ligger kvar i Git-historiken, alltså projektets sparade logg över alla ändringar.

Så flyttar du en hemlighet ut ur koden:

1. Skapa en .env-fil i projektets rotmapp, en vanlig textfil med rader som API_NYCKEL=.... Det är din lokala förvaring av hemligheter.
2. Lägg till .env i .gitignore innan du gör nästa commit, så att filen aldrig följer med upp till GitHub eller liknande.
3. Läs in värdet som en miljövariabel, en inställning som programmet hämtar från omgivningen när det körs, i stället för att skriva nyckeln direkt i koden. Be gärna AI:n uttryckligen: ”läs nyckeln från en miljövariabel”.
4. Lägg in hemligheten i värdtjänstens inställningar när du publicerar. Nästan alla tjänster har ett fält för miljövariabler eller en inbyggd hemlighetshanterare.
5. Sök igenom koden efter ord som key, secret, token och password innan du delar den. AI-verktyg klistrar ibland in ett exempelvärde som råkar vara din riktiga nyckel.

Har du redan råkat committa en nyckel gäller en tumregel: rotera först, städa sedan. Gå direkt till tjänsten som utfärdade nyckeln, spärra den och skapa en ny.

Det ska ta minuter, inte dagar.

Att skriva om Git-historiken går att göra efteråt, men det skyddar inte mot den som redan har hunnit kopiera nyckeln.

Rutin 2: granska inloggning och åtkomst

Kontrollera själv vem som kan läsa och ändra vad i din app. AI bygger ofta åtkomstregler som ser rimliga ut men släpper igenom för mycket. Autentisering betyder att appen kontrollerar vem du är, alltså inloggningen. Behörighet avgör vad du får göra när du väl är inne. De flesta fel sitter i det andra ledet: appen vet att du är inloggad men glömmer att kontrollera om datan faktiskt är din.

Det räcker inte att dölja knappar i gränssnittet. En dold ”radera”-knapp hindrar bara den som klickar. Den som skickar förfrågan direkt till servern når samma funktion. Kontrollen måste därför ligga på serversidan eller i databasens regler, där användaren inte kan ändra reglerna.

Ett test på några minuter avslöjar den vanligaste typen av fel. Testet passar en app där varje användare har en profil med namn och e-post, som i Lovable-apparna:

1. Skapa två testkonton, A och B, och fyll båda med påhittad data.
2. Logga in som A och öppna webbläsarens utvecklarverktyg (F12), fliken Nätverk. Ladda om din profilsida.
3. Leta upp förfrågan som hämtar profilen. Den innehåller ofta ett id eller en adress som /profiles?id=123.
4. Byt id:t till B:s id och skicka förfrågan igen, via adressfältet eller med ”Kopiera som fetch” i konsolen. Får du B:s namn och e-post tillbaka har appen inga behörighetskontroller.
5. Logga ut helt och skicka samma förfrågan en gång till. Kommer det data tillbaka är tabellen öppen för hela internet.
6. Prova att ändra i stället för att läsa. Skicka en uppdatering av B:s profil från A:s konto. Att läsa kan vara ofarligt, men att skriva i andras data får aldrig gå.

Går något av stegen igenom ber du AI:n att lägga till behörighetsregler i databasen, till exempel row level security i Supabase, så att varje rad bara kan läsas av sin ägare. Kör sedan testet igen.

Rutin 3: validera all inmatning

Lita aldrig på data från användare, formulär eller URL:er. Validera och rensa den på servern, inte bara i webbläsaren. Validering betyder att du kontrollerar att datan ser ut som den ska, till exempel att en ålder är ett tal mellan 0 och 120. Validering i webbläsaren är bra för användaren, som får besked direkt, men den skyddar inte appen.

Tänk dig ett formulär där fältet ”antal” bara tillåter 1 till 10. Webbläsaren stoppar den som skriver 500. Men samma förfrågan kan skickas med ett kommandoradsverktyg som curl, ett skript eller utvecklarverktygen, helt utan formuläret. Servern ser bara datan och vet inte var den kom ifrån. Kontrollerar servern inte själv går 500, eller minus 500, rakt igenom.

Den farligaste varianten är injektion, där inmatningen tolkas som kommandon i stället för som text. SQL-injektion är det klassiska exemplet. Om appen bygger sin databasfråga genom att klistra ihop text, ungefär ”hämta användaren som heter” plus det som skrevs i fältet, kan någon skriva in en bit SQL-kod som ändrar hela frågan. Resultatet blir att frågan hämtar alla användare i stället för en. Skyddet heter parametriserade frågor: databasen får frågan och värdet var för sig och behandlar värdet alltid som text. Moderna ramverk gör detta som standard, men AI-genererad kod hoppar ibland över det när den skriver ”snabba” lösningar. Be AI:n bekräfta att alla databasfrågor är parametriserade. Samma logik gäller text som visas för andra användare, där inskickad kod annars kan köras i deras webbläsare. Låt servern rensa eller koda om sådan text innan den visas.

Rutin 4: håll beroenden uppdaterade och granskade

AI föreslår ofta paket du inte valt själv. Kontrollera varje beroende innan du installerar det och uppdatera regelbundet. Ett beroende är färdig kod från någon annan som din app använder, till exempel ett paket från npm eller PyPI. Det kör med samma rättigheter som din egen kod. Ett enda gammalt eller skadligt paket kan därför ta över hela appen, även om allt du själv har skrivit är korrekt.

En särskild risk med AI är att den ibland hittar på paketnamn som låter rimliga. Angripare registrerar sådana namn i förväg och fyller dem med skadlig kod. Innan du kör npm install eller pip install på något AI:n föreslog, gå igenom de här frågorna:

• Finns paketet och stavas det exakt rätt? Sök upp det på npmjs.com eller pypi.org. Ett namn som skiljer sig med en bokstav från ett känt paket är en varningssignal.
• Används det av många? Ett paket med miljontals nedladdningar i veckan är granskat av fler ögon än ett med ett dussin.
• Underhålls det? Kolla när den senaste versionen kom. Ett paket som inte har uppdaterats på flera år har sannolikt kända brister som ingen åtgärdar.
• Har det kända sårbarheter? En sårbarhet är en känd säkerhetsbrist. Kör npm audit eller pip-audit efter installationen, så listas de.
• Behövs det alls? Många förslag löser sådant som språket redan klarar själv. Varje paket du slipper är ett mindre att hålla koll på.

Uppdateringsrutinen kan vara enkel. Slå på Dependabot eller motsvarande i GitHub, som skickar förslag när ett beroende har en säkerhetsfix, och kör en granskning ungefär en gång i månaden. Det räcker för ett hobbyprojekt. Har appen riktiga användare och persondata, kör den varje vecka.

Rutin 5: kontrollera vad som ligger publikt

Innan du publicerar, kontrollera vilka sidor, filer och databastabeller som är öppna för alla. Standardinställningar är ofta för generösa, eftersom verktygen vill att allt ska fungera direkt. Publik åtkomst betyder att något kan nås utan inloggning. Det passar en startsida men inte en kundlista. AI-verktyg skiljer inte alltid på de två, och många fel upptäcks först när någon utomstående hittar dem.

Kolla fyra ställen innan du går live. I databasen ska varje tabell ha uttryckliga regler för läsning och skrivning, och en tabell utan regler ska ses som öppen. I fillagringen, där uppladdade bilder och dokument hamnar, ska du kontrollera om lagringsytan är publik och om filnamnen går att gissa. Webbservern får inte servera .env, säkerhetskopior eller en .git-mapp. Prova att skriva in adresserna direkt i webbläsaren. Felmeddelandena ska vara korta för besökaren. Detaljerade fel med databasnamn och sökvägar hör hemma i loggen.

Efter lanseringen behövs en enkel övervakning: titta i loggarna efter ovanligt många förfrågningar och sätt upp en larmadress som någon faktiskt läser. Driver du ett företag och ska koppla en sådan app till kunddata hör den här genomgången hemma i samma planering som när du digitaliserar ditt småföretag i övrigt.

Hittar du ett fel gör du tre saker i ordning. Åtgärda det, så att hålet stängs först. Rotera sedan alla nycklar och lösenord som kan ha exponerats. Informera till sist de berörda. Har persondata läckt är det dessutom en personuppgiftsincident, och då gäller Integritetsskyddsmyndighetens regler för anmälan.

Bygger du bara för att lära dig räcker det att köra rutinerna före varje publicering. Samlar appen in andras namn, e-post eller betalningar bör du köra åtkomsttestet efter varje ändring AI:n gör i databasen.