Xint fant 434 utnyttbare sårbarheter i vibe-kodede apper

Xint.io, plattformen bak Theoris autonome pentest-motor, gikk inn i undersøkelsen med en forventning om SQL-injeksjon, XSS og et vell av tilgangskontrollfeil. Ifølge SecurityWeek fant de det motsatte: injeksjon dukket knapt opp, og IDOR-feil var langt sjeldnere enn antatt. Det som derimot veltet ut av skanningene, var manglende rate limiting og fravær av ressursgrenser.

Testen dekket tre arbeidsflyter. Én ny app bygget fra en godt skrevet spesifikasjon, med en erfaren utvikler over skulderen. Én ny app bygget på det langt vanligere «bare lag dette». Og til slutt legacy-forumet Gnuboard7, migrert til Laravel og React før KI-en fikk i oppdrag å herde det. Hver app fikk 30 minutters kombinert kjøretids- og kildekodeanalyse, og fasiten ble 434 utnyttbare funn: 196 i de to nye appene, 238 i den migrerte.

Det er 23 kritiske funn i materialet, og de handler stort sett om hemmeligheter: hardkodede eller uendrede standardverdier står for 11 av dem, debug-modus med kjøring av vilkårlig kode for seks til. Størrelsen på appen betyr også noe. IDOR utgjorde 11 prosent av feilene i de små appene, men 28 prosent i den store. «Finmasket autorisasjon holder på små apper, men brister etter hvert som appen vokser», advarer rapporten. Xint mener samtidig at modellene faktisk er blitt bedre, siden nettopp injeksjon og BOLA nå er sjeldne.

Hva bør du gjøre?

1. Be eksplisitt om ressursgrenser i prompten. Rate limiting, timeouts og maks kroppsstørrelse på forespørsler kommer ikke av seg selv når du bare beskriver funksjonalitet.
2. Kjør en hemmelighetsskanning over generert kode før første commit. API-nøkler og standardpassord er den vanligste kilden til kritiske funn.
3. Test autorisasjon på nytt hver gang du legger til endepunkter. Objektnivå-tilgang som holdt ved 20 ruter, brister ved 200.