Er vibe coding trygt? De reelle risikoene og hva du bør sjekke før du publiserer

Vibe coding er trygt for personlige verktøy og prototyper, og det kan være trygt for ekte apper med ekte brukere, men bare hvis du legger til sjekkene som «bare beskriv det og se om det fungerer» hopper over. De farlige problemene er usynlige fra skjermen: brukere som kan åpne hverandres data, hemmelige nøkler som ligger i nettleseren, og offentlige skjemaer uten grenser. Denne guiden forklarer risikoene som faktisk skaper problemer, hvordan du håndterer hemmeligheter, hvor mye gjennomgang du trenger, og en sjekk på 30 minutter som du bør kjøre før du publiserer.

For den fullstendige tekniske listen, se vår sikkerhetssjekkliste for AI-bygde apper. Denne siden er den kortere, praktiske versjonen for folk som ikke leser kode.

Hvorfor vibe coding har sine egne risikoer

Når du vibe coder, vurderer du appen ved å bruke den. Det fanger opp ødelagte knapper og stygge oppsett. Det fanger ikke problemer som bare dukker opp når noen bruker appen på en annen måte enn deg: en fremmed, en bot eller en nysgjerrig bruker som redigerer en nettadresse.

KI-modeller skriver plausibel kode, og det meste av den er fin. Men de optimaliserer for det du ba om, for eksempel «få dashbordet til å vise prosjektene mine», og legger kanskje ikke til beskyttelsen du ikke ba om, for eksempel «og ingen andres». Løsningen er ikke å slutte med vibe coding. Det er å be eksplisitt om beskyttelsen og så teste den.

Hvor risikabel er appen din? En rask skala

Vær ærlig om hvilken rad du er i. Mange apper starter i rad én og glir over til rad tre uten at noen har bestemt det.

Risikoene som faktisk skaper problemer

1. Brukere kan se hverandres data

Dette er det vanligste alvorlige problemet i KI-bygde apper. Siden viser hver bruker bare sine egne poster, så det ser riktig ut. Men serveren vil gi tilbake enhver post hvis noen endrer ID-en i adressefeltet eller i en forespørsel. Fordi du alltid tester som deg selv, ser du det aldri.

Slik sjekker du: Lag to kontoer. Logg inn som bruker A, åpne en av A sine poster og noter adressen. Logg inn som bruker B i et privat vindu og lim inn adressen. Du bør få «ikke funnet», aldri A sine data.

Prompt:

Sjekk alle serverendepunkter som leser, endrer eller sletter brukerdata. Hvert må bekrefte at innlogget bruker har lov til å få tilgang til den spesifikke posten. List opp endepunktene, forklar hvordan hvert av dem sjekker, og fiks de som ikke gjør det.

2. Hemmeligheter på feil sted

En hemmelighet er alt som gir tilgang: en API-nøkkel for en KI- eller e-posttjeneste, et databasepassord, en betalingsleverandørs hemmelige nøkkel. Hvis den ligger i kode som kjører i nettleseren, kan hvem som helst åpne utviklerverktøyene og kopiere den. Hvis den er sjekket inn i et offentlig repository, finner bots den i løpet av timer.

Slik sjekker du: Spør AI-en.

List opp alle API-nøkler, tokens og passord denne appen bruker. For hver og en, fortell meg hvor den lagres og om den noen gang sendes til nettleseren. Flytt alle som ligger i koden eller i frontend over til hemmeligheter på serversiden.

3. Offentlige skjemaer og endepunkter uten grenser

Kontaktskjemaer, registreringer og KI-funksjoner blir funnet av bots. Uten grenser får du spam, falske kontoer, eller en stor regning fra et KI-API som kalles tusenvis av ganger.

Prompt:

Legg til hastighetsgrenser på registrering, innlogging, kontaktskjemaet og hvert endepunkt som kaller en KI-tjeneste. Legg til et honeypot-felt i offentlige skjemaer. Fortell meg hvilke grenser du valgte.

4. Å stole på nettleseren

Alt nettleseren bestemmer, kan brukeren endre: priser, rabatter, quizsvar, «er admin»-flagg. Regler som betyr noe, må håndheves på serveren.

Prompt:

Finn steder der nettleseren bestemmer noe serveren burde bestemme: priser, totaler, tillatelser, roller, poengsum. Flytt disse kontrollene til serveren.

5. Ingen vei tilbake

En dårlig endring, eller en ond aktør, kan slette data. Hvis det ikke finnes backup og ingen måte å rulle tilbake på, blir en liten feil permanent. Sørg for at verktøyet ditt har sjekkpunkter for koden og sikkerhetskopier for databasen. Se hvordan du tar backup av appens database.

Slik håndterer du hemmeligheter på riktig måte

Hemmeligheter forårsaker mer unødvendig skade enn noe annet, så her er reglene samlet:

• Lim aldri inn en ekte nøkkel i chatten. Chatter lagres, deles og tas skjermbilder av. Legg nøkler i verktøyets hemmeligheter eller miljøvariabler i stedet. (Hva miljøvariabler og hemmeligheter er.)
• Kall betalte tjenester fra serveren. Nettleseren spør serveren din; serveren kaller KI- eller betalingstjenesten med nøkkelen.
• Bruk separate nøkler for testing og bruk i produksjon, slik at en lekket testnøkkel ikke kan røre ekte penger.
• Sett forbruksgrenser i dashbordene til KI- og e-postleverandører.
• Roter en nøkkel umiddelbart hvis du tror den har lekket. Lag en ny, oppdater hemmeligheten, og slett så den gamle.

På Mythex ligger hemmeligheter i prosjektinnstillingene utenfor koden, og agenten kan bruke dem uten at verdiene vises i chatten. Vår guide om å holde API-nøkler trygge dekker flere leverandører.

Hvor mye kodegjennomgang trenger du?

Vibe coding betyr at du ikke leser hver eneste linje. Det trenger du ikke. Men for noen linjer bør noen se på dem.

• Personlige verktøy: ingen utover sjekkene her.
• Apper med brukerkontoer: gå gjennom hvordan innlogging og datatilgang fungerer. Du kan gjøre dette ved å be AI-en forklare det med enkle ord, og sjekke at forklaringen stemmer med det du forventer.
• Apper med betaling eller sensitive data: få en utvikler til å se på autentisering, tillatelser, betalingshåndtering og alt som lagrer personopplysninger. Det er noen timer av deres tid, ikke en omskriving.

En nyttig prompt selv uten utvikler:

Forklar med enkle ord hvordan denne appen avgjør hvem en bruker er, og hva de har lov til å se. Pek på filene. List deretter opp alt en sikkerhetsreviewer bør se nærmere på.

Vår guide om hvordan du gjennomgår KI-generert kode forklarer hva gjennomgåere ser etter, og du kan gi den til den som gjør gjennomgangen. Hvis verktøyet ditt lar deg eksportere koden eller synkronisere til GitHub, er gjennomgangen enkel å ordne; på Mythex er begge deler en del av Pro.

30-minutters sjekken før publisering

Kjør denne før du deler lenken med noen utenfor din krets.

Tilgang (10 minutter)

1. To kontoer, to nettlesere: kan B åpne A sine poster via URL? Det skal den ikke kunne.
2. Logg ut og besøk adressen til hver side direkte. Private sider skal sende deg til innlogging.
3. Åpne admin-adresser som vanlig bruker. De skal avvises.

Hemmeligheter (5 minutter)

1. Spør AI-en hvor hver nøkkel ligger, ved hjelp av prompten over.
2. Åpne appen, vis kildekoden på siden og søk etter «key», «secret» og «token».

Skjemaer og misbruk (5 minutter)

1. Send hvert skjema tomt, med veldig lang tekst, og to ganger raskt etter hverandre.
2. Bekreft at det finnes hastighetsgrenser på registrering, innlogging og alle KI-funksjoner.

Data og gjenoppretting (5 minutter)

1. Vit hvor dataene ligger og hvordan du gjenoppretter dem.
2. Sjekk at du kan rulle tilbake koden til en tidligere fungerende versjon.

Juridisk og grunnleggende (5 minutter)

1. Hvis du samler inn personopplysninger, legg til en personvernerklæring og si hva du samler inn. Se hvordan du skriver vilkår for bruk og personvernerklæring.
2. Sjekk at den publiserte appen bruker HTTPS. De fleste verktøy, Mythex inkludert, ordner dette for deg.

Hvis alt består, er du godt rustet til en tidlig lansering. Gjenta trinn 1–5 etter hver stor endring i innlogging, roller eller data.

Hva vibe coding-plattformer beskytter og ikke beskytter

En god plattform håndterer mye av infrastrukturen: HTTPS, isolerte arbeidsområder, en database per prosjekt, lagring av hemmeligheter, sikkerhetskopier og tilbakerulling. Mythex gir hvert prosjekt sitt eget private arbeidsområde og database, holder hemmeligheter utenfor koden, og lagrer et sjekkpunkt etter hver vellykket endring, slik at du kan angre den.

Det ingen plattform kan gjøre, er å kjenne appens regler. Bare du vet at kunder ikke skal se hverandres fakturaer, eller at en rabattkode bare skal fungere én gang. De reglene må stå i prompt-ene dine og bekreftes av testene dine.

Det korte svaret

Vibe coding er så trygt som sjekkene du legger til. For et personlig verktøy: hold nøkler ute av koden og nyt det. For alt med andres data: kjør 30-minutters sjekken over før hver lansering, og få en utviklers blikk på betaling og sensitive data. For å se disse risikoene i ekte prosjekter, les vårt om eksempler på vibe coding; for å bygge med disse sjekkene fra starten, følg hvordan du bygger en app med vibe coding.

Spørsmål