Databassäkerhet i vibe-kodning: När alla blev utvecklare och började bygga sina egna applikationer
AI-verktygens framfart har medfört en ny verklighet för datahantering i organisationer. Marknadsavdelningar, produktteam och till och med HR skapar idag egna applikationer, ofta utan IT-avdelningens involvering. Verktyg som Claude Opus, Cursor, Lovable och GitHub Copilot gör det möjligt för icke-utvecklare att generera fungerande backend-kod på minuter. Problemet är att dessa snabbbyggen ofta saknar såväl åtkomstkontroll som grundläggande säkerhetspolicys.
En databas är inte längre ett verktyg reserverat för tekniska team. Supabase, Airtable, Google Sheets och andra gränssnittslösningar har gjort det lika enkelt att bygga en databas som att skapa ett kalkylark. Men i takt med att verktygen blir mer tillgängliga, blir riskerna för dataläckor och angrepp allt mer affärskritiska. Företagets data har lämnat serverrummet och blivit decentraliserad, men ansvaret förblir kollektivt.
Från kodgenerator till produktionssystem på tio minuter
I hjärtat av varje modern applikation finns ett backendlager som hanterar affärslogik, datalagring och åtkomst. När backend utvecklas via AI och vibe-kodning är det ofta databasen som står i centrum – men också där sårbarheterna börjar. För att göra backend-utveckling säker krävs ett systematiskt angreppssätt: databaser måste skyddas med explicita åtkomstpolicys, API-anrop måste filtreras och autentiseras, och miljövariabler måste hanteras på ett säkert sätt. Utan dessa skyddslager blir även en enkel applikation en potentiell attackyta.
Det som tidigare krävde veckor av backendutveckling går idag att åstadkomma via en prompt. AI-verktyg som Claude Opus och Cursor kan generera kompletta backendmiljöer med kopplingar till Supabase, PostgreSQL eller MySQL. Men dessa verktyg saknar alltid förkonfigurerad säkerhet. Standardkod är ofta för generisk, och nycklar hårdkodas direkt i klientkoden.
Dessutom laddas kodfiler och miljövariabler ofta upp till GitHub utan versionshantering eller behörighetskontroll. Filer som .env hamnar i publika repositories, och API-nycklar indexeras av sökmotorer. I takt med att utveckling blir promptdriven, förskjuts fokus från systemarkitektur till funktion – på bekostnad av säkerhet.
Den nya utvecklaren: från idé till applikation – på några timmar
En av de mest genomgripande förändringarna i dagens utvecklingslandskap är att fler bygger än någonsin förut. Verktyg som Lovable, Bolt, Cursor och andra AI-baserade plattformar i kombination med vibe-kodning har sänkt tröskeln till digital utveckling radikalt. Det som tidigare krävde kodkunskap, devops-kedjor och konfigurationsarbete kan idag göras av vem som helst med en uppkoppling och en idé.
Det betyder att nya applikationer föds varje dag ur personliga behov, passion och nyfikenhet. Många är meningsfulla, en del är triviala – men alla delar samma grundrisk: de hamnar ofta utanför IT:s radar.
Det handlar inte längre om skugg-IT i traditionell bemärkelse. Det handlar om en kulturell förflyttning där teknik blivit så tillgänglig att varje team och individ kan skapa digitala verktyg på egen hand. Men utan ramar för kodgranskning, dataskydd och åtkomstkontroll kan dessa initiativ snabbt förvandlas från inspiration till attackyta.
Denna utveckling sammanfaller med det som Andrej Karpathy i början av 2025 beskrev som ”vibe-kodning” – en samtalsbaserad kodstil där programmeraren inte längre skriver kod rad för rad, utan istället för dialog med en stor språkmodell som genererar färdig funktionalitet. Programmerarens roll blir att formulera syftet, testa resultaten och iterera, snarare än att själv implementera varje detalj.
Vibe-kodning har redan börjat omforma hur vi ser på utveckling. Den lockar in fler i det skapande ekosystemet, vilket är både kraftfullt och sårbart. Det som tidigare var en teknisk disciplin blir nu tillgängligt genom språk, och gränsen mellan användare och utvecklare suddas ut.
Samtidigt öppnar det upp för något positivt: ett bredare deltagande i digital utveckling, där fler får en röst i hur system formas. Den centrala frågan blir då inte om vi ska tillåta dessa initiativ, utan hur vi stöder dem med rätt ramverk, verktyg och ansvarsfördelning.
Supabase och PostgreSQL: när default blir farligt
Supabase är idag en populär val för att bygga moderna applikationer utan att behöva sätta upp en egen databas. Men få känner till att Supabase tillåter öppen åtkomst till tabeller om Row Level Security (RLS) inte är aktiverat. Det innebär att en enkel SELECT-fråga kan returnera hela kunddatabasen om policys inte uttryckligen satts. Det är ett scenario vi ser gång på gång när applikationer utvecklas utanför IT.
PostgreSQL har förvisso avancerade säkerhetsfunktioner, men dessa kräver aktiv implementation. RLS, åtkomstroller, audit-loggning och datakryptering är alla tekniker som ofta får stå tillbaka i jakten på snabba MVP:er. Det finns ett glapp mellan vad systemet möjliggör och vad organisationer faktiskt implementerar.
MySQL: etablerad men fortfarande sårbar
MySQL används än idag i tusentals applikationer och är ofta förstahandsval för enklare webbprojekt. Men det är också en av de databaser där äldsta säkerhetsbristerna lever kvar.
För breda privilegier (”GRANT ALL”), root-användare utan lösenord, fjärranslutning utan IP-begränsningar och brist på SSL-anslutning är fortfarande vanligt förekommande. Många team missar även att konfigurera regelbunden backup, och få har testat återställning vid incident.
GitHub: koddelning utan kontroll
GitHub fungerar idag inte bara som versionshanterare utan även som kodlager för hela applikationer. Det innebär att felhantering i repository-konfiguration snabbt kan få allvarliga konsekvenser.
Vi ser ofta att .env-filer, API-nycklar och till och med datadumpar hamnar i publika repositories. Branch-skydd saknas, kod granskas inte innan merge till produktion, och CI/CD-pipelines hanteras utan insyn. För att säkra denna typ av arbetsflöde krävs såväl tekniska verktyg som organisatoriska rutiner.
Integrationsfällor: när data flödar utanför kontroll
Många applikationer integrerar med externa system via verktyg som Zapier, Make.com eller direkt via API. Data skickas mellan Google Sheets, Airtable, formulär i WordPress och dashboards i verktyg som Power BI. Men dessa integrationer innebär också nya attackytor.
Filer delas publikt, autentisering sker via statiska nycklar, och data kan publiceras av misstag. Framför allt sker detta ofta utan loggning eller behörighetsgranskning. Risken att avdelningar publicerar persondata eller affärskritisk information av misstag är hög.
Fördelning av ansvar – strukturera organisationens säkerhetsarbete
IT kan inte ensam ta ansvar för den decentraliserade systemutveckling som AI-verktyg möjliggör. Men IT måste bli en kurator för säkra verktyg och flöden. Organisationen behöver tydliga spelregler för vad som får byggas, var data får lagras, och hur kod granskas innan produktion.
| Funktion | Ansvar |
|---|---|
| IT | Tillhandahålla godkända backendmiljöer och granska flöden |
| Avdelningar | Använda verktyg enligt policy och hantera datainnehåll |
| DevOps/Utvecklare | Implementera RLS, kryptering och CI/CD-skydd |
| Ledning | Allokera resurser och fastställa regelverk |
Det är viktigt att identifiera vilka system som är kritiska, vilka databaser som är i drift, och vem som har åtkomst. Checklista, loggning och återställning måste vara standard, inte eftertanke.
Rekommendationer
- Implementera säkerhetspolicys för AI-genererad kod
- Kräv RLS eller motsvarande åtkomstkontroll i databaser och att gå igenom felen som man exepelvis ser i Supabase
- Använd automatiserad scanning i GitHub (GitGuardian, m.fl.)
- Dokumentera och granska alla integrationer
- Utbilda användare i hur data får hanteras och var den får lagras
Källor och fördjupning
- Andrej Karpathy (2025): Beskrivning av vibe-kodning. Ursprunglig kommentar via X (f.d. Twitter), februari 2025.
- Supabase dokumentation: https://supabase.com/docs
- PostgreSQL Row-Level Security: https://www.postgresql.org/docs/current/ddl-rowsecurity.html
- GitHub Secrets & Actions security: https://docs.github.com/en/actions/security-guides
- OWASP: Database Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Database_Security_Cheat_Sheet.html
- GitGuardian: https://www.gitguardian.com/
Denna artikel fokuserar på databas- och backend-säkerhet i decentraliserade utvecklingsmiljöer. För specifik säkerhetsgranskning av WordPress rekommenderar vi vår guide: ”Säkrare WordPress: En guide hur du skyddar din webbplats från cyberattacker”.
Säkerhetsarbetet måste idag ta höjd för att utveckling inte längre är centraliserad. Med AI som motor och databaser som standardresurs för alla avdelningar, krävs en ny struktur för ansvar, tillgång och kontroll. Annars är risken stor att automatiseringens snabbhet överglänser säkerhetens eftertänksamhet.
