File .env Bukan Brankas: Cara Menyimpan Secret…

Banyak proyek aplikasi dimulai dengan satu kebiasaan sederhana: membuat file .env, memasukkan API key di dalamnya, lalu menambahkan pembacaan variabel lingkungan ke aplikasi. Cara ini nyaman karena konfigurasi bisa dipisahkan dari kode. Masalahnya, file tersebut sering diperlakukan seperti brankas, padahal sebenarnya hanya file teks biasa.

Jika seseorang bisa membaca file .env, ia mungkin bisa melihat kredensial database, token layanan email, kunci API pembayaran, atau akses ke layanan cloud. OWASP mengelompokkan semua itu sebagai secret, termasuk password, connection string, private key, dan session token. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html?utm_source=openai))

Jadi, pertanyaannya bukan apakah proyek Anda cukup kecil untuk mengabaikan pengelolaan secret. Pertanyaannya adalah: bagaimana membuat secret tetap praktis dipakai, tetapi tidak mudah bocor?

Mengapa file .env sering disalahpahami?

File .env biasanya dipakai untuk menyimpan konfigurasi yang berbeda antara komputer developer, server pengujian, dan produksi. Contohnya:

DATABASE_URL=postgres://user:password@localhost:5432/app
PAYMENT_API_KEY=sk_live_contoh
SMTP_PASSWORD=rahasia

Pola ini berguna karena aplikasi tidak perlu menulis password langsung di source code. Namun, .env tetap memiliki beberapa kelemahan:

Isinya biasanya tidak terenkripsi.
File dapat tersalin ke backup, folder sinkronisasi, atau laptop lain.
Developer bisa tidak sengaja menjalankan git add . dan memasukkannya ke repository.
Nilainya dapat muncul di log, pesan error, screenshot, atau output debugging.
Semua orang yang memiliki akses ke mesin tersebut bisa membacanya.

Dengan kata lain, .env membantu memisahkan secret dari kode, tetapi tidak otomatis melindungi secret dari pembacaan atau kebocoran.

Aturan pertama: jangan pernah commit secret ke repository

Langkah paling dasar adalah memasukkan file lokal ke .gitignore:

.env
.env.*
!.env.example

File .env.example boleh disimpan di repository, tetapi hanya berisi nama variabel tanpa nilai rahasia:

DATABASE_URL=
PAYMENT_API_KEY=
SMTP_PASSWORD=

Tujuannya agar anggota tim mengetahui konfigurasi apa saja yang dibutuhkan tanpa melihat kredensial sebenarnya. Dokumentasi proyek juga sebaiknya menjelaskan dari mana setiap nilai diperoleh dan lingkungan mana yang menggunakannya.

Namun, .gitignore bukan mesin waktu. Jika secret pernah masuk ke commit sebelumnya, menghapus file dari commit terbaru belum cukup. Nilai tersebut mungkin masih ada di riwayat Git, fork, clone lokal, atau cache layanan repository.

Jika secret terlanjur bocor, jangan hanya menghapusnya

Kesalahan umum adalah menghapus baris secret dari kode lalu menganggap masalah selesai. Perlakuan yang benar adalah menganggap secret sudah diketahui orang lain.

Cabut atau nonaktifkan secret lama. Revoke API key, reset password, atau hapus token yang terpapar.
Buat secret pengganti. Jangan menggunakan kembali nilai yang sama di server lain.
Periksa aktivitasnya. Lihat log penggunaan, request tidak biasa, pembuatan resource baru, atau perubahan konfigurasi.
Bersihkan repository bila perlu. Untuk kasus tertentu, riwayat Git perlu ditulis ulang, tetapi langkah ini harus dikoordinasikan karena dapat mengganggu clone dan branch anggota tim.
Catat penyebabnya. Apakah secret bocor lewat commit, log CI/CD, screenshot, atau pesan chat?

OWASP menyarankan agar secret dapat dicabut, diputar secara berkala, hanya terlihat oleh pihak yang memerlukan, dan tidak pernah ditulis ke log dalam bentuk plaintext. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html?utm_source=openai))

Gunakan tingkat perlindungan sesuai skala proyek

Tidak semua proyek membutuhkan sistem pengelolaan secret yang rumit. Yang penting adalah membedakan kebutuhan lokal, CI/CD, dan produksi.

Untuk proyek pribadi atau prototipe

Gunakan .env lokal, pastikan masuk .gitignore, dan hindari menyimpan file tersebut di folder yang otomatis tersinkronisasi tanpa perlindungan tambahan. Jangan mengirimnya lewat chat atau menaruhnya di dokumen bersama.

Tambahkan pemeriksaan sederhana sebelum commit. Beberapa editor dan alat keamanan dapat mendeteksi pola seperti API key, private key, atau token. Jika menggunakan GitHub, fitur push protection dapat memblokir sejumlah secret sebelum masuk ke repository dan membuat peringatan ketika perlindungan tersebut dilewati. ([docs.github.com](https://docs.github.com/en/enterprise-cloud%40latest/code-security/secret-scanning/enabling-secret-scanning-features/enabling-push-protection-for-your-repository?utm_source=openai))

Untuk tim kecil

Simpan secret pada pengaturan secret di platform CI/CD atau layanan hosting, bukan di file konfigurasi yang dikirim bersama source code. Batasi siapa yang dapat melihat dan mengubahnya. Pisahkan nilai untuk development, staging, dan production agar satu kebocoran tidak membuka semua lingkungan.

Perhatikan juga output pipeline. Perintah debugging yang mencetak semua variabel lingkungan dapat membocorkan secret meskipun repository Anda privat. Repository privat bukan berarti semua anggota tim atau semua proses otomatis boleh mengakses seluruh kredensial.

Untuk aplikasi produksi

Pertimbangkan layanan pengelolaan secret khusus, seperti secret manager dari penyedia cloud atau platform yang digunakan organisasi. Nilai tambahnya bukan sekadar penyimpanan, melainkan pengaturan akses, audit, rotasi, dan integrasi dengan deployment.

Prinsipnya adalah least privilege: aplikasi hanya mendapatkan secret yang benar-benar dibutuhkan. Service yang hanya mengirim email tidak perlu memiliki kredensial untuk menghapus database. OWASP juga menganjurkan agar organisasi memiliki proses penyimpanan, distribusi, audit, dan rotasi secret yang jelas. ([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html?utm_source=openai))

Bedakan konfigurasi biasa dan secret

Tidak semua isi konfigurasi harus diperlakukan sebagai rahasia. Nama aplikasi, port lokal, mode tampilan, atau alamat layanan publik biasanya bukan secret. Sebaliknya, password, token akses, private key, dan connection string dengan kredensial harus diperlakukan sebagai data sensitif.

Jika sebuah nilai dapat dipakai untuk masuk, mengubah data, menghabiskan saldo, atau mengambil alih layanan, perlakukan nilai itu sebagai secret.

Pemisahan ini membantu tim menghindari dua ekstrem: menganggap semua hal harus dirahasiakan secara berlebihan, atau menganggap tidak ada yang perlu dilindungi.

Checklist yang bisa dilakukan sekarang

Pastikan .env dan variasinya masuk ke .gitignore.
Buat .env.example tanpa nilai rahasia.
Cari repository lama dengan pola API key, password, token, dan private key.
Aktifkan secret scanning atau push protection jika tersedia.
Pastikan log aplikasi dan CI/CD tidak mencetak variabel lingkungan.
Pisahkan secret untuk development, staging, dan production.
Cabut secret yang pernah terlanjur masuk repository.
Tentukan siapa yang boleh melihat, mengubah, dan merotasi setiap secret.

Intinya

.env bukan pilihan yang buruk. Untuk pengembangan lokal, file ini masih sangat berguna. Yang keliru adalah menganggapnya sebagai brankas, padahal ia hanya mekanisme konfigurasi.

Mulailah dari kebiasaan sederhana: jangan commit secret, jangan mencetaknya ke log, gunakan nilai berbeda untuk setiap lingkungan, dan cabut kredensial yang pernah bocor. Ketika aplikasi dan tim membesar, pindahkan pengelolaannya ke sistem yang menyediakan kontrol akses, audit, dan rotasi. Dengan begitu, keamanan tidak bergantung pada ingatan satu developer atau satu baris .gitignore.

Sumber & bacaan lebih lanjut

– Rio Yotto @rioyotto