Bir web uygulamasını yayına alırken yapılan küçük bir dağıtım hatası, tüm kaynak kodunun dışarıdan okunabilir hale gelmesine neden olabilir. Özellikle hosting ortamında proje klasörü doğrudan web kök dizinine kopyalanıyorsa, uygulamayla birlikte gelen .git klasörü kritik bir risk oluşturur. Bu klasör yalnızca sürüm geçmişini değil; dosya adlarını, eski kod parçalarını, yapılandırma değişikliklerini ve bazen yanlışlıkla eklenmiş gizli bilgileri de barındırabilir.
Git klasörü normalde geliştiricinin yerel çalışma alanında veya özel bir depo sunucusunda kalmalıdır. Ancak web sunucusu nokta ile başlayan dizinleri engellemiyor ya da yanlış yapılandırılmışsa, saldırganlar bu dizindeki parçalardan projenin geçmişini yeniden oluşturabilir. Bu durum yalnızca “kod görüntülendi” seviyesinde kalmaz; veritabanı bağlantıları, API anahtarları, eski güvenlik açıkları ve iş mantığı da incelenebilir hale gelir.
Git klasörü neden tehlikeli bilgi içerir?
.git dizini, projenin sürüm kontrol veritabanıdır. İçinde commit geçmişi, referanslar, nesne dosyaları ve bazen dal bilgileri bulunur. Uygulamanın güncel dosyaları web üzerinden listelenmiyor olsa bile, bu Git verileri erişilebilir olduğunda kaynak kodu parça parça çıkarılabilir.
Riskin önemli kısmı, yalnızca mevcut kodla sınırlı olmamasıdır. Geliştirici geçmişte bir şifreyi dosyaya ekleyip daha sonra silmiş olabilir. Dosya güncel sürümde temiz görünse de commit geçmişinde bu bilgi durabilir. Bu nedenle Git klasörü sunucuda açık kalırsa saldırgan, eski sürümlerdeki hassas verileri de arayabilir.
Kaynak kodu nasıl ifşa olabilir?
Yanlış yapılandırılmış bir sunucuda saldırgan önce /.git/HEAD gibi bilinen yolları kontrol eder. Bu dosya erişilebilir durumdaysa, depo yapısının dışarıdan okunabildiğine dair güçlü bir işarettir. Ardından Git nesneleri, referans dosyaları ve paketlenmiş nesne arşivleri indirilerek proje yeniden oluşturulmaya çalışılır.
Bu işlem her zaman dizin listeleme açık olduğunda yapılmaz. Dizin listeleme kapalı olsa bile bilinen dosya yolları tahmin edilebilir. Örneğin .git/config, .git/index veya .git/objects/ altındaki nesneler üzerinden kod geçmişine ulaşılabilir. Bu yüzden yalnızca “klasör listelenmiyor” diye güvenli kabul etmek hatalıdır.
İfşa edildiğinde hangi bilgiler risk altına girer?
Kaynak kodunun açığa çıkması, saldırgana uygulamanın çalışma mantığını gösterir. Yetkilendirme kontrolleri, yönetici panellerinin yolları, üçüncü taraf servis entegrasyonları ve hata yönetimi gibi alanlar analiz edilebilir. Kod içinde çevresel değişkenler yerine doğrudan yazılmış veritabanı bilgileri varsa, etki daha da büyür.
Ayrıca eski commit kayıtlarında test kullanıcıları, geçici parolalar, özel endpoint bilgileri veya kapatılmış zannedilen güvenlik açıkları bulunabilir. Kurumsal projelerde bu durum yalnızca teknik değil, sözleşmesel ve operasyonel bir risk de doğurur.
Sunucuda açık olup olmadığını nasıl kontrol edebilirsiniz?
İlk kontrol basittir: tarayıcıdan alan adınızın sonuna /.git/HEAD ekleyerek yanıtı inceleyebilirsiniz. İçerikte ref: refs/heads/ benzeri bir çıktı görüyorsanız, erişim engellenmemiş demektir. Ancak 403 yanıtı her zaman tam güvenlik anlamına gelmez; farklı dosyalar hâlâ erişilebilir olabilir.
Daha sağlıklı kontrol için dağıtım sürecinizi de gözden geçirin. Canlı ortama kopyalanan paket içinde .git, .env, yedek dosyalar, SQL dökümleri ve geçici arşivler bulunmamalıdır. hosting panelinden dosya yöneticisi kullanılıyorsa, gizli dosyaların görüntülenmesi açık hale getirilerek bu klasörler ayrıca kontrol edilmelidir.
Nasıl önlem alınır?
En güvenli yaklaşım, canlı sunucuya Git çalışma kopyasını değil, yalnızca çalışması gereken uygulama dosyalarını göndermektir. CI/CD süreci kullanılıyorsa build çıktısı temiz bir artefakt olarak üretilmeli ve sürüm kontrol klasörü bu pakete dahil edilmemelidir.
Apache kullanılan ortamlarda nokta ile başlayan klasörlere erişim engellenmelidir. Nginx tarafında da benzer biçimde gizli dosya ve dizinlere web erişimi kapatılmalıdır. Bu kural yalnızca .git için değil, .env, .svn ve benzeri hassas dosyalar için de uygulanmalıdır.
Dağıtımda sık yapılan hatalar
En yaygın hata, geliştiricinin yerel proje klasörünü FTP ile doğrudan public dizine yüklemesidir. Bu yöntem hızlı görünür ancak gereksiz dosyaları da beraberinde taşır. Bir diğer hata, kök dizin ile public dizinin karıştırılmasıdır. Uygulamanın yalnızca erişilmesi gereken public veya web klasörü dışarı açık olmalıdır; yapılandırma ve bağımlılık dosyaları mümkünse web kökünün dışında kalmalıdır.
Git geçmişine daha önce gizli bilgi eklendiyse, dosyayı silmek tek başına yeterli değildir. İlgili anahtarlar yenilenmeli, parolalar değiştirilmelidir. Gerekirse Git geçmişi temizlenmeli ve uzak depo yeniden düzenlenmelidir. Bu işlem dikkatli yapılmalıdır; ekip içinde kullanılan depolarda geçmişi değiştirmek senkronizasyon sorunlarına yol açabilir.
Olay yaşandıysa izlenecek pratik adımlar
Önce web erişimini hemen kapatın veya .git klasörünü canlı ortamdan kaldırın. Ardından erişim loglarını inceleyerek /.git/ altında hangi dosyalara istek geldiğini kontrol edin. Sadece birkaç deneme isteği ile kapsamlı indirme girişimi arasında müdahale seviyesi farklı olacaktır.
Sonraki adım, kod içinde ve Git geçmişinde gizli bilgi taraması yapmaktır. Veritabanı şifreleri, servis tokenları, ödeme sistemi anahtarları ve yönetici bilgileri yenilenmelidir. Uygulama güvenlik testinden geçirilmeli; saldırganın kodu inceleyerek kullanabileceği zayıf noktalar önceliklendirilmelidir. Canlı ortamda temiz dağıtım standardı oluşturulduğunda, aynı hatanın tekrar etme ihtimali belirgin şekilde azalır.