File .env dan API Key: Cara Menyimpan Rahasia Proyek dengan Aman

API key, token akses, kata sandi database, dan kredensial layanan sering dibutuhkan aplikasi agar bisa terhubung ke layanan lain. Masalah muncul ketika nilai rahasia tersebut ditulis langsung di kode atau ikut terunggah ke repositori Git. Jika repositori dapat dilihat orang lain, kredensial itu bisa disalahgunakan untuk mengakses data, memakai kuota API, atau menimbulkan biaya tak terduga.

Salah satu pola yang umum digunakan adalah memisahkan konfigurasi dari kode dengan variabel lingkungan (environment variables). Dalam proyek lokal, file .env sering dipakai untuk menyimpan nilai tersebut. Namun, file ini bukan brankas terenkripsi. Perlindungan tetap bergantung pada cara file disimpan, dibagikan, dan digunakan.

Apa itu file .env dan API key?

File .env berisi pasangan nama dan nilai konfigurasi yang dibaca aplikasi saat berjalan. Contohnya, aplikasi dapat membaca nama host database atau token API dari lingkungan tanpa menuliskan nilainya di source code. API key sendiri adalah kredensial yang mengidentifikasi atau mengizinkan aplikasi mengakses suatu layanan. Perlakukan nilainya seperti kata sandi: jangan dipajang di dokumentasi, tangkapan layar, log, atau percakapan publik.

Format dan cara memuat file .env berbeda menurut bahasa pemrograman dan framework. Pastikan pustaka yang dipakai memang membaca file tersebut; Git dan sistem operasi tidak otomatis memuatnya ke aplikasi.

1. Simpan nilai rahasia di .env lokal

Di direktori proyek, buat file bernama .env dan masukkan nilai yang dibutuhkan. Contoh berikut menggunakan nilai tiruan, bukan kredensial sungguhan:

APP_ENV=development
API_BASE_URL=https://api.example.com
SERVICE_API_KEY=isi_dengan_kunci_lokal
DATABASE_URL=postgres://user:password@localhost:5432/appdb

Jangan menaruh nilai produksi di contoh kode. Hindari pula memasukkan rahasia ke file yang memang akan dibagikan. Jika proyek memerlukan pustaka untuk membaca .env, ikuti dokumentasi resmi framework dan pastikan konfigurasi produksi tidak bergantung pada file lokal milik pengembang.

2. Kecualikan .env dari Git

Tambahkan pola file rahasia ke .gitignore di akar repositori sebelum melakukan commit. Contoh sederhana:

.env
.env.*
!.env.example

Aturan ini mengecualikan file .env beserta variasinya, tetapi tetap mengizinkan template .env.example. Sesuaikan pola jika proyek memang mempunyai file konfigurasi lain yang aman untuk dilacak. Setelah itu, periksa daftar perubahan sebelum commit dan pastikan file rahasia tidak ikut masuk ke staging.

Penting: .gitignore hanya mencegah file yang belum dilacak agar tidak ditambahkan secara normal. Jika file .env sudah pernah di-commit, menambahkan namanya ke .gitignore tidak menghapus salinan dari riwayat Git. Hapus file dari pelacakan sesuai kebutuhan, lalu anggap kredensial yang pernah terunggah sudah terekspos.

3. Sediakan .env.example tanpa rahasia

Tim tetap membutuhkan daftar konfigurasi yang harus disiapkan. Buat file .env.example yang hanya berisi nama variabel dan nilai placeholder, misalnya:

APP_ENV=development
API_BASE_URL=https://api.example.com
SERVICE_API_KEY=
DATABASE_URL=

Template ini boleh dibagikan bersama kode karena tidak memuat nilai sensitif. Sertakan petunjuk di README tentang cara menyalin template menjadi .env dan memperoleh kredensial melalui jalur resmi. Jangan menyalin nilai produksi ke template hanya demi mempermudah penyiapan proyek.

4. Gunakan secret manager saat deployment

Untuk aplikasi yang berjalan di server, platform hosting, atau pipeline CI/CD, gunakan fitur pengelolaan secret yang disediakan platform jika tersedia. Misalnya, GitHub Actions mendukung secret pada tingkat repositori, organisasi, atau environment. Simpan nilai di pengaturan secret, lalu berikan hanya kepada workflow dan tahap yang benar-benar membutuhkannya. Panduan resmi tersedia di dokumentasi GitHub Actions tentang secrets.

Batasi siapa yang dapat membaca atau mengubah secret, pisahkan kredensial pengembangan dan produksi, serta hindari mencetak nilai ke log. Variabel lingkungan praktis, tetapi tidak otomatis aman: proses lain yang punya hak akses, dump diagnostik, atau konfigurasi logging yang buruk dapat membocorkannya. Untuk sistem berisiko tinggi, pertimbangkan layanan pengelola rahasia khusus dan ikuti panduan keamanan dari penyedia hosting.

5. Terapkan akses minimum dan rotasi

Buat API key dengan izin sesempit mungkin. Jika layanan menyediakan pembatasan berdasarkan proyek, alamat IP, endpoint, atau kuota, aktifkan sesuai kebutuhan aplikasi. Jangan memakai satu kunci administrator untuk semua tugas. Pisahkan kunci per aplikasi atau lingkungan agar insiden pada satu tempat tidak langsung membuka seluruh layanan.

Rotasi berarti mengganti kredensial secara terencana, bukan sekadar mengganti nama variabel. Pastikan aplikasi sudah memakai kunci baru sebelum mencabut kunci lama, lalu periksa log penggunaan untuk menemukan aktivitas yang tidak dikenal. Prinsip pengelolaan, pembatasan akses, dan pencabutan rahasia juga dibahas dalam OWASP Secrets Management Cheat Sheet.

Bagaimana jika API key terlanjur bocor?

Jangan hanya menghapus baris yang terlihat. Segera cabut atau nonaktifkan kunci melalui dashboard penyedia, buat kunci pengganti, lalu perbarui konfigurasi di semua lingkungan yang sah. Periksa log pemakaian, tagihan, dan aktivitas akun untuk mencari penyalahgunaan. Jika rahasia pernah masuk ke repositori, batasi akses repositori dan bersihkan riwayat bila diperlukan, tetapi ingat bahwa salinan atau fork mungkin sudah dibuat pihak lain. Penggantian kredensial tetap langkah utama.

Jangan menempelkan kunci asli ke tiket dukungan, pesan, atau alat pemindai daring untuk meminta bantuan. Jika perlu menyelidiki insiden, gunakan versi yang sudah disamarkan dan simpan bukti dengan akses terbatas.

Kesalahan yang perlu dihindari

• Menulis API key langsung di kode, contoh konfigurasi, atau skrip deployment.
• Menganggap repositori privat atau file .env sebagai perlindungan yang sempurna.
• Mencetak seluruh konfigurasi ke log saat debugging.
• Menggunakan kunci yang sama untuk pengembangan, pengujian, dan produksi.
• Mengandalkan .gitignore setelah rahasia telanjur masuk ke riwayat Git.

Checklist singkat sebelum proyek dibagikan

Pastikan .env tidak terlacak oleh Git, .env.example hanya berisi placeholder, dan pemindaian repositori tidak menemukan kredensial. Periksa pula pengaturan secret pada hosting dan pipeline, hak akses setiap kunci, serta prosedur rotasi jika terjadi kebocoran. Pemindaian otomatis dan fitur pencegahan push dapat membantu, tetapi tetap perlu ditambah pemeriksaan manual; lihat panduan GitHub tentang secret scanning.

Kesimpulan

File .env membantu memisahkan konfigurasi dari source code, tetapi bukan tempat penyimpanan rahasia yang kebal bocor. Gabungkan penggunaan variabel lingkungan dengan .gitignore, template tanpa kredensial, secret manager saat deployment, hak akses minimum, dan rotasi yang terencana. Jika kunci pernah terekspos, cabut dan ganti secepatnya. Kebiasaan sederhana ini mengurangi risiko kebocoran API key tanpa membuat alur pengembangan menjadi rumit. Ilustrasi Windows Terminal v1.0 oleh Microsoft; sumber: Wikimedia Commons; lisensi Expat/MIT.