Mencegah Bocornya File .env dan API Key

Tagihan API bulan ini melonjak, padahal aplikasimu sepi. Setelah ditelusuri, ternyata API key layanan AI milikmu dipakai dari server lain sejak beberapa hari lalu. Asalnya sederhana: file .env di folder website bisa dibuka siapa saja lewat browser, dan bot pemindai menemukannya lebih dulu daripada kamu.

Kejadian seperti ini jarang butuh peretas canggih. Bot terus-menerus mencoba alamat seperti /.env, /.git/config, dan /config.php.bak di banyak domain. Begitu ada yang merespons, isinya diambil otomatis. Kabar baiknya, jalur bocor yang paling umum bisa ditutup dengan kebiasaan yang cukup sederhana.

Tiga jalur bocor yang paling sering terjadi

File .env yang ikut tersaji web server. Banyak framework menaruh .env di folder proyek. Masalah muncul ketika folder proyek itu sendiri dijadikan web root, atau saat file diunggah manual ke public_html. Web server lalu menyajikannya seperti file teks biasa. Hal serupa terjadi pada folder .git yang ikut terunggah, yang memungkinkan orang merekonstruksi kode sumber beserta semua secret yang pernah di-commit.

Secret di riwayat git. Kamu sadar telah meng-commit .env, lalu menghapusnya di commit berikutnya. File itu memang hilang dari versi terbaru, tapi masih utuh di riwayat. Siapa pun yang bisa mengkloning repositori bisa membacanya. Risiko ini membesar ketika repositori pernah publik, meski hanya sebentar, atau ketika banyak orang dan sistem CI punya akses baca.

Secret di kode frontend. Semua yang dikirim ke browser bisa dibaca pengguna. Framework frontend biasanya hanya memasukkan variabel ber-awalan tertentu ke bundle, misalnya VITE_ di Vite atau NEXT_PUBLIC_ di Next.js. Kalau secret server diberi awalan itu agar "bisa dipakai di frontend", secret itu ikut terbaca di file JavaScript publik. Aturan praktisnya: API key yang bisa menagih biaya atau mengakses data tidak boleh pernah sampai ke browser. Panggil layanan itu dari backend.

Jalur lain yang juga sering terjadi: secret ditempel di tiket, chat, dokumentasi, atau log aplikasi yang mencetak seluruh konfigurasi saat error.

Menutup pintu di server dan repositori

Langkah pertama adalah memastikan web root hanya berisi file yang memang publik. Untuk framework modern, arahkan web root ke subfolder seperti public/, bukan ke folder proyek. Lalu tambahkan aturan yang menolak akses ke file tersembunyi sebagai lapisan kedua. Di Nginx:

location ~ /\.(?!well-known) {
    deny all;
}

Di Apache, versi yang setara memakai <FilesMatch "^\."> dengan Require all denied. Pengaturan Nginx yang lebih lengkap dibahas di hardening Nginx untuk server produksi. Cek hasilnya dengan membuka https://domainmu.com/.env dan https://domainmu.com/.git/config. Keduanya harus menghasilkan 403 atau 404.

Di repositori, masukkan .env ke .gitignore sejak commit pertama, dan sediakan .env.example berisi nama variabel tanpa nilai asli. Dengan begitu anggota tim tahu variabel apa yang dibutuhkan tanpa ada secret yang ikut tersimpan.

Memindai secret dengan gitleaks

Gitleaks adalah alat open source untuk mendeteksi secret seperti password, API key, dan token di repositori git, folder, atau input dari stdin. Menurut README di repositori resminya, alat ini bisa dipasang lewat Homebrew, Docker, Go, atau binary siap pakai, dan bisa dijalankan sebagai pre-commit hook.

Perintah dasarnya:

# pindai seluruh riwayat git di folder saat ini
gitleaks git -v

# pindai folder atau file tanpa riwayat git
gitleaks dir -v ./

Jalankan pemindaian riwayat sekali untuk setiap repositori lama. Hasilnya sering mengejutkan, terutama di proyek yang sudah berjalan bertahun-tahun. Setelah itu, pasang gitleaks sebagai pre-commit hook agar secret tertahan sebelum masuk commit, dan jalankan juga di pipeline CI sebagai jaring pengaman kedua. Bila kamu meng-host repositori sendiri, misalnya di Gitea, pemindaian bisa dijalankan sebagai langkah di CI pada setiap push. Pilihan alat pengembangan self-hosted dibahas di alat developer self-hosted.

Perlu dicatat, README gitleaks per 4 November 2026 menyebut proyek itu sudah feature complete: rilis berikutnya hanya berisi perbaikan keamanan, dan pengembangnya beralih ke proyek baru bernama Betterleaks. Alatnya tetap bisa dipakai, tapi pantau perkembangannya bila kamu membangun alur kerja jangka panjang.

Apa yang harus dilakukan bila secret sudah bocor?

Urutan yang benar sering terbalik dalam praktik. Banyak orang langsung sibuk menghapus file dari riwayat git, padahal secret yang sudah terlihat harus dianggap sudah diambil orang.

Untuk password database yang bocor, rotasi juga berarti memeriksa apakah ada akun database baru atau data yang berubah. Kalau ada data pribadi pelanggan yang mungkin ikut terakses, ada kewajiban pemberitahuan yang dibahas di kewajiban lapor kebocoran data 3x24 jam.

Beralih ke secret manager

File .env cukup untuk proyek kecil, asal tidak pernah masuk repositori dan tidak tersaji ke publik. Ketika tim dan jumlah layanan bertambah, menyebar file .env lewat chat mulai berbahaya. Secret manager menyimpan secret secara terenkripsi, mencatat siapa mengakses apa, dan memudahkan rotasi.

Pilihannya beragam, dari layanan bawaan penyedia cloud, fitur secret di platform CI, sampai alat open source yang di-host sendiri. Untuk berbagi kredensial antaranggota tim yang bukan secret aplikasi, seperti login panel atau akun vendor, password manager tim lebih tepat, seperti dibahas di password manager untuk tim dengan Vaultwarden.

Apa pun alatnya, terapkan prinsip yang sama: satu secret untuk satu keperluan, hak akses seminimal mungkin, dan jadwal rotasi yang jelas. API key yang hanya boleh membaca data jangan diberi izin menulis.

Ringkasan

Secret paling sering bocor lewat file .env yang tersaji web server, commit lama di riwayat git, dan variabel yang terbundel ke frontend. Tutup ketiganya dengan web root yang benar, aturan blokir file tersembunyi, .gitignore, dan pemindaian gitleaks di pre-commit maupun CI. Bila sudah telanjur bocor, rotasi secret di penyedianya adalah langkah pertama, sebelum urusan membersihkan riwayat.