Paano Panatilihing Ligtas ang API Key sa Iyong App

Para panatilihing ligtas ang API key, itago ang mga ito bilang secrets o environment variables sa host mo, gamitin lang sa server-side code, at huwag kailanman i-paste sa chat, code file, screenshot, o Git repository. Bigyan ang bawat key ng pinakamababang pahintulot na kailangan nito, magtakda ng spending limit sa provider, at kapag may nalantad na key, palitan ito. Gumawa ng bago at burahin ang luma, sa halip na itago lang ang lugar kung saan ito lumitaw.

Ang API key ay parang password para sa isang serbisyo. Ang OpenAI key mo ay nagpapahintulot sa iba na gumastos ng pera mo sa AI; ang Stripe secret key mo ay nagpapahintulot sa iba na mag-refund; ang email provider key mo ay nagpapahintulot sa iba na magpadala ng mail bilang ikaw. Magaling ang mga AI app builder sa pagkonekta ng mga ito, pero hindi laging maingat kung saan napupunta ang mga ito, kaya sakop ng gabay na ito kung paano sila panatilihing ligtas at kung paano suriin.

Public na key kumpara sa secret na key

Hindi lahat ng key ay sikreto. Kapag alam mo ang pagkakaiba, hindi ka mapapraning sa maling key at hindi mo mapapabayaan ang tamang key.

Kung hindi ka sigurado kung anong uri ang isang key, tingnan ang dokumentasyon ng provider. Kapag nagdududa, ituring itong secret.

Hakbang 1: Itago ang mga key bilang secrets, hindi sa code

Dapat nasa environment variables o secrets settings ng host mo ang mga key. Binabasa ito ng code mo ayon sa pangalan habang tumatakbo (halimbawa process.env.OPENAI_API_KEY), kaya hindi lumalabas ang halaga sa mga file mo. Para sa background, tingnan ang ano ang environment variables at secrets.

Ilipat ang bawat API key mula sa code papunta sa environment variables. Ilista ang bawat key na nakita mo, aling file ito nakalagay, at ang pangalan ng variable na ginamit mo. Huwag mong ipakita ang mga halaga.

Pagkatapos, tiyaking walang natira:

Hanapin sa buong project, kasama ang config file at anumang .env file, ang anumang mukhang API key o password. Iulat ang file at linya, hindi ang halaga.

Hakbang 2: Gamitin ang secret na key sa server lang

Ito ang pinakamahalagang tuntunin. Anumang natatanggap ng browser ay mababasa ng bisita: nakikita sa developer tools ang page source at mga JavaScript file.

Kaya kung kailangang tumawag ng app sa OpenAI, dapat tumawag ang browser sa sarili mong server, at ang server mo ang tumatawag sa OpenAI gamit ang key. Hindi kailanman lumalabas ang key sa server.

Direktang tumatawag sa OpenAI mula sa browser ang chat feature. Ilipat ang tawag na iyon sa server API route na nagbabasa ng OPENAI_API_KEY mula sa environment. Ang browser ay dapat tumawag lang sa route natin. Hingin ang login para sa route.

Ingatan ang isang karaniwang bitag sa mga frontend framework: ang mga variable na may public prefix, gaya ng VITE_ sa Vite at NEXT_PUBLIC_ sa Next.js, ay sadyang isinasama sa browser code. Ang secret key na may ganitong prefix ay nalantad, kahit nasa "environment variable" ito.

Hakbang 3: Subukan na walang lumalabas

Huwag basta magtiwala na gumana; suriin ang live na site:

1. Buksan ang na-publish na app sa browser.
2. Buksan ang developer tools, saka ang Sources o Network tab.
3. Hanapin sa lahat ng file ang unang mga character ng bawat secret key (halimbawa sk_ o sk-).
4. Tingnan ang mga network request na ginagawa ng app. Ang request na direktang napupunta mula sa browser papunta sa bayad na AI provider ay palatandaan ng problema.

Kung makakita ka ng secret key, ilipat ito sa server (hakbang 2) at palitan (hakbang 6), dahil nalantad na ito.

Hakbang 4: Higpitan kung ano ang magagawa ng bawat key

Maraming provider ang nagpapahintulot na limitahan ang key:

• Scoped o restricted na key na kayang gawin lang ang kailangan ng app mo. Halimbawa, sinusuportahan ng Stripe ang restricted keys na may tiyak na pahintulot.
• Domain o IP restriction para sa mga key na kailangang publiko, gaya ng maps key.
• Hiwalay na key kada app at kada environment, para hindi malantad ang lahat kapag may isang tumagas, at hindi maapektuhan ang iba kapag binawi ang isa.
• Test key habang nagbubuo, at live key lang sa na-publish na app.

Hakbang 5: Maglagay ng limitasyon sa pinsala

Kahit mahusay ang proteksyon ng key, puwede pa rin itong maabuso sa pamamagitan ng sarili mong app, gaya ng isang taong nagsa-script ng AI feature mo nang libo-libong beses.

• Magtakda ng spending limit o alert sa bawat bayad na provider.
• Hingin ang login para sa anumang feature na nagkakaroon ng gastos kada tawag.
• Magdagdag ng limitasyon kada user kada oras. Tingnan ang ano ang rate limiting.

Magdagdag ng limit na 30 AI request kada user kada oras sa /api/chat. Magpakita ng malinaw na mensahe kapag naabot ang limit. Tanggihan ang mga request mula sa mga user na hindi naka-log in.

Hakbang 6: Palitan ang mga key na tumagas

Kung lumitaw ang secret key sa lugar na hindi dapat, gaya ng chat message, commit, screenshot, support ticket, o browser code, ituring itong nakompromiso.

1. Gumawa ng bagong key sa provider.
2. I-update ang secret sa settings ng app mo.
3. Mag-redeploy o mag-publish ulit para gamitin ng live na app ang bagong key.
4. Burahin ang lumang key sa provider.
5. Tingnan ang usage logs ng provider para sa aktibidad na hindi mo kilala.

Hindi sapat ang pagbura ng chat message o Git commit. Itinatago ng Git history ang mga lumang bersyon, at ang anumang naging publiko ay maaaring nakopya na.

Mga karaniwang pagkakamali

• Pagpapaste ng key sa prompt. Nasa chat history na ito ngayon. Gumamit ng secrets form.
• Public prefix sa secret na variable. Ang VITE_OPENAI_API_KEY ay nagpapadala ng key sa bawat bisita.
• Pag-commit ng .env file. Siguraduhing nasa .gitignore ito bago ang unang push.
• Iisang key para sa lahat. Gumamit ng hiwalay na key para sa test at live, at para sa bawat app.
• Walang spending limit. Ang nalantad o inabusong key na walang takda ay puwedeng makapagpabigat ng malaking bill bago mo pa mapansin.
• Pagtatago sa halip na pagpapalit. Kapag nalantad na ang key, bagong key lang ang makapag-aayos nito.
• Mga key sa screenshot. I-crop o i-blur ang settings page bago ibahagi para humingi ng tulong.

Checklist

• Lahat ng key ay nakaimbak bilang secret o environment variable, hindi sa code.
• Walang .env file o key na naka-commit sa Git.
• Secret key ay ginagamit lang sa server-side code.
• Walang secret variable na gumagamit ng public prefix tulad ng VITE_ o NEXT_PUBLIC_.
• Hinanap ko sa JavaScript ng live na site ang prefix ng bawat key at walang nakita.
• Naka-scope o naka-restrict ang mga key kung pinapayagan ng provider.
• Hiwalay ang test at live na key.
• Ang mga bayad na feature ay humihingi ng login at may limitasyon kada user.
• May spending cap o alert ang bawat bayad na provider.
• Alam ko kung paano palitan ang bawat key, at napalitan na ang anumang key na nalantad kailanman.

Pagpapanatiling ligtas ng mga key sa Mythex

Inilalayo ng Mythex ang mga key sa code at chat sa dalawang paraan:

• Secrets request card. Kapag kailangan ng agent ang key, magpapakita ito ng card sa chat kung saan ilalagay mo ang halaga sa form fields, hindi sa message box, at itatago ito bilang project secret. Tingnan ang Secrets sa chat.
• Project settings → Secrets, o /secrets sa chat, para magdagdag o magpalit ng key nang ikaw mismo. Tingnan ang Environment variables at secrets.

Pagkatapos magpalit ng secret para sa na-publish na app, mag-publish ulit para makuha ito ng live na app. Hindi kasama ang mga secret sa mga na-export na project, kaya idagdag ulit ang mga ito saanman mo patatakbuhin ang code. Kung lumitaw ang key sa chat, palitan ito sa provider.

Para sa natitirang security pass bago mag-launch, sundin ang security checklist para sa AI-built na app. Kung nagdadagdag ka ng AI features, sakop ng paano gumamit ng LLM API ang mga key at gastos nang mas malalim.

Mga tanong