Mengamankan API Key & .env di GitHub: Gitignore, Scanning, Rotasi

Foto: blprnt_van — CC BY 2.0

Ringkasan Cepat

• Jangan pernah commit file .env; gunakan .gitignore, .env.example, dan environment variables platform.
• Aktifkan secret scanning dan push protection agar GitHub mendeteksi serta memblokir kunci rahasia.
• Jika kunci bocor, rotasi segera, audit akses, lalu bersihkan riwayat Git dengan alat seperti git filter-repo.

API key yang bocor di repositori GitHub dapat disalahgunakan untuk mengakses layanan, menghabiskan kuota, atau mencuri data. Artikel ini memandu langkah praktis mengamankan file .env dan kunci rahasia melalui .gitignore, secret scanning, hingga rotasi kunci yang benar.

Mengapa API Key dan File .env Rawan Bocor

File .env biasanya menyimpan variabel lingkungan seperti kunci API, token bot, kredensial database, dan secret key. Karena letaknya di folder proyek, file ini sangat mudah ikut ter-commit saat menjalankan git add . atau membuat repositori publik. Banyak pengembang juga menyalin nilai asli ke file contoh, menaruh kunci langsung di kode, atau mengunggah arsip proyek tanpa memeriksa isi folder.

Kebocoran tidak selalu terjadi lewat commit yang disengaja. Gist, fork, log CI/CD, dan cache build bisa menjadi jalur alternatif. Sebuah kunci yang terekspos dapat dipakai penyerang untuk memanggil API atas nama pemilik proyek, membaca data, atau menghapus resource. Prinsip yang perlu dipegang: perlakukan .env seperti password. Jangan pernah mengandalkan kerahasiaan repositori, karena repo privat bisa berubah menjadi publik atau diakses pihak yang tidak berwenang.

Kasus kunci JWT hard-coded pada proyek seperti yang dibahas di CVE-2026-108860: Kunci JWT Hard-coded di BotSharp Buka Autentikasi menunjukkan bahwa kunci yang tertanam di kode bisa membuka celah autentikasi. Pola serupa juga sering ditemukan pada proyek kecil yang belum menerapkan manajemen rahasia.

Langkah 1: Amankan .env dengan .gitignore dan Environment Variables

Langkah pertama adalah memastikan file .env tidak pernah masuk ke Git. Buat file .gitignore di root proyek dan tambahkan pola berikut:

• .env — mengabaikan file utama.
• .env.* — mengabaikan variasi seperti .env.local atau .env.production.
• !.env.example — mengecualikan file contoh agar tetap bisa di-commit.
• *.pem, *.key, dan secrets/ — melindungi file kunci lain.

Sediakan .env.example yang hanya berisi nama variabel tanpa nilai sensitif, misalnya API_KEY=. Dengan begitu, anggota tim tahu variabel apa yang dibutuhkan tanpa membocorkan rahasia. Di platform deployment seperti Vercel, Railway, Heroku, atau AWS, gunakan menu environment variables untuk menyimpan nilai asli. Untuk proyek tim, pertimbangkan secret manager seperti HashiCorp Vault, AWS Secrets Manager, atau layanan bawaan platform. Pembahasan soal keamanan kolaborasi tim juga tersedia di Panduan Keamanan Notion, Trello, dan Asana untuk Tim Remote.

Jika file .env sudah telanjur dilacak Git, menambahkannya ke .gitignore saja tidak cukup. Jalankan git rm --cached .env untuk menghentikan pelacakan, lalu commit perubahan. Ingat, perintah ini tidak menghapus file dari riwayat commit sebelumnya. Selalu periksa git status sebelum melakukan commit untuk memastikan tidak ada file rahasia yang ikut terbawa.

Langkah 2: Aktifkan Secret Scanning dan Push Protection

GitHub menyediakan fitur secret scanning yang memindai repositori untuk mendeteksi pola rahasia yang dikenal, seperti token akses, kunci API, dan kredensial layanan cloud. Fitur ini dapat diaktifkan melalui menu Settings > Code security and analysis. Untuk organisasi, aktifkan di tingkat organisasi agar semua repositori terlindungi secara konsisten.

Push protection melangkah lebih jauh: ia memblokir push yang mengandung rahasia sebelum kode masuk ke repositori. Jika tim menggunakan format kunci internal, buat custom pattern agar deteksi lebih akurat. Berikut perbandingan singkat mekanisme yang tersedia:

Mekanisme	Fungsi	Kapan Aktif
Secret scanning	Memindai riwayat dan commit baru untuk pola rahasia	Otomatis dan berkala
Push protection	Memblokir push yang berisi rahasia terdeteksi	Saat proses push
Custom pattern	Mendeteksi format kunci khusus organisasi	Setelah dikonfigurasi
Alert	Memberi notifikasi kepada admin atau pengembang	Saat rahasia terdeteksi

Jangan abaikan alert yang muncul. Tindak lanjuti dengan mencabut kunci, memeriksa log akses, dan melakukan rotasi. Jika push protection memblokir, jangan memaksa push dengan mengabaikan peringatan. Hapus rahasia dari commit, perbaiki konfigurasi, lalu push ulang.

Langkah 3: Rotasi Kunci dan Bersihkan Riwayat Git

Rotasi kunci berarti mengganti kunci lama dengan kunci baru, bukan sekadar menghapus file dari commit terakhir. Urutan yang benar adalah rotasi terlebih dahulu, baru bersihkan riwayat. Berikut langkah yang bisa diikuti:

1. Cabut kunci lama di dashboard penyedia layanan agar tidak bisa dipakai lagi.
2. Buat kunci baru dengan hak akses minimum sesuai kebutuhan aplikasi.
3. Perbarui environment variables di server, CI/CD, dan lingkungan lokal.
4. Audit log akses untuk melihat apakah ada aktivitas mencurigakan sebelum kunci dicabut.
5. Bersihkan riwayat Git menggunakan git filter-repo atau BFG Repo-Cleaner.
6. Force push dan minta seluruh kolaborator melakukan clone ulang agar tidak mengembalikan commit lama.

Setelah riwayat bersih, aktifkan kembali push protection dan secret scanning. Perlu dicatat, menghapus kunci dari riwayat tidak otomatis membuat kunci tersebut tidak valid. Itulah alasan rotasi harus dilakukan lebih dulu. Jika kunci terlanjur dipakai pihak lain, mencabutnya akan menghentikan akses tersebut.

Kebiasaan Tim dan Otomatisasi agar Tidak Terulang

Keamanan rahasia bukan pekerjaan sekali selesai. Terapkan kebiasaan berikut di tim:

• Gunakan pre-commit hook atau alat pemindai rahasia sebelum commit.
• Terapkan prinsip least privilege pada setiap kunci API.
• Pisahkan kunci untuk development, staging, dan production.
• Wajibkan review pull request, terutama yang menyentuh konfigurasi.
• Dokumentasikan prosedur rotasi dan tanggung jawabnya.
• Jadwalkan audit akses dan rotasi berkala.

Otomatisasi membantu mengurangi kesalahan manusia. Misalnya, pipeline CI/CD dapat menolak build jika mendeteksi file .env atau pola kunci. Beberapa alat populer seperti gitleaks dan trufflehog dapat dijalankan di lokal maupun di pipeline. Yang terpenting, jangan menaruh rahasia di kode, log, atau tiket. Jika rahasia harus dibagikan ke anggota tim, gunakan secret manager dengan akses berbasis peran, bukan chat atau email.

Dengan kombinasi .gitignore yang benar, secret scanning, dan rotasi kunci, risiko kebocoran API key dapat ditekan secara signifikan. Mulailah dari langkah kecil: periksa repositori hari ini, pastikan tidak ada .env yang terlacak, dan aktifkan push protection.

Pertanyaan yang Sering Diajukan (FAQ)

Apakah cukup menghapus file .env dari commit terakhir?

Tidak. Kunci masih tersimpan di riwayat Git dan dapat ditemukan melalui commit sebelumnya. Segera rotasi kunci, cabut yang lama, lalu bersihkan riwayat dengan git filter-repo atau BFG.

Apa itu push protection di GitHub?

Push protection adalah fitur yang memblokir push jika mendeteksi rahasia seperti API key atau token. Fitur ini mencegah kunci masuk ke repositori sejak awal.

Bagaimana jika repositori sudah publik dan kunci terlanjur bocor?

Anggap kunci sudah bocor. Cabut kunci lama, buat kunci baru, audit log akses, bersihkan riwayat Git, dan aktifkan secret scanning serta push protection.

Apakah .gitignore bisa mengabaikan file yang sudah dilacak Git?

Tidak. .gitignore hanya berlaku untuk file yang belum dilacak. Gunakan git rm --cached .env untuk menghentikan pelacakan, lalu commit.

Seberapa sering kunci API perlu dirotasi?

Sesuaikan dengan kebijakan keamanan dan risiko. Minimal rotasi dilakukan saat kunci bocor, saat anggota tim keluar, atau secara berkala untuk kunci produksi.

English Version — Securing API Keys & .env on GitHub: Gitignore, Scanning, Rotation

Quick Summary

• Never commit .env files; use .gitignore, .env.example, and platform environment variables.
• Enable secret scanning and push protection so GitHub detects and blocks secret keys.
• If a key leaks, rotate immediately, audit access, then clean Git history with tools like git filter-repo.

A leaked API key in a GitHub repository can be abused to access services, consume quotas, or steal data. This article guides you through practical steps to secure .env files and secret keys using .gitignore, secret scanning, and proper key rotation.

Why API Keys and .env Files Are Prone to Leaks

The .env file typically stores environment variables such as API keys, bot tokens, database credentials, and secret keys. Because it sits in the project folder, this file can very easily be committed when running git add . or creating a public repository. Many developers also copy real values into example files, place keys directly in code, or upload project archives without checking the folder contents.

Leaks do not always happen through intentional commits. Gists, forks, CI/CD logs, and build caches can be alternative paths. An exposed key can be used by an attacker to call APIs on behalf of the project owner, read data, or delete resources. The principle to hold onto: treat .env like a password. Never rely on repository confidentiality, because a private repo can become public or be accessed by unauthorized parties.

The case of hard-coded JWT keys in projects, as discussed in CVE-2026-108860: Hard-coded JWT Key in BotSharp Opens Authentication, shows that keys embedded in code can open an authentication gap. Similar patterns are also often found in small projects that have not implemented secret management.

Step 1: Secure .env with .gitignore and Environment Variables

The first step is to ensure the .env file never enters Git. Create a .gitignore file in the project root and add the following patterns:

• .env — ignores the main file.
• .env.* — ignores variations such as .env.local or .env.production.
• !.env.example — excludes the example file so it can still be committed.
• *.pem, *.key, and secrets/ — protect other key files.

Provide a .env.example containing only variable names without sensitive values, for example API_KEY=. That way, team members know which variables are needed without leaking secrets. On deployment platforms such as Vercel, Railway, Heroku, or AWS, use the environment variables menu to store the real values. For team projects, consider secret managers such as HashiCorp Vault, AWS Secrets Manager, or built-in platform services. A discussion of team collaboration security is also available in Notion, Trello, and Asana Security Guide for Remote Teams.

If the .env file has already been tracked by Git, adding it to .gitignore alone is not enough. Run git rm --cached .env to stop tracking it, then commit the change. Remember, this command does not remove the file from previous commit history. Always check git status before committing to make sure no secret files are included.

Step 2: Enable Secret Scanning and Push Protection

GitHub provides secret scanning, which scans repositories to detect known secret patterns such as access tokens, API keys, and cloud service credentials. This feature can be enabled through Settings > Code security and analysis. For organizations, enable it at the organization level so all repositories are consistently protected.

Push protection goes further: it blocks pushes containing secrets before the code enters the repository. If your team uses internal key formats, create custom patterns for more accurate detection. Here is a brief comparison of the available mechanisms:

Mechanism	Function	When Active
Secret scanning	Scans history and new commits for secret patterns	Automatically and periodically
Push protection	Blocks pushes containing detected secrets	During the push process
Custom pattern	Detects organization-specific key formats	After configuration
Alert	Notifies admins or developers	When a secret is detected

Do not ignore alerts that appear. Follow up by revoking the key, checking access logs, and performing rotation. If push protection blocks, do not force push by ignoring the warning. Remove the secret from the commit, fix the configuration, and push again.

Step 3: Rotate Keys and Clean Git History

Key rotation means replacing the old key with a new one, not just deleting the file from the last commit. The correct order is rotation first, then clean history. Here are the steps to follow:

1. Revoke the old key in the service provider dashboard so it can no longer be used.
2. Create a new key with minimum permissions based on the application's needs.
3. Update environment variables on servers, CI/CD, and local environments.
4. Audit access logs to see whether there was suspicious activity before the key was revoked.
5. Clean Git history using git filter-repo or BFG Repo-Cleaner.
6. Force push and ask all collaborators to re-clone so old commits are not restored.

After the history is clean, re-enable push protection and secret scanning. Note that removing a key from history does not automatically make the key invalid. That is why rotation must be done first. If the key has already been used by another party, revoking it will stop that access.

Team Habits and Automation to Prevent Recurrence

Secret security is not a one-time task. Implement the following habits in your team:

• Use pre-commit hooks or secret scanning tools before committing.
• Apply the principle of least privilege to every API key.
• Separate keys for development, staging, and production.
• Require pull request reviews, especially those touching configuration.
• Document rotation procedures and responsibilities.
• Schedule access audits and periodic rotation.

Automation helps reduce human error. For example, a CI/CD pipeline can reject a build if it detects a .env file or key pattern. Several popular tools such as gitleaks and trufflehog can be run locally or in a pipeline. Most importantly, do not put secrets in code, logs, or tickets. If secrets must be shared with team members, use a secret manager with role-based access, not chat or email.

With the right combination of .gitignore, secret scanning, and key rotation, the risk of API key leaks can be significantly reduced. Start with small steps: check your repository today, make sure no .env is tracked, and enable push protection.

FAQ (English)

Is it enough to delete the .env file from the last commit?

No. The key is still stored in Git history and can be found through previous commits. Immediately rotate the key, revoke the old one, then clean history with git filter-repo or BFG.

What is push protection on GitHub?

Push protection is a feature that blocks pushes if it detects secrets such as API keys or tokens. This feature prevents keys from entering the repository in the first place.

What if the repository is already public and the key has already leaked?

Assume the key has leaked. Revoke the old key, create a new key, audit access logs, clean Git history, and enable secret scanning and push protection.

Can .gitignore ignore files already tracked by Git?

No. .gitignore only applies to files that are not yet tracked. Use git rm --cached .env to stop tracking, then commit.

How often should API keys be rotated?

Adjust according to your security policy and risk. At minimum, rotate when a key leaks, when a team member leaves, or periodically for production keys.