Slik holder du API-nøkler trygge i appen din

For å holde API-nøkler trygge, lagrer du dem som hemmeligheter eller miljøvariabler hos hosten din, bruker dem bare i kode på serveren, og limer dem aldri inn i chatten, kodefiler, skjermbilder eller et Git-repositorium. Gi hver nøkkel minst mulig tillatelse, sett forbruksgrenser hos leverandøren, og hvis en nøkkel noen gang lekker, roter den — lag en ny og slett den gamle — i stedet for bare å skjule hvor den dukket opp.

En API-nøkkel er et passord for en tjeneste. OpenAI-nøkkelen din lar noen bruke pengene dine på AI; din hemmelige Stripe-nøkkel lar noen utstede refusjoner; nøkkelen til e-postleverandøren din lar noen sende e-post som deg. AI-appbyggere er gode til å koble dem inn, men er ikke alltid nøye med hvor de havner, så denne guiden viser hvordan du holder dem trygge og hvordan du sjekker.

Offentlige nøkler kontra hemmelige nøkler

Ikke alle nøkler er hemmelige. Å vite forskjellen hindrer deg i å bekymre deg for feil nøkkel og ignorere den riktige.

Hvis du er usikker på hvilken type en nøkkel er, sjekk leverandørens dokumentasjon. Når du er i tvil, behandle den som hemmelig.

Steg 1: Lagre nøkler som hemmeligheter, ikke i koden

Nøkler hører hjemme i hostens miljøvariabler eller hemmelighetsinnstillinger. Koden din leser dem med navn når den kjører (for eksempel process.env.OPENAI_API_KEY), slik at verdien aldri står i filene dine. For bakgrunnen, se hva miljøvariabler og hemmeligheter er.

Flytt alle API-nøkler ut av koden og inn i miljøvariabler. List opp hver nøkkel du fant, hvilken fil den var i, og variabelnavnet du brukte. Ikke vis meg verdiene.

Sjekk deretter at ingenting er igjen:

Søk gjennom hele prosjektet, inkludert konfigurasjonsfiler og eventuelle .env-filer, etter alt som ligner en API-nøkkel eller et passord. Rapporter fil og linje, ikke verdien.

Steg 2: Bruk hemmelige nøkler bare på serveren

Dette er regelen som betyr mest. Alt nettleseren mottar, kan en besøkende lese — kildekoden og JavaScript-filene er synlige i utviklerverktøyene.

Så hvis appen trenger å kalle OpenAI, bør nettleseren kalle din server, og serveren din kaller OpenAI med nøkkelen. Nøkkelen forlater aldri serveren.

Chatfunksjonen kaller OpenAI direkte fra nettleseren. Flytt det kallet til en API-rute på serveren som leser OPENAI_API_KEY fra miljøet. Nettleseren skal bare kalle ruten vår. Krev innlogging for ruten.

Vær oppmerksom på en vanlig felle i frontend-rammeverk: variabler med et offentlig prefiks — VITE_ i Vite, NEXT_PUBLIC_ i Next.js — bygges inn i nettleserkoden med vilje. En hemmelig nøkkel med ett av disse prefiksene er eksponert, selv om den står «i en miljøvariabel».

Steg 3: Test at ingenting lekker

Ikke stol på at det fungerte — sjekk den live siden:

1. Åpne den publiserte appen i en nettleser.
2. Åpne utviklerverktøyene, og deretter fanen Sources eller Network.
3. Søk på tvers av filene etter de første tegnene i hver hemmelig nøkkel (for eksempel sk_ eller sk-).
4. Sjekk nettverksforespørslene appen gjør. En forespørsel som går rett fra nettleseren til en betalt AI-leverandør er et rødt flagg.

Hvis du finner en hemmelig nøkkel, flytt den til serveren (steg 2) og roter den (steg 6), fordi den allerede var offentlig.

Steg 4: Begrens hva hver nøkkel kan gjøre

Mange leverandører lar deg begrense en nøkkel:

• Avgrensede eller begrensede nøkler som bare kan gjøre det appen trenger. Stripe for eksempel støtter begrensede nøkler med spesifikke tillatelser.
• Domene- eller IP-begrensninger for nøkler som må være offentlige, som kartnøkler.
• Separate nøkler per app og per miljø, slik at én lekkasje ikke eksponerer alt, og tilbakekalling av én ikke ødelegger de andre.
• Testnøkler mens du bygger, og live-nøkler bare i den publiserte appen.

Steg 5: Sett et tak på skaden

Selv en godt beskyttet nøkkel kan misbrukes gjennom din egen app — for eksempel hvis noen skripter AI-funksjonen din tusenvis av ganger.

• Sett forbruksgrenser eller varsler hos hver betalt leverandør.
• Krev innlogging for funksjoner som koster penger per kall.
• Legg til en grense per bruker. Se hva hastighetsbegrensning er.

Legg til en grense på 30 AI-forespørsler per bruker per time for /api/chat. Returner en tydelig melding når grensen er nådd. Avvis forespørsler fra brukere som ikke er innlogget.

Steg 6: Roter nøkler som lekker

Hvis en hemmelig nøkkel dukker opp et sted den ikke skulle — en chatmelding, en commit, et skjermbilde, en supportsak, nettleserkode — anta at den er kompromittert.

1. Lag en ny nøkkel hos leverandøren.
2. Oppdater hemmeligheten i appens innstillinger.
3. Deploy eller publiser på nytt slik at den live appen bruker den nye nøkkelen.
4. Slett den gamle nøkkelen hos leverandøren.
5. Sjekk leverandørens bruksloggene for aktivitet du ikke gjenkjenner.

Å slette chatmeldingen eller Git-commiten er ikke nok. Git-historikken beholder gamle versjoner, og alt som var offentlig kan allerede være kopiert.

Vanlige feil

• Å lime en nøkkel inn i prompten. Den er nå i chatteloggen. Bruk et skjema for hemmeligheter i stedet.
• Et offentlig prefiks på en hemmelig variabel. VITE_OPENAI_API_KEY sender nøkkelen til alle besøkende.
• Å committe en .env-fil. Sørg for at den står i .gitignore før første push.
• Én nøkkel overalt. Bruk separate nøkler for test og live, og for hver app.
• Ingen forbruksgrense. En lekket eller misbrukt nøkkel uten tak kan øke regningen før du legger merke til det.
• Å skjule i stedet for å rotere. Når en nøkkel har vært eksponert, er det bare en ny nøkkel som løser problemet.
• Nøkler i skjermbilder. Beskjær eller slør innstillingssider før du deler dem for å få hjelp.

Sjekkliste

• Hver nøkkel er lagret som en hemmelighet eller miljøvariabel, ikke i koden.
• Ingen .env-fil eller nøkkel er committet til Git.
• Hemmelige nøkler brukes bare i kode på serveren.
• Ingen hemmelig variabel bruker et offentlig prefiks som VITE_ eller NEXT_PUBLIC_.
• Jeg søkte gjennom JavaScript på den live siden etter hvert nøkkelprefiks og fant ingenting.
• Nøkler er avgrenset eller begrenset der leverandøren tillater det.
• Test- og live-nøkler er separate.
• Betalte funksjoner krever innlogging og har grenser per bruker.
• Hver betalt leverandør har et forbruksstak eller varsel.
• Jeg vet hvordan hver nøkkel roteres, og alle nøkler som noen gang var eksponert er rotert.

Holde nøkler trygge på Mythex

Mythex holder nøkler ute av koden og chatten på to måter:

• Kort for forespørsel om hemmeligheter. Når agenten trenger en nøkkel, viser den et kort i chatten der du skriver verdien inn i skjemafelt, ikke i meldingsboksen, og den lagres som en prosjekthemmelighet. Se Hemmeligheter i chatten.
• Prosjektinnstillinger → Secrets, eller /secrets i chatten, for å legge til eller endre nøkler selv. Se Miljøvariabler og hemmeligheter.

Etter at du har endret en hemmelighet for en publisert app, publiser på nytt slik at den live appen tar den i bruk. Eksporterte prosjekter utelater hemmeligheter, så legg dem til igjen der du kjører koden neste gang. Hvis en nøkkel noen gang havner i chatten, roter den hos leverandøren.

For resten av sikkerhetsgjennomgangen før lansering, gå gjennom sikkerhetssjekklisten for AI-bygde apper. Hvis du legger til AI-funksjoner, dekker slik bruker du LLM-API-er nøkler og kostnader mer grundig.

Spørsmål