En rapport offentliggjort på DEV Community beskriver et "sikkerhedsbrud til $0", hvor 24.664 AI-byggede apps angiveligt lækkede mere end 80.000 brugerposter, herunder pasnumre, gennem Supabase-databaser. Denne AI-byggede apps-datalækage Supabase-sag er en nyttig påmindelse om, at udviklingshastighed og sikkerhed for brugerdata ikke er det samme.

En note om kilder: Det kildemateriale, vi har adgang til, er begrænset til rapportens overskrift og et kort resumé. Det fortæller os ikke, hvem der identificerede eksponeringen, hvordan appene blev fundet, eller hvilke specifikke apps der var berørt. Denne artikel holder sig til det, rapporten angiver, og mærker tydeligt enhver generel baggrund som sådan.

Hvordan fejlkonfigurerede databaser eksponerede brugerposter

Ifølge rapportens titel kom de eksponerede poster fra apps bygget med AI-værktøjer, der brugte Supabase som deres backend. Overskriften rammer også hændelsen ind som kostfri at gennemføre, hvilket antyder, at der ikke var nogen sofistikeret hacking involveret. Kilden beskriver ikke mekanikken i detaljer.

Som generel baggrund (ikke fra rapporten): Supabase er en hosted database-tjeneste, og adgang til dens data styres typisk af regler fastsat af den, der bygger appen, såsom row level security. Hvis disse regler mangler eller er for tilladende, kan data være læsbare for personer, der ikke burde se dem. Det er et konfigurationsproblem snarere end en fejl, der kræver indbrud.

Hvorfor vibe coding skaber dette sikkerhedshul

"Vibe coding" refererer til at bygge software ved at beskrive, hvad man ønsker, til et AI-værktøj og acceptere den genererede kode med minimal manuel gennemgang. Det kan forvandle en idé til en fungerende app på få timer. Afvejningen er, at sikkerhedsindstillinger er nemme at overse, når appen ser ud til at fungere.

En app kan se ud og opføre sig perfekt, mens dens backend er åben for enhver, der ved, hvor de skal kigge. Intet på skærmen fortæller en bruger, eller ofte byggeren, at noget er galt. Det er derfor, en poleret grænseflade er en dårlig indikator for, hvor omhyggeligt data beskyttes.

Det passer også ind i et bredere mønster af AI-værktøjer, der ændrer risikobilledet. Vores dækning af, hvordan Aurora ransomware-bandens udrulning af en AI-kodeagent i angreb og hvordan Qilin bruger AI-værktøjer, mens ransomware-angreb i Japan stiger, viser AI accelererer arbejdet på angribernes side også.

Hvilke data blev eksponeret, og hvem er i fare

Rapporten siger, at de eksponerede poster udgør mere end 80.000 og inkluderer pasnumre. Pasoplysninger er blandt de mest følsomme identifikatorer, en person kan dele, fordi de er svære at erstatte og kan understøtte identitetssvindel, når de kombineres med et navn, en e-mailadresse eller en fødselsdato.

Kilden specificerer ikke, hvilke andre felter der blev eksponeret, eller hvilke lande de berørte brugere befinder sig i. Alle, der har tilmeldt sig en nyere app og uploadet identitetsdokumenter eller personlige oplysninger, er potentielt i den gruppe, det er værd at være opmærksom på, især hvis appen kom fra en lille eller ukendt udvikler.

Hvad det betyder for dig

Du kan normalt ikke se, hvordan en app beskytter sin database, så det praktiske forsvar er at kontrollere, hvad du afgiver.

  • Sæt spørgsmålstegn ved behovet. Hvis en app beder om et pasnummer eller en ID-scanning, så spørg, om tjenesten virkelig har brug for det.
  • Tjek udvikleren. Se efter en navngivet virksomhed, en privatlivspolitik og en måde at kontakte support på. Vær forsigtig med helt nye apps, der ikke har nogen af disse.
  • Brug unikke legitimationsoplysninger. En separat adgangskode og et e-mail-alias til hver ny tjeneste begrænser skaden, hvis ét sæt poster eksponeres.
  • Spring valgfrie felter over. Udelad telefonnumre, adresser og dokumentuploads, medmindre de er påkrævet.
  • Vær opmærksom på opfølgende svindel. Eksponerede poster genbruges ofte til phishing og svindel, som set da Paidwork-brugerposter blev tilføjet til HIBP.

Sådan vurderer du apps og begrænser, hvad du deler

Før du opretter en konto hos en ny app, brug et minut på at gennemgå den. Foretræk tjenester, der forklarer, hvordan de opbevarer data, og som har en etableret track record. Hvis en app vil have identitetsdokumenter, overvej, om der findes et mere etableret alternativ.

Hvis du selv bygger apps, er det generelle råd at gennemgå databaseadgangsregler før lancering i stedet for at stole på genereret kode, og at teste din app som en uautentificeret besøgende for at se, hvilke data der er tilgængelige.

Vigtigste pointer

Den rapporterede AI-byggede apps-datalækage Supabase-hændelse viser, at en fungerende app ikke nødvendigvis er en sikker en. Start med at tjekke, om din e-mail fremgår af kendte brud ved hjælp af en tjeneste som Have I Been Pwned, og skift adgangskoder for enhver konto, hvor det er tilfældet. Giv derefter hver ny app kun de minimale personlige data, den har brug for. For at se, hvordan eksponerede poster bruges, læs vores dækning af Paidwork-bruddet, der lækkede 23 mio. e-mails og bankdata.