Moltbook-intrånget: När vibe coding blir en säkerhetsmardröm

Vad hände egentligen på Moltbook?

Låt mig bryta ner exakt vad som gick fel, för detaljerna spelar roll.

Moltbook byggdes med Supabase—ett populärt Firebase-alternativ med öppen källkod som tillhandahåller värdbaserade PostgreSQL-databaser. Supabase har blivit backend-valet för vibe-kodade applikationer eftersom det hanterar autentisering, databaser och lagring med minimal konfiguration.

Problemet? Någon (eller någon AI) lade en Supabase API-nyckel direkt i den klientsidiga JavaScript-koden. Detta är ett grundläggande säkerhetsmisstag. API-nycklar hör hemma på servern, aldrig i kod som körs i en användares webbläsare.

Men det blir värre.

Den API-nyckeln hade full läs- och skrivåtkomst till hela databasen. Och Moltbook hade inte aktiverat Radsäkerhet (RLS)—en Supabase-funktion som styr vem som kan komma åt vilken data. RLS är ungefär lika valfritt som ett säkerhetsbälte. Du kanske tror att du inte behöver det tills du kraschar.

Säkerhetsforskare på Wiz hittade den exponerade nyckeln inom några minuter efter att ha tittat på webbplatsen. De kunde ha:

• Laddade ner alla 1,5 miljoner API-nycklar (inklusive nycklar för OpenAI, Anthropic och andra AI-leverantörer)
• Kom åt privata meddelanden mellan AI-agenter
• Ändrat eller raderat någon data i databasen
• Kapade något användarkonto
• Samla på dig enorma räkningar med stulna API-nycklar

Kicken? Grundaren erkände att han "helt vibe-codade" hela plattformen. Ingen kodgranskning. Ingen säkerhetsrevision. Bara prompts till en AI och copy-paste av resultaten.

Varför detta fortsätter att hända

Här är vad som är frustrerande med den här historien: den är inte unik.

Kommer du ihåg när DeepSeek hade sina API-nycklar exponerade? Eller Base44? Mönstret upprepar sig eftersom vibe coding-filosofin aktivt avskräcker från de metoder som förhindrar dessa intrång.

Kärnfilosofin med vibe-kodning är: rör dig snabbt, fokusera på resultat, oroa dig inte för detaljerna. Det är förföriskt eftersom – ärligt talat – det fungerar för att bygga prototyper. Du kan snurra upp en fungerande app på timmar.

Men produktionsapplikationer lever i en annan värld. De hanterar riktig användardata, riktiga betalningar, riktiga säkerhetshot. Samma tankesätt som hjälper dig att leverera en prototyp på en helg kommer att få din produktionsapp hackad på dag ett.

Jag pratade med en säkerhetsforskare som specialiserar sig på AI-genererad kod. Här är vad som håller honom vaken på natten:

• Ingen förståelse för vad som händer: När du uppmanar en AI att "bygga ett inloggningssystem" får du kod som ser ut som ett inloggningssystem men kan ha subtila brister som bara en expert skulle upptäcka
• Lita på AI: Användare antar att AI-genererad kod är säker eftersom... den är från en AI? Det antagandet är helt fel
• Saknade grunder: Vibe-kodare vet ofta inte vad de inte vet om säkerhet

45%-problemet

Låt mig ge dig en siffra som borde hålla dig vaken på natten: 45%.

Det är andelen AI-genererad kod som innehåller säkerhetsbrister, enligt Veracodes forskning om AI-genererad mjukvarusäkerhet^[1].

Det handlar inte om dåliga AI-modeller eller inkompetenta utvecklare. Det handlar om kodgenereringens grundläggande natur. AI-modeller är tränade på befintlig kod—som inkluderar osäker kod. De återger mönster de har sett, inklusive sårbara sådana.

Vanliga sårbarheter i AI-genererad kod inkluderar:

Moltbook-intrånget var faktiskt två problem: en hårdkodad API-nyckel (hårdkodade hemligheter) OCH saknad RLS (osäker konfiguration). Endera ensam skulle ha varit illa. Tillsammans skapade de en katastrof.

Vad ingen berättar för dig om Vibe Coding

Låt mig vara ärlig med dig. Jag har vibe kodat massor av projekt. Det har verkligen förändrat hur jag bygger saker. Men jag har också lärt mig några hårda läxor den hårda vägen.

Du måste fortfarande förstå säkerhet

Här är en obekväm sanning: du kan inte använda AI-verktyg för att bygga säkra applikationer om du inte förstår säkerhet själv. AI:n känner inte till din hotmodell. Den vet inte vilka tillgångar du skyddar. Den genererar bara kod som ser rimlig ut.

Du behöver inte bli en säkerhetsexpert. Men du måste förstå:

• Lägg aldrig hemligheter i klientsidans kod
• Aktivera alltid Radsäkerhet på databaser
• Använd miljövariabler för känslig konfiguration
• Implementera korrekt indatavalidering
• Kör säkerhetsskanningar på genererad kod

Prototyp snabbt, ingenjör sedan

Mitt nuvarande arbetsflöde:

• Vibe-koda prototypen – Få något fungerande, validera idén med riktiga användare
• Identifiera produkt-marknadspassning – Innan du investerar i något
• Refaktorera för produktion – Det är här du faktiskt konstruerar säkerhet, prestanda och underhållbarhet

Misstaget är att skicka vibe-kodade prototyper direkt till produktion utan refaktoriseringssteget. Du sparar inte tid – du ackumulerar teknisk skuld som kommer att kosta dig senare.

Använd rätt verktyg för jobbet

Det här kan vara kontroversiellt, men jag tycker inte att vibe coding är lämpligt för:

• Applikationer som hanterar känslig användardata (sjukvård, ekonomi)
• System som behandlar betalningar
• Allt med regelefterlevnadskrav
• Applikationer där säkerhetsfel kan orsaka verklig skada

För interna verktyg, MVP:er och prototyper? Kör hårt. För produktionssystem som hanterar riktig användardata? Bygg det ordentligt.

Hur du skyddar dig själv

Om du vibe-codar ändå (och ärligt talat, det borde du — det är otroligt kraftfullt), här är hur du undviker att bli nästa rubrik:

För din Supabase/Backend

javascript
// WRONG - Never do this
const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE')
// Your service_role key is also exposed here!

// CORRECT - Use environment variables, server-side only
const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_ANON_KEY
)

Viktig säkerhetschecklista

• [ ] Aktivera Row Level Security på ALLA databastabeller
• [ ] Lagra API-nycklar i miljövariabler, aldrig i kod
• [ ] Kör en säkerhetsskanning på all genererad kod (Snyk, CodeQL eller GitHub Advanced Security)
• [ ] Exponera aldrig service_role-nycklar för klienten
• [ ] Implementera korrekt inmatningsvalidering på alla användarinmatningar
• [ ] Sätt upp hastighetsbegränsning för att förhindra missbruk
• [ ] Skaffa en penetrationstest innan du lanserar något med riktiga användare

Verktyg som hjälper

Vad detta innebär för branschen

Jag är ärligt talat orolig för vart vi är på väg.

Vi är mitt i en massiv förändring av hur programvara byggs. Icke-tekniska grundare kan nu skapa sofistikerade applikationer. Inträdesbarriären har kollapsat. Det är verkligen spännande.

Men vi skapar också en generation applikationer utan någon som vaktar butiken.

Här är vad jag tycker behöver hända:

• AI-kodningsverktyg behöver bättre säkerhetsstandarder som standard – Sluta generera kod med inbyggda sårbarheter
• Communities måste prata mer om detta — Varje blogginlägg om vibe coding bör nämna säkerhet
• Vi behöver bättre verktyg — Automatisk säkerhetsskanning bör vara inbyggd i varje AI-kodningsarbetsflöde
• Grundare måste ta ansvar – Du kan inte skylla på AI när något går fel

Framtiden för mjukvaruutveckling handlar inte om att välja mellan AI-hastighet och säkerhet. Det handlar om att lära sig använda båda tillsammans.

Vanliga frågor

Slutsatsen

Moltbook är inte en anomali. Det är en förhandsvisning av vad som komma skall.

När fler grundare skickar vibe-codade applikationer utan att förstå säkerhetsgrunder kommer vi att se fler intrång. Fler läckta API-nycklar. Fler exponerade databaser. Fler offer.

Detta är inte ett argument mot vibe-kodning. Det är ett argument för att vara ärlig om dess begränsningar.

Skicka snabbt. Testa idéer. Rör dig snabbt. Men innan du sätter riktig användardata på spel, sakta ner och gör säkerhetsarbetet. Dina användare litar på dig med sin information. Det förtroendet borde inte vibe-codas bort.

Relaterade inlägg

• Vad är Vibe Coding? Den kompletta guiden 2026
• Cursor vs Windsurf för Vibe Coding: Vilken vinner 2026?
• Hur man bygger en AI-app på 7 dagar (steg-för-steg
• Hur du snabbt får 100 betaanvändare

Redo att lansera din app säkert? Lista din app på GetFree—en kurerad katalog där utvecklare delar kampanjkoder och betaåtkomst med tusentals riktade testare.

Källor

Ursprungligen publicerad på GetFree.APP Blogg — Senast uppdaterad: 17 februari 2026