Permintaan ke /.git/config sering menjadi indikator bahwa crawler atau scanner sedang mencari metadata repositori Git yang tidak sengaja tersedia melalui web server. Jika berhasil diakses, file tersebut dapat mengungkap URL remote, nama branch, struktur konfigurasi, dan informasi lain yang membantu pemetaan aplikasi. File ini biasanya tidak berisi secret secara langsung, tetapi kebocorannya dapat membuka jalan menuju histori Git atau file internal lain.

Pencegahan yang tepat terdiri dari beberapa lapisan: jangan menempatkan direktori .git di web root, blokir akses melalui web server, deploy hanya artefak aplikasi yang diperlukan, pantau pola scanning pada access log, dan siapkan prosedur respons apabila file pernah terekspos. Pembahasan ini sejalan dengan konteks tulisan tentang crawler Git config di Git Config Spider. Contoh pemeriksaan di bawah hanya boleh dilakukan terhadap server dan domain yang Anda miliki atau berwenang untuk uji.

Mengapa .git Tidak Boleh Berada di Web Root

Direktori .git menyimpan metadata internal repositori, seperti konfigurasi repository, referensi branch, object database, dan histori perubahan. Pada instalasi Git tertentu, file .git/config dapat memuat URL remote atau konfigurasi tambahan. File lain di dalam direktori tersebut dapat membantu seseorang merekonstruksi isi repository jika seluruh object Git dapat diambil.

Masalah utamanya bukan hanya isi .git/config. Jika web server menyajikan direktori ini sebagai file statis, penyerang dapat mencoba:

  • membaca konfigurasi remote dan nama repository;
  • menemukan referensi branch atau struktur object Git;
  • mengakses file konfigurasi, source code, atau secret yang pernah masuk ke histori;
  • menggunakan informasi tersebut untuk menyusun serangan lanjutan pada aplikasi.

Keberadaan file .env, backup database, arsip deployment, dan file konfigurasi lain di web root juga perlu diperlakukan sebagai risiko terpisah. Memblokir .git tidak otomatis melindungi file sensitif lainnya.

Memeriksa Paparan Secara Aman

Lakukan verifikasi dari lingkungan yang Anda kontrol, misalnya domain staging atau production milik organisasi. Jangan mengirimkan permintaan pengujian ke target pihak lain tanpa izin.

Mulai dengan memeriksa status HTTP dan isi respons secara terbatas:

curl --silent --show-error --location \
  --max-time 10 \
  -D /tmp/git-config.headers \
  -o /tmp/git-config.body \
  https://contoh.example/.git/config

sed -n '1,20p' /tmp/git-config.headers
wc -c /tmp/git-config.body

Respons yang aman biasanya berupa 404 Not Found atau 403 Forbidden, sesuai kebijakan server. Kode status saja tidak cukup: periksa juga ukuran dan isi respons, karena aplikasi dapat mengembalikan halaman error dengan status 200. Jangan mengunduh seluruh repository atau melakukan pemindaian agresif. Untuk pemeriksaan internal, validasi pula bahwa direktori deployment memang tidak berisi metadata Git:

find /var/www/app -type d -name .git -print
find /var/www/app -type f \( -name '.env*' -o -name '*.bak' -o -name '*.sql' \) -print

Jalankan pemeriksaan tersebut pada direktori yang benar-benar digunakan web server, bukan hanya pada checkout source code di workstation atau CI runner.

Hardening Web Server untuk Memblokir .git

Nginx

Tambahkan aturan pada blok server yang menangani situs tersebut. Pola ini memblokir .git di root maupun subdirektori dan mengembalikan 404, sehingga keberadaan path internal tidak terlalu mudah dibedakan dari resource yang memang tidak ada.

server {
    server_name contoh.example;
    root /var/www/app/public;

    location ~* /\.git(?:/|$) {
        return 404;
    }

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Sesuaikan blok location / dengan aplikasi Anda. Setelah perubahan, validasi sintaks dan muat ulang konfigurasi:

sudo nginx -t
sudo systemctl reload nginx

Aturan di web server adalah lapisan pertahanan tambahan, bukan pengganti deployment yang benar. Pastikan konfigurasi efektif pada virtual host yang benar, terutama jika terdapat reverse proxy, CDN, atau beberapa server frontend.

Apache HTTP Server

Pada konfigurasi virtual host atau konfigurasi server, gunakan aturan direktori untuk menolak akses ke direktori bernama .git:

<DirectoryMatch "(^|/)\.git(/|$)">
    Require all denied
</DirectoryMatch>

Jika konfigurasi server tidak dapat diubah dan hosting mengizinkan .htaccess, gunakan aturan berbasis file sebagai lapisan tambahan:

<FilesMatch "^\.git">
    Require all denied
</FilesMatch>

Efektivitas .htaccess bergantung pada AllowOverride dan konfigurasi host. Karena itu, aturan pada virtual host atau konfigurasi global lebih mudah diaudit dan biasanya lebih konsisten. Setelah perubahan, lakukan reload sesuai prosedur platform Anda dan uji endpoint dari sisi klien.

Pencegahan melalui Build dan Deployment

Solusi paling kuat adalah tidak menyalin checkout Git ke direktori yang dilayani web server. Pisahkan lokasi source dan web root:

  • checkout repository berada di workspace CI/CD atau direktori di luar web root;
  • proses build menghasilkan artefak runtime yang diperlukan saja;
  • web server diarahkan ke direktori publik, misalnya public/ atau dist/;
  • secret diberikan melalui secret manager atau environment deployment, bukan disimpan di repository;
  • file dokumentasi internal, test fixture, cache, log, dan backup tidak ikut dipublikasikan.

Contoh pola deployment sederhana:

# Di workspace build, bukan di web root publik
git clone --depth 1 https://git.example/internal/app.git build/app
cd build/app
./build-production.sh

# Salin hanya artefak yang diperlukan ke release directory
rsync -a --delete public/ /srv/releases/app-current/

Perintah build setiap aplikasi berbeda, tetapi prinsipnya sama: hasil akhir harus berupa artefak terkontrol, bukan seluruh repository. Pada deployment berbasis container, gunakan multi-stage build agar metadata Git dan tool build tidak masuk ke image runtime. Tambahkan pemeriksaan pipeline yang gagal jika .git, file secret, atau backup ditemukan dalam artefak yang akan dipublikasikan.

Memantau Access Log dan Mendeteksi Crawler

Permintaan ke path seperti /.git/config, /.git/HEAD, /.git/index, atau variasi dengan encoding berbeda dapat menjadi sinyal scanning. Satu request tidak selalu membuktikan kompromi, tetapi pola berulang dari alamat sumber yang sama atau banyak path sensitif layak diberi alert.

Contoh pencarian awal pada log Nginx atau Apache yang menggunakan format request umum:

grep -Eai '(/|%2f)\.git(/|%2f|%3f|$)|/\.env($|[/?])|/wp-config\.php|\.sql($|[/?])' \
  /var/log/nginx/access.log

Untuk lingkungan produksi, lebih baik kirim log ke sistem terpusat dan buat deteksi berdasarkan:

  • path sensitif yang diminta, termasuk variasi URL encoding dan perbedaan huruf besar-kecil;
  • jumlah request unik dalam jendela waktu tertentu;
  • status respons, terutama kombinasi 200, 206, atau ukuran respons yang tidak biasa;
  • alamat IP, autonomous system, user-agent, dan pola distribusi request;
  • munculnya request ke banyak file konfigurasi atau endpoint admin dalam urutan singkat.

Alert sebaiknya mengarah pada verifikasi, bukan langsung memblokir semua crawler. Scanner keamanan internal, uptime monitor, atau integrasi pihak ketiga dapat menghasilkan pola serupa. Korelasikan alert dengan deployment, perubahan konfigurasi, dan log aplikasi sebelum mengambil tindakan pemblokiran.

Catatan: robots.txt bukan kontrol keamanan. File tersebut hanya memberi petunjuk kepada crawler yang mematuhinya; scanner berbahaya dapat mengabaikannya. Jangan mencantumkan path rahasia di sana dengan asumsi path tersebut menjadi terlindungi.

Respons Jika .git/config Pernah Terekspos

Anggap paparan sebagai insiden keamanan sampai terbukti sebaliknya. Kecepatan penting, tetapi jangan menghapus bukti sebelum log dan konteks insiden diamankan.

1. Isolasi dan hentikan paparan

  1. Blokir path pada Nginx, Apache, gateway, atau WAF, lalu deploy perbaikan permanen.
  2. Jika perlu, keluarkan host dari traffic publik atau batasi akses sementara.
  3. Simpan salinan log yang relevan, waktu kejadian, status respons, ukuran respons, dan sumber request.
  4. Periksa apakah file benar-benar berisi data dan apakah request lain mengarah ke object Git atau file sensitif.

2. Audit histori Git

Periksa seluruh branch dan tag, bukan hanya commit terbaru. Cari file yang pernah memuat secret dan review perubahan yang relevan:

git log --all --full-history -- .env config/ secrets/
git log --all -S'API_KEY' --oneline --decorate
git rev-list --all --objects | grep -Ei '(^|/)(\.env|config|secret|backup)'

Gunakan secret-scanning tool yang sesuai dengan kebijakan organisasi untuk memeriksa commit, branch, tag, dan artefak CI. Perlu diingat bahwa menghapus file pada commit terbaru tidak menghapusnya dari histori yang masih dapat diakses.

3. Cabut dan rotasi secret

Segera cabut token, password, private key, credential cloud, webhook secret, dan kredensial database yang mungkin pernah berada di repository atau histori. Buat nilai baru, perbarui aplikasi secara aman, dan verifikasi bahwa nilai lama benar-benar tidak lagi diterima. Jangan hanya mengganti nama variabel atau menghapus file dari working tree.

4. Pertimbangkan pembersihan histori

Jika secret masuk ke histori, lakukan pembersihan repository dengan prosedur resmi organisasi dan koordinasikan force-push, mirror, fork, cache CI, serta clone yang sudah beredar. Pembersihan histori mengurangi paparan di repository, tetapi tidak membatalkan secret; pencabutan dan rotasi tetap wajib dilakukan lebih dulu.

5. Verifikasi ulang dan dokumentasikan

Uji endpoint dari luar jaringan internal, periksa seluruh frontend atau origin yang relevan, dan pastikan respons tidak lagi mengandung metadata Git. Audit kembali pipeline, izin file, web root, cache, CDN, dan backup. Catat timeline, dampak, secret yang dirotasi, bukti log, serta tindakan pencegahan agar insiden dapat ditutup secara terukur.

Checklist Hardening

  • Web root hanya berisi artefak runtime yang memang perlu disajikan.
  • Direktori .git tidak ada di web root maupun image runtime.
  • Nginx atau Apache menolak path .git dan konfigurasi sudah diuji.
  • File .env, backup, dump database, dan konfigurasi internal tidak terpublikasi.
  • Pipeline memeriksa isi artefak sebelum deployment.
  • Access log dikirim ke sistem terpusat dan memiliki alert untuk pola scanning.
  • Secret disimpan di secret manager atau mekanisme konfigurasi runtime.
  • Terdapat prosedur isolasi, audit histori, rotasi secret, dan verifikasi pascainsiden.
  • Tim memahami bahwa robots.txt bukan mekanisme pembatasan akses.

Memblokir /.git/config menyelesaikan gejala yang terlihat, tetapi pencegahan utama tetap berada pada desain deployment: repository bukan artefak publik. Kombinasikan pemisahan web root, aturan web server, validasi build, pemantauan log, dan rotasi secret agar kebocoran metadata Git tidak berubah menjadi kompromi aplikasi.