--- title: "Mencegah Bocornya File .env dan API Key" description: "Jalur umum bocornya secret (.env publik, riwayat git, bundle frontend), cara memindai dengan gitleaks, merotasi key, dan memakai secret manager." url: "https://nivelva.com/insight/mencegah-bocor-file-env" category: "Keamanan/Cyber Security" tags: ["file env","api key bocor","gitleaks","secret management","keamanan aplikasi"] author: "Theresia Candiawan" published: "2026-11-07T02:03:00+07:00" updated: "2026-11-07T02:03:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Mencegah Bocornya File .env dan API Key > **Jawaban singkat:** Secret paling sering bocor lewat file .env yang bisa diunduh dari web root, commit lama di riwayat git, dan variabel yang ikut terbundel ke kode frontend. Cegah dengan konfigurasi server, .gitignore, pemindaian gitleaks, dan secret manager. Bila sudah bocor, rotasi key dulu, baru bersihkan. 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: ```nginx location ~ /\.(?!well-known) { deny all; } ``` Di Apache, versi yang setara memakai `` dengan `Require all denied`. Pengaturan Nginx yang lebih lengkap dibahas di [hardening Nginx untuk server produksi](https://nivelva.com/insight/hardening-nginx-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: ```bash # 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](https://nivelva.com/insight/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. | Urutan | Tindakan | Alasan | |:--|:--|:--| | 1 | Cabut atau rotasi secret di penyedianya | Menghapus file tidak membatalkan key yang sudah disalin orang | | 2 | Perbarui konfigurasi aplikasi dengan secret baru | Agar layanan tetap jalan dengan kredensial yang sah | | 3 | Periksa log pemakaian di penyedia layanan | Mengetahui apakah key sudah disalahgunakan dan sejak kapan | | 4 | Tutup jalur bocornya | Blokir file tersembunyi, perbaiki web root, atau pindahkan key ke backend | | 5 | Bersihkan riwayat git bila perlu | Dengan alat seperti git filter-repo, lalu minta semua anggota tim mengkloning ulang | | 6 | Pasang pencegahan | Pre-commit hook, pemindaian CI, dan peninjauan berkala | 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](https://nivelva.com/insight/lapor-kebocoran-data-uu-pdp). ## 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](https://nivelva.com/insight/password-manager-tim-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. ## Sumber - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/mencegah-bocor-file-env Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com