Yedek klasörleri public_html içinde bırakılırsa ne olur?

Web sitesi taşıma, güncelleme veya sorun giderme sırasında alınan yedekler çoğu zaman hızlı erişim amacıyla aynı dizinde tutulur. Ancak yedek klasörlerinin public_html içinde bırakılması, yalnızca düzen açısından değil, güvenlik ve veri gizliliği açısından da ciddi riskler doğurabilir. Çünkü public_html, web sunucusunun internetten erişilebilir kök dizinidir; buraya konan birçok dosya, doğru önlem alınmadığında tarayıcı üzerinden görüntülenebilir veya indirilebilir.

public_html neden hassas bir dizindir?

public_html, alan adınıza gelen ziyaretçilerin doğrudan eriştiği ana web klasörüdür. WordPress dosyaları, tema ve eklenti kaynakları, görseller, bazı yapılandırma dosyaları ve statik içerikler bu alanda yer alır. Bu dizinde bulunan her dosya otomatik olarak güvenli değildir; sunucu yapılandırmasına, dosya izinlerine ve dosya uzantısına göre dışarıdan erişilebilir hale gelebilir.

Örneğin site-yedek.zip, backup-old, public_html_backup veya wp-yedek gibi tahmin edilebilir klasör ve dosya adları, kötü niyetli tarayıcı botları tarafından kolayca denenebilir. Bu nedenle hosting hesabında yedeklerin nerede tutulduğu, en az yedek almak kadar önemlidir.

Yedek klasörleri public_html içinde kalırsa hangi riskler oluşur?

Veritabanı bilgileri açığa çıkabilir

WordPress yedekleri genellikle yalnızca tema veya medya dosyalarından oluşmaz. İçlerinde veritabanı çıktıları, wp-config.php dosyası, eklenti ayarları, kullanıcı tabloları veya eski yapılandırma dosyaları bulunabilir. Bu dosyalar indirilebilir hale gelirse veritabanı adı, kullanıcı adı, parola, güvenlik anahtarları ve site URL yapısı gibi kritik bilgiler açığa çıkabilir.

Kişisel ve ticari veriler sızabilir

E-ticaret sitelerinde sipariş bilgileri, müşteri kayıtları, fatura verileri veya iletişim formlarından gelen içerikler yedek dosyalarında yer alabilir. Kurumsal bir web sitesinde ise teklif dokümanları, özel formlar, aday başvuruları veya dahili belgeler yanlışlıkla yedek içine dahil edilmiş olabilir. Bu durum yalnızca teknik bir güvenlik açığı değil, aynı zamanda itibar ve uyumluluk riski de oluşturur.

Eski açıklar yeniden kullanılabilir

Bir sitenin güncel sürümünde kapatılmış bir güvenlik açığı, eski yedek klasöründe hâlâ bulunabilir. Saldırganlar eski tema, eklenti veya özel yazılım dosyalarını inceleyerek güncel siteye uygulanabilecek zayıf noktaları tespit edebilir. Özellikle eski PHP dosyaları çalıştırılabilir durumdaysa, risk yalnızca bilgi sızıntısıyla sınırlı kalmaz.

Bu klasörler nasıl fark edilir?

Arama motorları ve otomatik botlar, tahmin edilebilir dizinleri düzenli olarak tarar. “backup”, “yedek”, “old”, “temp”, “copy”, “2023”, “site-eski” gibi adlar sık denenen kalıplardır. Dizin listeleme açıksa klasör içeriği doğrudan görüntülenebilir. Dizin listeleme kapalı olsa bile, dosya adı tahmin edilebiliyorsa ZIP, SQL veya TAR.GZ gibi arşivler indirilebilir.

Bu nedenle yalnızca “klasörü kimse bilmiyor” düşüncesi güvenli bir yaklaşım değildir. Güvenlik, gizli klasör adına değil, doğru konumlandırma, erişim kontrolü ve düzenli temizlik süreçlerine dayanmalıdır.

Yedekler nerede tutulmalı?

En güvenli yaklaşım, yedek dosyalarını webden erişilemeyen bir alanda saklamaktır. Birçok hosting panelinde public_html ile aynı seviyede, dışarıdan görüntülenmeyen üst dizinler bulunur. Yedekler mümkünse bu alana veya güvenli uzak depolama çözümlerine aktarılmalıdır.

• Web kökü dışında saklayın: public_html içine değil, erişime kapalı üst dizinlere taşıyın.
• Dosya adlarını tahmin edilebilir bırakmayın: “backup.zip” gibi genel adlar kullanmayın.
• Şifreleme kullanın: Özellikle veritabanı içeren arşivleri şifreli tutun.
• Yerel ve uzak kopya planı yapın: Tek kopyayı sunucuda bırakmak operasyonel risk oluşturur.
• Eski yedekleri silin: Gereksiz yedekler arttıkça saldırı yüzeyi de büyür.

public_html içinde yedek varsa ne yapılmalı?

Öncelikle paniğe kapılmadan mevcut durumu kontrol etmek gerekir. Dosya yöneticisi veya FTP üzerinden public_html dizininde yedek, eski kopya, sıkıştırılmış arşiv ve veritabanı dosyaları aranmalıdır. Özellikle .zip, .tar, .tar.gz, .sql, .bak, .old uzantılı dosyalar dikkatle incelenmelidir.

Gerekli dosyalar web kökü dışına taşınmalı, artık kullanılmayanlar güvenli şekilde silinmelidir. Eğer yedek dosyalarının bir süre erişilebilir kaldığından şüpheleniliyorsa veritabanı parolası, WordPress yönetici parolaları, FTP bilgileri ve panel erişimleri değiştirilmelidir. wp-config.php içinde yer alan veritabanı bilgileri sızmış olabilir; bu nedenle yalnızca WordPress şifresini değiştirmek yeterli olmayabilir.

Yanlış yapılan yaygın güvenlik önlemleri

Sadece index.html koymak yeterli değildir

Bazı kullanıcılar klasöre boş bir index.html dosyası koyarak dizin listelemeyi engellediğini düşünür. Bu yöntem klasör içeriğinin listelenmesini zorlaştırabilir; ancak dosya adı bilinen bir arşivin indirilmesini engellemez. Örneğin backup.zip dosyası hâlâ doğrudan çağrılabilir.

robots.txt güvenlik aracı değildir

robots.txt dosyası arama motorlarına tarama tercihi bildirir; erişim kontrolü sağlamaz. Hatta hassas klasörleri robots.txt içinde belirtmek, kötü niyetli kişiler için hedef listesi oluşturabilir. Güvenlik için robots.txt yerine dosya izinleri, sunucu kuralları ve doğru dizin kullanımı esas alınmalıdır.

Geçici klasörler kalıcı hale gelmemelidir

Taşıma veya güncelleme sırasında oluşturulan “eski-site” klasörü çoğu zaman unutulur. Bu klasörlerde test amaçlı yüklenen eklentiler, eski yönetici hesapları veya çalışmayan ama okunabilir yapılandırmalar bulunabilir. İşlem tamamlandıktan sonra geçici klasörler mutlaka kontrol edilmelidir.

Sunucu tarafında ek koruma nasıl sağlanır?

Sunucu yapılandırmasına erişiminiz varsa dizin listeleme kapatılmalı, hassas dosya uzantılarına doğrudan erişim engellenmeli ve yedek arşivlerinin çalıştırılabilir alanlarda bulunması önlenmelidir. Paylaşımlı yapılarda bu ayarların bir kısmı panel üzerinden yapılabilir; emin olunamayan durumlarda teknik destekten ilgili dizinlerin web erişimine kapalı olup olmadığı teyit edilmelidir.

Düzenli bakım planına yedek konumu kontrolü eklemek, küçük ama etkili bir önlemdir. Her büyük güncelleme, taşıma veya geri yükleme işleminden sonra public_html içinde gereksiz arşiv, eski klasör ve veritabanı çıktısı kalmadığını kontrol etmek; güvenli, sürdürülebilir ve kurumsal bir hosting yönetimi için temel alışkanlıklardan biridir.