Så håller du API-nycklar säkra i din app

För att hålla API-nycklar säkra, lagra dem som hemligheter eller miljövariabler hos din värd, använd dem bara i kod på servern och klistra aldrig in dem i chatten, kodfiler, skärmbilder eller ett Git-repo. Ge varje nyckel minsta möjliga behörighet, sätt utgiftsgränser hos leverantören, och om en nyckel någonsin läcker, rotera den: skapa en ny och ta bort den gamla, i stället för att bara dölja var den dök upp.

En API-nyckel är ett lösenord till en tjänst. Din OpenAI-nyckel låter någon spendera dina pengar på AI; din Stripe-hemliga nyckel låter någon göra återbetalningar; din mejlleverantörsnyckel låter någon skicka mejl i ditt namn. AI-appbyggare är bra på att koppla in dessa, men inte alltid noga med var de hamnar, så den här guiden visar hur du håller dem säkra och hur du kontrollerar det.

Publika nycklar kontra hemliga nycklar

Ett nyckel är inte alltid hemlig. Att veta skillnaden hindrar dig från att panikera över fel nyckel och ignorera rätt.

Om du inte är säker på vilken typ en nyckel är, kontrollera leverantörens dokumentation. Vid tveksamhet, behandla den som hemlig.

Steg 1: Lagra nycklar som hemligheter, inte i koden

Nycklar hör hemma i din hosts miljövariabler eller hemlighets-inställningar. Din kod läser dem med namn vid körning (till exempel process.env.OPENAI_API_KEY), så värdet syns aldrig i dina filer. För bakgrunden, se vad miljövariabler och hemligheter är.

Flytta varje API-nyckel från koden till miljövariabler. Lista varje nyckel du hittade, i vilken fil den satt och vilket variabelnamn du använde. Visa inte värdena.

Kontrollera sedan att inget finns kvar:

Sök i hela projektet, inklusive konfigurationsfiler och eventuella .env-filer, efter allt som ser ut som en API-nyckel eller ett lösenord. Rapportera fil och rad, inte värdet.

Steg 2: Använd hemliga nycklar bara på servern

Detta är regeln som betyder mest. Allt webbläsaren tar emot kan en besökare läsa; sidans källkod och JavaScript-filerna syns i utvecklarverktygen.

Om appen behöver anropa OpenAI ska alltså webbläsaren anropa din server, och din server anropar OpenAI med nyckeln. Nyckeln lämnar aldrig servern.

Chattfunktionen anropar OpenAI direkt från webbläsaren. Flytta det anropet till en API-route på servern som läser OPENAI_API_KEY från miljön. Webbläsaren ska bara anropa vår route. Kräv inloggning för routen.

Var uppmärksam på en vanlig fälla i frontend-ramverk: variabler med ett publikt prefix, VITE_ i Vite, NEXT_PUBLIC_ i Next.js, byggs med avsikt in i kod för webbläsaren. En hemlig nyckel med ett sådant prefix är exponerad, även om den ligger ”i en miljövariabel”.

Steg 3: Testa att inget läcker

Lita inte på att det fungerade, kontrollera den publicerade sajten:

1. Öppna den publicerade appen i en webbläsare.
2. Öppna utvecklarverktygen, sedan fliken Sources eller Network.
3. Sök över filerna efter de första tecknen i varje hemlig nyckel (till exempel sk_ eller sk-).
4. Kontrollera nätverksanropen som appen gör. Ett anrop som går direkt från webbläsaren till en betald AI-leverantör är en röd flagga.

Hittar du en hemlig nyckel, flytta den till servern (steg 2) och rotera den (steg 6), eftersom den redan var offentlig.

Steg 4: Begränsa vad varje nyckel kan göra

Många leverantörer låter dig begränsa en nyckel:

• Scopade eller begränsade nycklar som bara kan göra det din app behöver. Stripe stöder till exempel begränsade nycklar med specifika behörigheter.
• Domän- eller IP-begränsningar för nycklar som måste vara publika, till exempel kartnycklar.
• Separata nycklar per app och per miljö, så att ett läckage inte exponerar allt, och att återkalla en inte bryter de andra.
• Testnycklar under byggandet, och skarpa nycklar endast i den publicerade appen.

Steg 5: Sätt ett tak på skadan

Även en väl skyddad nyckel kan missbrukas genom din egen app, till exempel om någon skriptar din AI-funktion tusentals gånger.

• Sätt utgiftsgränser eller aviseringar hos varje betald leverantör.
• Kräv inloggning för varje funktion som kostar pengar per anrop.
• Lägg till en gräns per användare. Se vad rate limiting är.

Lägg till en gräns på 30 AI-förfrågningar per användare och timme till /api/chat. Returnera ett tydligt meddelande när gränsen nås. Avvisa förfrågningar från användare som inte är inloggade.

Steg 6: Rotera nycklar som läcker

Om en hemlig nyckel dyker upp någonstans den inte borde, i ett chattmeddelande, en commit, en skärmbild, ett supportärende, kod i webbläsaren, anta att den är komprometterad.

1. Skapa en ny nyckel hos leverantören.
2. Uppdatera hemligheten i din apps inställningar.
3. Driftsätt eller publicera igen så att den live-appen använder den nya nyckeln.
4. Ta bort den gamla nyckeln hos leverantören.
5. Kontrollera leverantörens användningsloggar för aktivitet du inte känner igen.

Att radera chattmeddelandet eller Git-committen räcker inte. Git-historiken sparar gamla versioner, och allt som varit publikt kan redan ha kopierats.

Vanliga misstag

• Att klistra in en nyckel i prompten. Den hamnar nu i chatthistoriken. Använd ett hemlighetsformulär i stället.
• Ett publikt prefix på en hemlig variabel. VITE_OPENAI_API_KEY skickar nyckeln till varje besökare.
• Att committa en .env-fil. Se till att den finns i .gitignore innan första pushen.
• En nyckel överallt. Använd separata nycklar för test och skarpt, och för varje app.
• Ingen utgiftsgräns. En läckt eller missbrukad nyckel utan tak kan köra upp en stor räkning innan du märker det.
• Att gömma i stället för att rotera. När en nyckel väl exponerats åtgärdar bara en ny nyckel problemet.
• Nycklar i skärmbilder. Beskär eller sudda ut inställningssidor innan du delar dem för hjälp.

Checklista

• Varje nyckel är lagrad som en hemlighet eller miljövariabel, inte i koden.
• Ingen .env-fil eller nyckel är committad till Git.
• Hemliga nycklar används endast i kod på servern.
• Ingen hemlig variabel använder ett publikt prefix som VITE_ eller NEXT_PUBLIC_.
• Jag sökte i den live-sajtens JavaScript efter varje nycklars prefix och hittade inget.
• Nycklar är scopade eller begränsade där leverantören tillåter det.
• Test- och skarpa nycklar är separata.
• Betalda funktioner kräver inloggning och har gränser per användare.
• Varje betald leverantör har ett utgiftstak eller en avisering.
• Jag vet hur jag roterar varje nyckel, och alla nycklar som någon gång exponerats har roterats.

Att hålla nycklar säkra på Mythex

Mythex håller nycklar borta från din kod och chatt på två sätt:

• Kortet för hemlighetsbegäran. När agenten behöver en nyckel visar den ett kort i chatten där du skriver in värdet i formulärfält, inte i meddelanderutan, och det lagras som en projekthemlighet. Se Hemligheter i chatten.
• Projektinställningar → Hemligheter, eller /secrets i chatten, för att lägga till eller ändra nycklar själv. Se Miljövariabler och hemligheter.

Efter att du ändrat en hemlighet för en publicerad app, publicera igen så att den live-appen får med sig den. Exporterade projekt utesluter hemligheter, så lägg till dem igen där du kör koden nästa gång. Om en nyckel någonsin dyker upp i chatten, rotera den hos leverantören.

För resten av säkerhetsgenomgången före lansering, gå igenom säkerhetschecklistan för AI-byggda appar. Om du lägger till AI-funktioner täcker hur du använder LLM-API:er nycklar och kostnader mer ingående.

Frågor