Cara Pastikan Kunci API Selamat dalam Apl Anda

Untuk memastikan kunci API selamat, simpan sebagai rahsia atau pembolehubah persekitaran pada hos anda, guna hanya dalam kod pelayan, dan jangan sekali-kali tampal dalam sembang, fail kod, tangkapan skrin atau repositori Git. Beri setiap kunci kebenaran paling minimum yang diperlukan, tetapkan had perbelanjaan di pembekal, dan jika kunci bocor, tukarkannya — cipta yang baharu dan padam yang lama — dan bukan sekadar menyembunyikan tempat ia muncul.

Kunci API ialah kata laluan untuk sesuatu perkhidmatan. Kunci OpenAI anda membolehkan orang lain membelanjakan wang anda untuk AI; kunci rahsia Stripe anda membolehkan orang lain mengeluarkan bayaran balik; kunci pembekal e-mel anda membolehkan orang menghantar mel sebagai anda. Pembina apl AI pandai menyambungkannya tetapi tidak selalu berhati-hati tentang tempat ia berakhir, jadi panduan ini menerangkan cara memastikannya selamat dan cara menyemaknya.

Kunci awam berbanding kunci rahsia

Tidak semua kunci adalah rahsia. Mengetahui perbezaannya menghalang anda daripada panik tentang kunci yang salah dan mengabaikan yang betul.

Jika anda tidak pasti jenis kunci, semak dokumentasi pembekal. Apabila ragu-ragu, anggap ia rahsia.

Langkah 1: Simpan kunci sebagai rahsia, bukan dalam kod

Kunci patut berada dalam pembolehubah persekitaran atau tetapan rahsia hos anda. Kod anda membacanya mengikut nama semasa runtime (contohnya process.env.OPENAI_API_KEY), jadi nilainya tidak pernah muncul dalam fail anda. Untuk latar belakang, lihat apa itu pembolehubah persekitaran dan rahsia.

Pindahkan setiap kunci API daripada kod ke pembolehubah persekitaran. Senaraikan setiap kunci yang anda jumpai, dalam fail mana ia berada, dan nama pembolehubah yang anda guna. Jangan tunjukkan nilainya.

Kemudian semak tiada yang tertinggal:

Cari seluruh projek, termasuk fail konfigurasi dan mana-mana fail .env, untuk apa-apa yang kelihatan seperti kunci API atau kata laluan. Laporkan fail dan baris, bukan nilainya.

Langkah 2: Guna kunci rahsia hanya di pelayan

Ini peraturan yang paling penting. Apa sahaja yang diterima pelayar, pelawat boleh baca — fail sumber halaman dan JavaScript semuanya kelihatan dalam alat pembangun.

Jadi jika apl perlu memanggil OpenAI, pelayar patut memanggil pelayan anda, dan pelayan anda memanggil OpenAI dengan kunci itu. Kunci tidak pernah keluar daripada pelayan.

Ciri sembang memanggil OpenAI terus dari pelayar. Pindahkan panggilan itu ke laluan API pelayan yang membaca OPENAI_API_KEY daripada persekitaran. Pelayar hanya patut memanggil laluan kami. Wajibkan log masuk untuk laluan itu.

Berhati-hati dengan satu perangkap biasa dalam rangka kerja frontend: pembolehubah dengan awalan awam — VITE_ dalam Vite, NEXT_PUBLIC_ dalam Next.js — sengaja dimasukkan ke dalam kod pelayar. Kunci rahsia dengan awalan sebegini terdedah, walaupun ia "dalam pembolehubah persekitaran".

Langkah 3: Uji bahawa tiada yang bocor

Jangan percaya ia berfungsi — semak laman langsung:

1. Buka apl yang diterbitkan dalam pelayar.
2. Buka alat pembangun, kemudian tab Sources atau Network.
3. Cari merentasi fail untuk beberapa aksara pertama setiap kunci rahsia (contohnya sk_ atau sk-).
4. Semak permintaan rangkaian yang dibuat oleh apl. Permintaan yang terus dari pelayar ke pembekal AI berbayar ialah tanda bahaya.

Jika anda menjumpai kunci rahsia, pindahkannya ke pelayan (langkah 2) dan tukarkannya (langkah 6), kerana ia sudah terdedah.

Langkah 4: Hadkan apa yang setiap kunci boleh lakukan

Banyak pembekal membenarkan anda mengehadkan kunci:

• Kunci berskop atau terhad yang hanya boleh melakukan apa yang apl anda perlukan. Stripe, contohnya, menyokong kunci terhad dengan kebenaran tertentu.
• Sekatan domain atau IP bagi kunci yang mesti awam, seperti kunci peta.
• Kunci berasingan bagi setiap apl dan persekitaran, supaya satu kebocoran tidak mendedahkan semua, dan pembatalan satu tidak merosakkan yang lain.
• Kunci ujian semasa membina, dan kunci sebenar hanya dalam apl yang diterbitkan.

Langkah 5: Letakkan had pada kerosakan

Walaupun kunci yang dilindungi dengan baik boleh disalah guna melalui apl anda sendiri — contohnya, seseorang membuat skrip ciri AI anda beribu kali.

• Tetapkan had atau amaran perbelanjaan pada setiap pembekal berbayar.
• Wajibkan log masuk bagi sebarang ciri yang menelan kos setiap panggilan.
• Tambah had kadar setiap pengguna. Lihat apa itu had kadar.

Tambah had 30 permintaan AI setiap pengguna sejam ke /api/chat. Pulangkan mesej yang jelas apabila had dicapai. Tolak permintaan daripada pengguna yang tidak log masuk.

Langkah 6: Tukar kunci yang bocor

Jika kunci rahsia muncul di tempat yang tidak sepatutnya — mesej sembang, commit, tangkapan skrin, tiket sokongan, kod pelayar — anggap ia telah dikompromi.

1. Cipta kunci baharu di pembekal.
2. Kemas kini rahsia dalam tetapan apl anda.
3. Terbitkan semula atau deploy semula supaya apl langsung menggunakan kunci baharu.
4. Padam kunci lama di pembekal.
5. Semak log penggunaan pembekal untuk aktiviti yang tidak anda kenali.

Memadam mesej sembang atau commit Git tidak mencukupi. Sejarah Git menyimpan versi lama, dan apa-apa yang awam mungkin sudah disalin.

Kesilapan biasa

• Menampal kunci dalam prompt. Ia kini berada dalam sejarah sembang. Gunakan borang rahsia sebagai ganti.
• Awalan awam pada pembolehubah rahsia. VITE_OPENAI_API_KEY menghantar kunci kepada setiap pelawat.
• Commit fail .env. Pastikan ia berada dalam .gitignore sebelum push pertama.
• Satu kunci untuk semua. Gunakan kunci berasingan untuk ujian dan sebenar, dan untuk setiap apl.
• Tiada had perbelanjaan. Kunci yang bocor atau disalah guna tanpa had boleh menaikkan bil besar sebelum anda perasan.
• Menyembunyikan dan bukan menukar. Setelah kunci terdedah, hanya kunci baharu yang membetulkannya.
• Kunci dalam tangkapan skrin. Potong atau kaburkan halaman tetapan sebelum berkongsinya untuk bantuan.

Senarai semak

• Setiap kunci disimpan sebagai rahsia atau pembolehubah persekitaran, bukan dalam kod.
• Tiada fail .env atau kunci di-commit ke Git.
• Kunci rahsia hanya digunakan dalam kod pelayan.
• Tiada pembolehubah rahsia menggunakan awalan awam seperti VITE_ atau NEXT_PUBLIC_.
• Saya cari JavaScript laman langsung untuk awalan setiap kunci dan tidak menjumpai apa-apa.
• Kunci diskop atau dihadkan di mana pembekal membenarkan.
• Kunci ujian dan sebenar adalah berasingan.
• Ciri berbayar memerlukan log masuk dan mempunyai had setiap pengguna.
• Setiap pembekal berbayar mempunyai had atau amaran perbelanjaan.
• Saya tahu cara menukar setiap kunci, dan mana-mana kunci yang pernah terdedah telah ditukar.

Memastikan kunci selamat di Mythex

Mythex menyimpan kunci di luar kod dan sembang anda dengan dua cara:

• Kad permintaan rahsia. Apabila ejen memerlukan kunci, ia memaparkan kad dalam sembang di mana anda memasukkan nilai dalam medan borang, bukan dalam kotak mesej, dan ia disimpan sebagai rahsia projek. Lihat Rahsia dalam sembang.
• Tetapan projek → Secrets, atau /secrets dalam sembang, untuk menambah atau menukar kunci sendiri. Lihat Pembolehubah persekitaran dan rahsia.

Selepas menukar rahsia untuk apl yang diterbitkan, terbitkan semula supaya apl langsung mengambilnya. Projek yang dieksport tidak menyertakan rahsia, jadi tambahkannya semula di mana sahaja anda menjalankan kod seterusnya. Jika kunci muncul dalam sembang, tukarkannya di pembekal.

Untuk baki pemeriksaan keselamatan sebelum pelancaran, ikuti senarai semak keselamatan untuk apl dibina AI. Jika anda menambah ciri AI, cara guna LLM API meliputi kunci dan kos dengan lebih mendalam.

Soalan lazim