Det er ikke lenge siden utviklere skrev alt kode manuelt. I dag skriver vibe coding den første versjonen av koden - og du må sjekke den grundig. Vibe coding betyr at du bruker AI-verktøy som GitHub Copilot for å generere backend-kode med enkle beskrivelser. «Lag en login-side med JWT og brukerroller» - og AI gir deg kode. Det ser ut som det fungerer. Men det fungerer ikke sikkert. I 2026 er 78 % av AI-generert autentiseringskode sårbar for angrep. Ikke fordi AI er dårlig. Fordi den ikke vet hva du ikke sier.
Hva er vibe coding, og hvorfor er det farlig?
Vibe coding er ikke en ny programmeringsspråk. Den er en måte å jobbe. Du skriver: «Lag en API som godtar brukernavn og passord, og gir en token.» AI gir deg en Express.js-endepunkt, en JWT-generering, og en databasekobling. Det er raskt. Det er enklere. Og det er farlig som ingenting annet.
AI genererer autentisering. Den glemmer autorisasjon. Det er som å bygge en dør med en perfekt lås - men glemme å sette inn en nøkkel til rommet bak døren. I 68 % av vibe-kodete systemer finnes det ingen sjekk av hvilken bruker som har tilgang til hva. En bruker med «viewer»-rolle kan slette alle poster. En gjest kan laste ned hele brukerlisten. Det skjer fordi AI ikke forstår kontekst. Den ser ikke at «bruker» ikke betyr «alle».
Et eksempel fra virkeligheten: En utvikler på Reddit brukte Copilot til å lage en backend for en liten app. AI genererte JWT-tokens med et hardcoded hemmelig nøkkel - "mysecret123". Det var det hele. Ingen token-validering. Ingen utløpsdato. Ingen refresh-token. Tre dager senere var hele systemet kompromittert. AI gjorde det riktig - i henhold til det den fikk å gjøre. Ikke i henhold til hva som var trygt.
Hva må autentisering inneholde for å være trygg?
En sikker vibe-kodet autentisering må ha fire byggestener. Ikke tre. Ikke fem. Fire.
- OAuth 2.0 Authorization Code Flow med PKCE: Dette er minimumsstandard. AI bruker ofte den gamle, usikre «Implicit Grant»-flyten - som 42 % av genererte koder gjør. PKCE gjør det umulig for angripere å stjele tokens ved å bruke en kodechallenge. Denne flyten må brukes, spesielt for mobil- og frontend-apper.
- JWT med riktig konfigurasjon: AI genererer JWT-tokens - men ofte med uendelig gyldighet. En sikker token må ha en kort levetid: 15-60 minutter for access-token. Refresh-token skal ikke være gyldig lenger enn 7 dager. Og aldri skal hemmeligheten være hardkodet. Den må lagres i en sikker miljøvariabel.
- HTTP-only, Secure, SameSite=Strict cookies: Hvis du bruker sesjoner, ikke tokens, må du bruke cookies med disse flaggene. AI glemmer dette. Den genererer cookies uten
Secure- som gjør dem sårbar for man-in-the-middle-angrep. OgSamesite=Strictstopper CSRF-angrep - som 63 % av vibe-kodete systemer mangler. - Rate limiting: AI genererer ikke beskyttelse mot brute-force-angrep. Du må legge til en middelvare som
express-rate-limitog sette grensen til 100 forespørsler per 15 minutter per IP-adresse. Uten dette kan en angriper prøve 10 000 passord på 5 minutter.
Hvis du ikke har alle fire, så er ikke koden trygg. Uansett hvor pent den ser ut.
Hvorfor autorisasjon er den største fellen
Autentisering er å si: «Du er kimen.» Autorisasjon er å si: «Hva kan du gjøre?»
AI er flink til å lage autentisering. Den er dårlig til autorisasjon. I 78 % av tilfellene glemmer AI å legge inn autorisasjonskontroller. Det betyr at når du logger inn, får du tilgang til alt - ikke bare det du skal ha.
Her er hva du må gjøre:
- RBAC - Rollbasert tilgangskontroll: Lag minst tre roller: admin, editor, viewer. Hver rolle har en liste over tillatelser. Ikke bruk «user» som en rolle. Den er for generell. AI vil alltid bruke «user» - og det er feil.
- ABAC - Attributtbasert tilgangskontroll: Noen ressurser skal bare være tilgjengelige for brukere med en spesifikk egenskap. Eksempel: «Kun brukere som eier dette dokumentet kan slette det.» AI vil aldri lage dette selv. Du må legge det til manuelt. Et eksempel på ABAC:
if (user.id === document.ownerId) { allowDelete(); } - Check på hvert eneste endepunkt: Hver gang en bruker spør om data - sjekk. Ikke bare på login. Ikke bare på admin-sider. På alle API-endepunkter. 68 % av vibe-kodete systemer har ingen sjekk mellom autentisering og datatilgang. Det er en åpen dør.
En utvikler på GitHub skrev: «AI genererte en perfekt login. Men jeg kunne slette alle brukere som gjest. Jeg fikk ikke en advarsel. Ikke en linje kode. Bare en 200 OK-svar.»
Hva må du gjøre etter at AI har kodet
AI er ikke din sekretær. Den er din assistent. Og assistenter må sjekkes.
Her er en liste over hva du må gjøre etter at du har fått kode fra AI:
- Sjekk alle hemmeligheter: Finn alle
"secret","key","password"i koden. Er de hardkodet? Slett. Brukprocess.env.JWT_SECRETi stedet. - Sjekk token-utløpsdatoer: Er access-tokenene gyldige i 30 dager? Endre til 15-60 minutter. Er refresh-tokens gyldige i 30 dager? Endre til 7 dager.
- Sjekk cookies: Har de
HttpOnly,Secure, ogSamesite=Strict? Hvis ikke, legg dem til. - Sjekk autorisasjonslogikk: Gå gjennom hvert endepunkt. Spør deg selv: «Hvem skal kunne gjøre dette?» Hvis du ikke kan svare med en rolle eller attributt - så mangler du en sjekk.
- Legg til rate limiting: Bruk
express-rate-limiteller en lignende middelvare. Sett grensen til 100 forespørsler per 15 minutter per IP. - Test med autorisasjonsbypass: Logg inn som en vanlig bruker. Prøv å få tilgang til admin-endepunkter. Prøv å slette andre brukeres data. Hvis det fungerer - har du en sårbarhet.
Det tar 35-50 % av totalt tid å gjøre dette. Ikke 10 %. Ikke 20 %. 35-50 %. Det er ikke et valg. Det er en nødvendighet.
Hva sier eksperter?
Naomi Buckwalter, hovedsikkerhetsspesialist ved ReversingLabs, sier: «AI forstår ikke dine spesifikke autorisasjonskrav. Den kan bare implementere det du eksplisitt beskriver.»
FusionAuths CTO, Brian Pontarelli, sier: «AI-genererte JWT-implentasjoner bruker ofte hardcoded hemmeligheter og glemmer å validere tokens. Det er en kritisk sårbarhet.»
Men det er ikke bare kritikk. Rocket.news utviklerteam sier: «Med riktig etterbehandling kan vibe coding produsere systemer som er like sikre som manuell kode.»
Det er sant. Men bare hvis du vet hva du gjør. Hvis du ikke vet om OAuth 2.0, JWT, eller RBAC - så vil du ikke kunne gjenkjenne feilene. AI vil ikke fortelle deg at du har en sikkerhetsfeil. Den vil bare lage kode som ser ut som den fungerer.
Hva er i utvikling?
Det er ikke bare deg og AI. Markedet reagerer.
GitHub la i januar 2026 ut «Copilot Security Guardrails» - en funksjon som automatisk markerer 45 % av usikre autentiseringsmønstre mens du skriver. Snyk Code og andre verktøy har lagt til spesifikke sjekker for vibe coding.
Cloud Security Alliance har utgitt en «Secure Vibe Coding Framework» med forhåndsdefinerte prompt-maler. Eksempel: «Implementer OAuth 2.0 Authorization Code Flow med PKCE. Bruk JWT med 30-minutters access-token og 7-dagers refresh-token. Implementer RBAC med roller admin, editor, viewer. Sjekk autorisasjon på hvert endepunkt. Bruk HTTP-only, Secure, SameSite=Strict cookies. Legg til rate limiting på 100 forespørsler per 15 minutter.»
Det er ikke lenger nok å si: «Lag en login.» Du må si: «Lag en sikker login.»
Hva er fremtiden?
Det er ikke AI som vil løse dette. Det er deg.
Den eneste måten å gjøre vibe coding trygg er å ha en grundig forståelse av autentisering og autorisasjon. Hvis du ikke vet hva en refresh-token er, eller hvorfor PKCE er viktig - så vil du aldri kunne identifisere feilene.
Gartner forutsetter at i 2027 vil 60 % av vibe-kodete autentiseringsløsninger ha innebygde sikkerhetsvalideringer - opp fra 18 % i 2025. Men det er ikke en teknologisk løsning. Det er en kulturell. Det handler om utviklere som ikke lenger aksepterer «det ser ut som det fungerer» som et svar.
Denne fremtiden kommer ikke fra AI. Den kommer fra deg som tar tid til å sjekke, teste, og forstå. Ikke fordi AI er dårlig. Fordi du er den eneste som kan tenke.
Hvorfor er JWT-sikkerhet så viktig i vibe coding?
AI genererer ofte JWT-tokens med hardcoded hemmeligheter, uendelig gyldighet, og ingen validering. Dette gjør det mulig for angripere å signere egne tokens, stjele data, eller ta over kontoer. En sikker JWT må ha en kort utløpsdato (15-60 minutter), en sikker hemmelighet lagret i miljøvariabler, og en token-valideringsmekanisme som sjekker signatur, utløpsdato og utsteder.
Kan jeg bruke AI til å lage autorisasjonsregler?
Nei. AI kan ikke lage autorisasjonsregler uten eksplisitte instruksjoner. Den forstår ikke din applikasjon. Den vet ikke hvilke brukere skal ha tilgang til hvilke data. Du må skrive inn reglene manuelt: «Kun admin kan slette brukere», «Kun eieren kan endre dokumentet». Ingen AI vil gjøre dette for deg - og hvis du ikke skriver det, vil ingen sjekk eksistere.
Hva er forskjellen mellom autentisering og autorisasjon?
Autentisering er å bekrefte at du er hvem du sier du er - for eksempel ved å logge inn med brukernavn og passord. Autorisasjon er å bestemme hva du har lov til å gjøre etter du har blitt autentisert - for eksempel om du kan slette en post, se en konto, eller endre innstillinger. AI er flink til autentisering, men dårlig til autorisasjon - og det er der sikkerhetsproblemene kommer fra.
Hvorfor er OAuth 2.0 Authorization Code Flow med PKCE bedre enn Implicit Grant?
Implicit Grant sender tokens direkte via nettleseren - noe som gjør dem lett å stjele. Authorization Code Flow bruker en midlertidig kode som sendes til serveren, som da bytter den mot en token. PKCE legger til en kodechallenge som bare den originale klienten kan bruke. Dette gjør det umulig for angripere å bruke stjålne tokens, selv om de får tak i dem. AI bruker ofte Implicit Grant fordi den er enklere å generere - men den er farlig.
Hva skal jeg gjøre hvis jeg har en eksisterende vibe-kodet backend?
Start med å sjekke tre ting: 1) Er hemmelighetene hardkodet? 2) Har du autorisasjonskontroller på alle endepunkter? 3) Har du rate limiting og sikre cookies? Hvis svaret er nei på noen av disse - så er systemet ikke trygt. Lag en liste over alle endepunkter og sjekk hver for seg. Bruk en verktøy som Snyk Code eller GitHub Advanced Security for å finne kjente sårbarheter. Det vil ta tid, men det er bedre enn å vente til en angripere kommer.
Post Comments (1)
Enkel sak. Ikke komplisert. Bare nødvendig.