En rapport publicerad på DEV Community beskriver ett "säkerhetsintrång för 0 dollar" där 24 664 AI-byggda appar påstås ha läckt mer än 80 000 användarposter, inklusive passnummer, genom Supabase-databaser. Detta fall med AI-byggda appar som läcker data via Supabase är en bra påminnelse om att snabb utveckling och säkerhet för användardata inte är samma sak.
En notering om källan: det källmaterial vi har tillgång till är begränsat till rapportens rubrik och en kort sammanfattning. Den säger inte vem som identifierade exponeringen, hur apparna hittades eller vilka specifika appar som drabbades. Den här artikeln håller sig till vad rapporten anger och märker tydligt ut allmän bakgrund som sådan.
Hur felkonfigurerade databaser exponerade användarposter
Enligt rapportens rubrik kom de exponerade posterna från appar byggda med AI-verktyg som använde Supabase som backend. Rubriken ramar också in incidenten som att den inte kostade något att genomföra, vilket antyder att ingen avancerad hackning var inblandad. Källan beskriver inte mekanismerna i detalj.
Som allmän bakgrund (inte hämtat från rapporten): Supabase är en hostad databastjänst, och åtkomst till dess data styrs vanligtvis av regler som sätts av den som bygger appen, till exempel row level security. Om dessa regler saknas eller är för tillåtande kan data bli läsbar för personer som inte borde se den. Det är ett konfigurationsproblem snarare än en brist som kräver att man bryter sig in.
Varför vibe coding skapar detta säkerhetshål
"Vibe coding" syftar på att bygga mjukvara genom att beskriva vad man vill ha för ett AI-verktyg och acceptera den genererade koden med liten manuell granskning. Det kan förvandla en idé till en fungerande app på några timmar. Avvägningen är att säkerhetsinställningar är lätta att förbise när appen verkar fungera.
En app kan se ut och bete sig perfekt medan dess backend är öppen för alla som vet var de ska leta. Ingenting på skärmen talar om för en användare, eller ofta ens för byggaren, att något är fel. Det är därför ett polerat gränssnitt är en dålig indikator på hur noggrant data skyddas.
Detta passar också in i ett bredare mönster där AI-verktyg förändrar riskbilden. Vår rapportering om hur Aurora-ransomwareligan använder en AI-kodningsagent i attacker och hur Qilin använder AI-verktyg när ransomware-attacker ökar i Japan visar att AI även snabbar upp arbetet på angriparens sida.
Vilken data exponerades och vem är i riskzonen
Rapporten säger att de exponerade posterna uppgår till fler än 80 000 och inkluderar passnummer. Passuppgifter är bland de mest känsliga identifierare en person kan dela, eftersom de är svåra att ersätta och kan möjliggöra identitetsbedrägeri när de kombineras med ett namn, en e-postadress eller ett födelsedatum.
Källan anger inte vilka andra fält som exponerades eller vilka länder de drabbade användarna finns i. Alla som registrerade sig för en nyare app och laddade upp identitetshandlingar eller personuppgifter är potentiellt i den grupp som är värd att uppmärksamma, särskilt om appen kom från en liten eller okänd utvecklare.
Vad det här innebär för dig
Du kan vanligtvis inte se hur en app skyddar sin databas, så det praktiska försvaret är att kontrollera vad du lämnar över.
- Ifrågasätt behovet. Om en app begär ett passnummer eller en ID-skann, fråga om tjänsten verkligen kräver det.
- Kontrollera utvecklaren. Leta efter ett namngivet företag, en integritetspolicy och ett sätt att kontakta supporten. Var försiktig med helt nya appar som saknar allt detta.
- Använd unika inloggningsuppgifter. Ett separat lösenord och ett e-postalias för varje ny tjänst begränsar skadorna om en uppsättning poster exponeras.
- Hoppa över valfria fält. Utelämna telefonnummer, adresser och dokumentuppladdningar om de inte är obligatoriska.
- Var uppmärksam på uppföljningsbedrägerier. Exponerade poster återanvänds ofta för nätfiske och bedrägeri, vilket syntes när Paidwork-användarposter lades till i HIBP.
Hur du granskar appar och begränsar vad du delar
Innan du skapar ett konto hos en ny app, ta en minut att granska den. Föredra tjänster som förklarar hur de lagrar data och som har ett etablerat track record. Om en app vill ha identitetshandlingar, överväg om ett mer etablerat alternativ finns.
Om du bygger appar själv är det allmänna rådet att granska databasens åtkomstregler före lansering i stället för att lita på genererad kod, och att testa din app som en oautentiserad besökare för att se vilken data som är åtkomlig.
Slutsatser
Den rapporterade incidenten med AI-byggda appar som läcker data via Supabase visar att en fungerande app inte nödvändigtvis är en säker sådan. Börja med att kontrollera om din e-post förekommer i kända intrång med hjälp av en tjänst som Have I Been Pwned, och byt lösenord för alla konton som gör det. Ge sedan varje ny app endast de minimala personuppgifter den behöver. För att se hur exponerade poster används, läs vår rapportering om Paidwork-intrånget som läckte 23 miljoner e-postadresser och bankdata.




