API-nøkler og tokens: slik håndterer du autentisering trygt i små webprosjekter

Mange som bygger sine første nettsider eller små webapper oppdager fort at de må snakke med et API. Det kan være betaling, kart, e‑postutsendelse eller egen backend. Da dukker ord som API-nøkkel, token og bearer opp, og det er ikke alltid åpenbart hvordan dette bør håndteres trygt.
Denne guiden gir en jordnær forklaring på hva disse begrepene betyr, hvordan du bør bruke dem i frontend og backend, og hvilke enkle grep som reduserer risiko betydelig i små og mellomstore prosjekter.
Hva er en API-nøkkel, og hva er et token?
En API-nøkkel er typisk en lang streng som identifiserer applikasjonen din mot en ekstern tjeneste. Den brukes ofte for å begrense trafikk og se hvem som gjør hva, og ganske ofte også som en form for «passord» for appen din.
Et token er et mer generelt begrep for en streng som gir tilgang. Det kan være knyttet til en bruker, til en sesjon eller til en bestemt rettighet. I moderne API-er brukes ofte tokens (for eksempel JWT) for innlogging og autorisasjon.
Hvorfor du aldri bør legge hemmeligheter rett i frontend
All kode som sendes til nettleseren kan i prinsippet leses av hvem som helst. Det gjelder JavaScript, innebygde variabler, kommentert kode og statiske filer. Legger du en API-nøkkel der, er den ikke lenger hemmelig.
Selv om du tenker at API-et har liten verdi, kan en lekket nøkkel føre til uventet trafikk, misbruk eller kostnader. Noen vil også kunne hente ut mer data enn du hadde tenkt å dele.
Typiske feil i småprosjekter
- Hardkode API-nøkler i JavaScript-filer som ligger åpent i produksjon.
- Lagre hemmeligheter i .env-filer som ved en feil pushes til GitHub.
- Bruke samme nøkkel til alt, uten å begrense tilganger eller domener.
En enkel tommelfingerregel: Hvis noe kalles «key», «secret» eller «token» i dokumentasjonen, skal det som hovedregel ikke ligge synlig i frontend-koden din.
Frontend mot API: hva er egentlig trygt å ha i nettleseren?
Noe informasjon må ligge i frontend for at siden skal fungere, for eksempel et offentlig kart-ID eller et «public key»-felt som eksplisitt er ment for nettlesere. Slike nøkler har normalt begrensede rettigheter og omtales gjerne som public eller client side.
Det du bør styre unna i nettleseren, er nøkler og tokens som gir bred tilgang: administrativ tilgang, skrivetilgang til data eller mulighet til å gjøre kostbare kall.
En enkel tommelfingerregel for frontend
- Ok i frontend: nøkler som dokumentasjonen eksplisitt omtaler som «public» eller «client-side» og som typisk bare kan lese åpne data.
- Ikke ok i frontend: API-nøkler som gir tilgang til brukerdata, skriveoperasjoner, fakturering eller administrasjon.
Hvis du er usikker på om en nøkkel kan ligge i frontend, er en trygg løsning å rute kallene gjennom din egen backend i stedet.
Sett opp en enkel backend som mellomledd
En liten backend fungerer som en dørvakt mellom nettleseren og eksterne API-er. Frontend sender en forespørsel til din backend, og backend kaller videre til tredjepart med skjulte nøkler og tokens.
Dette gir deg bedre kontroll på hva som kan gjøres, hvem som kan gjøre det, og hvor mye som kan kalles. Du kan også legge på enkel logging og rate limiting etter behov.
Eksempel med fetch fra frontend til backend
Tenk deg at du har et Node-basert API-endepunkt på/api/weathersom snakker med en ekstern vær-tjeneste. I frontend kan du da gjøre noe ala:
Frontend (JavaScript):
Her kaller du bare din egen backend, uten hemmeligheter i nettleseren.
Miljøvariabler: skjul nøkler uten å forvirre deg selv

Miljøvariabler er en utbredt måte å lagre hemmeligheter og konfigurasjon i backend. I stedet for å hardkode nøkler i koden, henviser du til dem via prosessvariabler eller rammeverkets opplegg for konfigurasjon.
Dette gjør det enklere å ha ulike nøkler for utvikling, test og produksjon, og du minimerer sjansen for å sjekke inn hemmeligheter i Git.
Enkle leveregler for miljøvariabler
- Legg aldri .env-filer i versjonskontroll, legg dem til i .gitignore.
- Bruk ulike nøkler for ulike miljøer, og generer nye ved mistanke om lekkasje.
- Gi variabler meningsfulle navn, for eksempelPAYMENT_API_KEYi stedet for bareKEY.
Hvis du bruker hosting-plattformer, har de ofte egne paneler for konfigurasjonsnøkler. Bruk dem, og dokumenter hvilke variabler som trengs i prosjektet.
Hvordan håndtere tokens for innlogging
Når du har egen innlogging, vil du ofte bruke et token for å huske at en person er autentisert. Typiske valg er session cookies eller tokens som lagres i nettleseren. Hvert valg har fordeler og ulemper, og sikkerhetsmessige konsekvenser.
For små apper er det ofte trygt å starte med sessions og cookies håndtert av backend-rammeverket ditt, så lenge du skrur på sikkerhetsflagg og bruker HTTPS.
Noen enkle sikkerhetsgrep for innlogging
- Bruk HTTPS i alle miljøer der ekte data brukes.
- Sett cookies til HTTPOnly og Secure der det gir mening, så blir de vanskeligere å stjele via skript.
- Gi tokens rimelig kort levetid, og støtt utlogging ved å slette eller gjøre dem ugyldige.
Hvis du senere går over til mer avanserte oppsett med for eksempel JWT, er det lurt å sette seg inn i hvordan du kan håndtere utløp, fornyelse og tilbakekalling på en forståelig måte.
Begrens tilganger og overvåk bruk
De fleste API-leverandører gir mulighet til å begrense hva en nøkkel kan gjøre, for eksempel hvilke endepunkter som kan kalles, hvilke domener som får lov å bruke den, eller hvilken IP-adresse den må komme fra.
Ved å begrense tilganger og følge litt med på logg eller statistikk, kan du oppdage misbruk tidlig og begrense konsekvensene om en nøkkel likevel skulle lekke.
Konkrete ting du kan gjøre i små prosjekter
- Opprett egne nøkler for frontend og backend, med smalest mulige rettigheter.
- Skru på domene- eller IP-begrensninger der leverandøren støtter det.
- Sjekk jevnlig bruksstatistikk i kontrollpanelet til API-leverandøren.
Hvis du oppdager noe uvanlig, kan du ofte rotere nøkler, midlertidig sperre dem, eller legge til strengere begrensninger uten å endre hele koden.
Oppsummering: enkle rutiner gir mye bedre sikkerhet
Sikker håndtering av API-nøkler og tokens trenger ikke være komplisert, men det krever noen faste vaner. Ikke legg hemmeligheter i frontend, bruk en liten backend som mellomledd, og skjul nøkler i miljøvariabler på serveren.
Start enkelt, skriv ned hvordan nøklene dine er satt opp, og gjør det til en rutine å vurdere tilgangsnivå, begrensninger og logg når du kobler deg til nye API-er. Da bygger du løsninger som er langt mer robuste, selv om prosjektet er lite.









0 kommentarer