Cara Menjaga Keamanan API Key di Aplikasi Anda

Untuk menjaga keamanan API key, simpan sebagai secret atau environment variable di host Anda, gunakan hanya di kode sisi server, dan jangan pernah menempelkannya ke chat, file kode, screenshot, atau repositori Git. Berikan setiap key hak akses sekecil mungkin yang dibutuhkan, atur batas pengeluaran di penyedia layanan, dan jika key bocor, ganti key tersebut — buat yang baru lalu hapus yang lama — alih-alih hanya menyembunyikan tempat kemunculannya.

API key adalah kata sandi untuk sebuah layanan. Key OpenAI Anda memungkinkan orang lain menghabiskan uang Anda untuk AI; secret key Stripe Anda memungkinkan orang lain membuat refund; key penyedia email Anda memungkinkan orang lain mengirim surel atas nama Anda. Pembuat aplikasi berbasis AI sangat andal dalam menghubungkan key-key ini, tetapi tidak selalu berhati-hati tentang di mana key tersebut berakhir. Karena itu panduan ini membahas cara menjaga keamanannya dan cara memeriksanya.

Public key vs secret key

Tidak setiap key bersifat rahasia. Dengan memahami perbedaannya, Anda tidak akan panik karena key yang keliru, dan tidak mengabaikan key yang memang penting.

Jika Anda tidak yakin jenis key apa yang Anda miliki, periksa dokumentasi penyedia layanannya. Jika ragu, perlakukan sebagai secret.

Langkah 1: Simpan key sebagai secret, bukan di dalam kode

Key seharusnya berada di pengaturan environment variables atau secrets milik host Anda. Kode Anda membacanya berdasarkan nama saat aplikasi berjalan (misalnya process.env.OPENAI_API_KEY), sehingga nilainya tidak pernah muncul di file Anda. Untuk latar belakangnya, lihat apa itu environment variables dan secrets.

Pindahkan setiap API key dari kode ke environment variables. Daftarkan setiap key yang Anda temukan, di file mana key itu berada, dan nama variabel yang Anda gunakan. Jangan tampilkan nilainya.

Lalu pastikan tidak ada yang tertinggal:

Cari di seluruh proyek, termasuk file konfigurasi dan file .env apa pun, untuk apa pun yang terlihat seperti API key atau kata sandi. Laporkan file dan nomor barisnya, bukan nilainya.

Langkah 2: Gunakan secret key hanya di server

Ini aturan yang paling penting. Apa pun yang diterima browser bisa dibaca oleh pengunjung — source halaman dan file JavaScript semuanya terlihat di developer tools.

Jadi jika aplikasi perlu memanggil OpenAI, browser sebaiknya memanggil server Anda, dan server Anda yang memanggil OpenAI dengan key tersebut. Key tidak pernah meninggalkan server.

Fitur chat saat ini memanggil OpenAI langsung dari browser. Pindahkan pemanggilan itu ke route API di server yang membaca OPENAI_API_KEY dari environment. Browser hanya boleh memanggil route kita. Wajibkan login untuk route tersebut.

Waspadai satu jebakan umum di framework frontend: variabel dengan awalan publik — VITE_ di Vite, NEXT_PUBLIC_ di Next.js — sengaja dimasukkan ke dalam kode browser. Secret key dengan awalan seperti itu akan terekspos, meskipun key tersebut ada “di environment variable”.

Langkah 3: Uji bahwa tidak ada yang bocor

Jangan hanya percaya bahwa semuanya sudah benar — periksa situs yang sudah live:

1. Buka aplikasi yang sudah dipublikasikan di browser.
2. Buka developer tools, lalu tab Sources atau Network.
3. Cari di seluruh file awalan dari setiap secret key (misalnya sk_ atau sk-).
4. Periksa permintaan jaringan yang dibuat aplikasi. Permintaan yang langsung dari browser ke penyedia AI berbayar adalah tanda bahaya.

Jika Anda menemukan secret key, pindahkan ke server (langkah 2) dan ganti (langkah 6), karena key tersebut sudah terlanjur publik.

Langkah 4: Batasi apa yang bisa dilakukan setiap key

Banyak penyedia layanan memungkinkan Anda membatasi key:

• Scoped atau restricted key yang hanya bisa melakukan apa yang dibutuhkan aplikasi Anda. Stripe, misalnya, mendukung restricted key dengan izin tertentu.
• Pembatasan domain atau IP untuk key yang memang harus publik, seperti key peta.
• Key terpisah per aplikasi dan per environment, sehingga satu kebocoran tidak membuka semuanya, dan mencabut satu key tidak merusak yang lain.
• Key uji saat membangun, dan key live hanya di aplikasi yang sudah dipublikasikan.

Langkah 5: Batasi kerusakan yang mungkin terjadi

Bahkan key yang terlindungi dengan baik bisa disalahgunakan lewat aplikasi Anda sendiri — misalnya seseorang yang mengirim ribuan permintaan ke fitur AI Anda lewat skrip.

• Atur batas pengeluaran atau peringatan di setiap penyedia layanan berbayar.
• Wajibkan login untuk setiap fitur yang memakan biaya per panggilan.
• Tambahkan batas permintaan per pengguna. Lihat apa itu rate limiting.

Tambahkan batas 30 permintaan AI per pengguna per jam ke /api/chat. Tampilkan pesan yang jelas saat batas tercapai. Tolak permintaan dari pengguna yang belum login.

Langkah 6: Ganti key yang bocor

Jika secret key muncul di tempat yang seharusnya tidak — pesan chat, commit, screenshot, tiket dukungan, atau kode browser — anggap key tersebut sudah disusupi.

1. Buat key baru di penyedia layanan.
2. Perbarui secret di pengaturan aplikasi Anda.
3. Deploy atau publikasikan ulang agar aplikasi yang live memakai key baru.
4. Hapus key lama di penyedia layanan.
5. Periksa log penggunaan di penyedia layanan untuk aktivitas yang tidak Anda kenali.

Menghapus pesan chat atau commit Git tidak cukup. Riwayat Git menyimpan versi lama, dan apa pun yang bersifat publik mungkin sudah telanjur disalin.

Kesalahan umum

• Menempelkan key ke prompt. Key itu sekarang ada di riwayat chat. Gunakan form secrets sebagai gantinya.
• Awalan publik pada variabel secret. VITE_OPENAI_API_KEY mengirim key ke setiap pengunjung.
• Meng-commit file .env. Pastikan file itu ada di .gitignore sebelum push pertama.
• Satu key untuk semuanya. Gunakan key terpisah untuk uji dan live, serta untuk setiap aplikasi.
• Tanpa batas pengeluaran. Key yang bocor atau disalahgunakan tanpa batas bisa menghabiskan tagihan besar sebelum Anda menyadarinya.
• Menyembunyikan alih-alih mengganti. Begitu key sudah terekspos, hanya key baru yang bisa memperbaikinya.
• Key di screenshot. Potong atau blur halaman pengaturan sebelum membagikannya untuk meminta bantuan.

Daftar periksa

• Setiap key disimpan sebagai secret atau environment variable, bukan di dalam kode.
• Tidak ada file .env atau key yang di-commit ke Git.
• Secret key hanya digunakan di kode sisi server.
• Tidak ada variabel secret yang memakai awalan publik seperti VITE_ atau NEXT_PUBLIC_.
• Saya sudah mencari awalan setiap key di JavaScript situs yang live dan tidak menemukannya.
• Key sudah dibatasi (scoped atau restricted) jika penyedia layanan mengizinkannya.
• Key uji dan key live dipisahkan.
• Fitur berbayar mewajibkan login dan memiliki batas per pengguna.
• Setiap penyedia layanan berbayar memiliki batas pengeluaran atau peringatan.
• Saya tahu cara mengganti setiap key, dan key yang pernah terekspos sudah diganti.

Menjaga keamanan key di Mythex

Mythex menjaga key tetap di luar kode dan chat Anda dengan dua cara:

• Kartu permintaan secrets. Saat agen membutuhkan sebuah key, kartu akan muncul di chat tempat Anda memasukkan nilainya di kolom form, bukan di kotak pesan, dan key tersebut disimpan sebagai secret proyek. Lihat Secrets di chat.
• Project settings → Secrets, atau /secrets di chat, untuk menambah atau mengubah key sendiri. Lihat Environment variables dan secrets.

Setelah mengubah secret untuk aplikasi yang sudah dipublikasikan, publikasikan ulang agar aplikasi yang live menggunakannya. Proyek yang diekspor tidak menyertakan secrets, jadi tambahkan kembali di mana pun Anda menjalankan kodenya berikutnya. Jika sebuah key pernah muncul di chat, ganti key tersebut di penyedia layanan.

Untuk sisa pemeriksaan keamanan sebelum peluncuran, ikuti daftar periksa keamanan untuk aplikasi buatan AI. Jika Anda menambahkan fitur AI, cara menggunakan LLM API membahas key dan biaya secara lebih mendalam.

Pertanyaan