Hogyan őrizd biztonságban az API-kulcsaidat az appodban

Az API-kulcsok biztonságban tartásához tárold őket titokként vagy környezeti változóként a hosztodon, csak szerveroldali kódban használd, és soha ne illeszd be csevegésbe, kódfájlba, képernyőképre vagy Git-repóba. Minden kulcsnak csak a szükséges minimális jogosultságot add, állíts be költséghatárt a szolgáltatónál, és ha egy kulcs mégis kiszivárog, cseréld le — hozz létre újat, és töröld a régit —, ne csak elrejtsd azt a helyet, ahol megjelent.

Az API-kulcs egy szolgáltatás jelszava. Az OpenAI-kulcsoddal valaki AI-ra költhet a pénzedből; a Stripe titkos kulcsával visszatérítéseket adhat ki; az e-mail-szolgáltatód kulcsával e-mailt küldhet a nevedben. Az AI-építő eszközök jók abban, hogy ezeket bekötik, de nem mindig figyelnek arra, hová kerülnek, ezért ez az útmutató arról szól, hogyan őrizd őket biztonságban, és hogyan ellenőrizd.

Nyilvános és titkos kulcsok

Nem minden kulcs titkos. Ha tudod a különbséget, nem pánikolsz a rossz kulcs miatt, és nem hagyod figyelmen kívül a jót.

Ha nem vagy biztos benne, melyik típus egy kulcs, nézd meg a szolgáltató dokumentációját. Kétség esetén kezeld titokként.

1. lépés: Tárold a kulcsokat titokként, ne a kódban

A kulcsok a hosztod környezeti változóiba vagy titok beállításaiba tartoznak. A kódod futásidőben név szerint olvassa őket (például process.env.OPENAI_API_KEY), így az érték soha nem jelenik meg a fájljaidban. A háttérhez lásd: mik a környezeti változók és a titkok.

Vidd ki az összes API-kulcsot a kódból környezeti változókba. Sorold fel minden kulcsot, amit találtál, melyik fájlban volt, és mi lett a változónév. Ne mutasd meg az értékeket.

Utána ellenőrizd, hogy nem maradt semmi:

Keress a teljes projektben, a konfigurációs fájlokat és a .env fájlokat is beleértve, bármit, ami API-kulcsnak vagy jelszónak néz ki. A fájlt és a sort add meg, az értéket ne.

2. lépés: A titkos kulcsokat csak a szerveren használd

Ez a legfontosabb szabály. Bármit, amit a böngésző megkap, a látogató elolvashat — a forráskód és a JavaScript-fájlok láthatók a fejlesztői eszközökben.

Ha tehát az appnak OpenAI-t kell hívnia, a böngésző a te szerveredet hívja, a szervered pedig az OpenAI-t a kulccsal. A kulcs soha nem hagyja el a szervert.

A csevegési funkció közvetlenül a böngészőből hívja az OpenAI-t. Vidd át ezt a hívást egy szerveroldali API-útvonalra, amely az OPENAI_API_KEY értéket a környezetből olvassa. A böngésző csak a mi útvonalunkat hívja. Az útvonalhoz bejelentkezés kötelező.

Egy gyakori csapda a frontend-keretrendszerekben: a publikus előtaggal rendelkező változók — VITE_ a Vite-ban, NEXT_PUBLIC_ a Next.js-ben — szándékosan beépülnek a böngészőkódba. Egy titkos kulcs ilyen előtaggal kiszivárog, még akkor is, ha „környezeti változóban van”.

3. lépés: Teszteld, hogy semmi nem szivárog

Ne bízz abban, hogy működik — ellenőrizd az élő oldalon:

1. Nyisd meg a publikált appot böngészőben.
2. Nyisd meg a fejlesztői eszközöket, majd a Sources vagy a Network fület.
3. Keress a fájlokban az egyes titkos kulcsok első karaktereire (például sk_ vagy sk-).
4. Nézd meg, milyen hálózati kéréseket küld az app. Egy kérés, amely közvetlenül a böngészőből megy egy fizetős AI-szolgáltatóhoz, vörös jelzés.

Ha titkos kulcsot találsz, vidd a szerverre (2. lépés), és cseréld le (6. lépés), mert már nyilvánossá vált.

4. lépés: Korlátozd, mit tehet egy-egy kulcs

Sok szolgáltató lehetővé teszi, hogy korlátozz egy kulcsot:

• Hatókörös vagy korlátozott kulcsok, amelyek csak azt tudják, amire az appnak szüksége van. A Stripe például támogatja a meghatározott jogosultságokkal rendelkező korlátozott kulcsokat.
• Domain- vagy IP-korlátozás olyan kulcsoknál, amelyeknek nyilvánosnak kell lenniük, például térképes kulcsoknál.
• Külön kulcsok apponként és környezetenként, hogy egy kiszivárgás ne tegyen ki mindent, és egy visszavonás ne törjön el másokat.
• Teszt kulcsok fejlesztés közben, élő kulcsok csak a publikált appban.

5. lépés: Korlátozd a kárt

A jól védett kulcsot is vissza lehet élni az appon keresztül — például valaki ezer alkalommal scripteli az AI-funkciódat.

• Állíts be költséghatárt vagy riasztást minden fizetős szolgáltatónál.
• Kötelező bejelentkezés minden olyan funkciónál, amely hívásonként pénzbe kerül.
• Adj hozzá felhasználónkénti sebességkorlátot. Lásd: mi az a sebességkorlátozás.

Adj korlátot: felhasználónként óránként 30 AI-kérés a /api/chat útvonalon. Ha elérte a korlátot, mutass világos üzenetet. Utasíts el minden kérést, amely nincs bejelentkezve.

6. lépés: Cseréld le a kiszivárgott kulcsokat

Ha egy titkos kulcs olyan helyre került, ahová nem kellett volna — csevegési üzenet, commit, képernyőkép, támogatási jegy, böngészőkód —, tekintsd kompromittáltnak.

1. Hozz létre új kulcsot a szolgáltatónál.
2. Frissítsd a titkot az app beállításaiban.
3. Telepítsd újra vagy publikálj újra, hogy az élő app az új kulcsot használja.
4. Töröld a régi kulcsot a szolgáltatónál.
5. Nézd át a szolgáltató használati naplóit, hogy nem látsz-e ismeretlen tevékenységet.

Az üzenet vagy a Git-commit törlése nem elég. A Git-előzmények megőrzik a régi verziókat, és ami nyilvános volt, azt már másolhatták.

Gyakori hibák

• Kulcs beillesztése a promptba. Most már a csevegési előzményekben van. Helyette használj titkos űrlapot.
• Nyilvános előtag egy titkos változón. A VITE_OPENAI_API_KEY minden látogatónak kiszolgáltatja a kulcsot.
• .env fájl commitolása. Győződj meg róla, hogy a .gitignore-ban van, mielőtt az első push megtörténik.
• Egy kulcs mindenhol. Használj külön kulcsokat tesztre és élesre, és apponként is.
• Nincs költséghatár. Egy kiszivárgott vagy visszaélt kulcs korlát nélkül nagy számlát okozhat, mielőtt észrevennéd.
• Elrejtés csere helyett. Ha egy kulcs egyszer kiszivárgott, csak egy új kulcs old meg.
• Kulcsok a képernyőképeken. Vágd le vagy homályosítsd a beállítási oldalakat, mielőtt segítségért megosztod őket.

Ellenőrzőlista

• Minden kulcs titokként vagy környezeti változóként van tárolva, nem a kódban.
• Nincs .env fájl vagy kulcs commitolva a Gitbe.
• A titkos kulcsokat csak szerveroldali kód használja.
• Egyetlen titkos változó sem használ nyilvános előtagot, mint a VITE_ vagy NEXT_PUBLIC_.
• Az élő oldal JavaScriptjében minden kulcs előtagjára kerestem, és nem találtam semmit.
• A kulcsok korlátozva vannak, ahol a szolgáltató lehetővé teszi.
• A teszt és az éles kulcsok el vannak választva.
• A fizetős funkciókhoz kötelező a bejelentkezés, és van felhasználónkénti korlát.
• Minden fizetős szolgáltatónál van költséghatár vagy riasztás.
• Tudom, hogyan cseréljem le az egyes kulcsokat, és minden kiszivárgott kulcsot lecseréltem.

API-kulcsok biztonsága a Mythexen

A Mythex kétféleképpen tartja távol a kulcsokat a kódodtól és a csevegéstől:

• Titokkérő kártya. Amikor az ágensnek kulcsra van szüksége, a csevegésben megjelenik egy kártya, ahol az értéket űrlapmezőkbe írod, nem az üzenetmezőbe; a kulcs projekt-titokként tárolódik. Lásd: Titkok a csevegésben.
• Projektbeállítások → Titkok, vagy a /secrets a csevegésben, ahol magad adhatsz hozzá vagy módosíthatsz kulcsokat. Lásd: Környezeti változók és titkok.

Egy közzétett app titkának módosítása után publikálj újra, hogy az élő app átvegye. Az exportált projektekből a titkok kimaradnak, ezért ott, ahol a kódot futtatod, add újra őket. Ha egy kulcs valaha a csevegésbe került, cseréld le a szolgáltatónál.

A publikálás előtti biztonsági átnézés további részeihez járd végig a biztonsági ellenőrzőlistát AI-val épített appokhoz. Ha AI-funkciókat adsz hozzá, a hogyan használj LLM API-kat mélyebben tárgyalja a kulcsokat és a költségeket.

Kérdések