İçinde indeks dosyası bulunmayan bir medya alt dizini, sunucu yapılandırmasına bağlı olarak otomatik dosya listesi gösterebilir. Bu listede eski ZIP yedekleri, loglar veya unutulmuş dışa aktarma dosyaları görünüyorsa normal WordPress sayfaları sorunsuz çalışsa bile hassas bilgiler açığa çıkar.
Apache uyumlu ortamlarda dizin indeksini kapatmak kolaydır; ancak bu işlem yalnız otomatik listeyi engeller. Tam URL’si bilinen dosyalar erişilebilir kalır. Hassas içerik ayrıca web kökünden kaldırılmalı veya uygun erişim kuralıyla korunmalıdır.
Dizin listeleme nedir?
Web sunucusu, doğrudan istenen bir klasörde indeks dosyası bulamazsa dosya ve alt klasör adlarından otomatik bir sayfa oluşturabilir. Apache’de bu davranış Indexesseçeneğiyle ilişkilidir. Hosting izin veriyorsa Options -Indexesilgili dizin ve alt dizinlerde otomatik listeyi kapatır.
Gerçekçi bir örnek
/wp-content/uploads/arsiv/adresi, klasördeki görsellerin yanı sıra eski bir veritabanı dışa aktarımını ve ZIP yedeğini listeler. Dizin indeksi kapatılınca klasör adresi 403 verir; fakat doğrudan istenen geçerli görseller açılmaya devam eder. SQL ve ZIP dosyaları ise web kökünden tamamen çıkarılır.
Ne sağlar, ne sağlamaz?
Dizin listelemeyi kapatmak, ziyaretçinin dosya adlarını topluca görmesini engeller. Dosyayı silmez, şifrelemez veya tam adresi bilen birinin indirmesini önlemez. Bu nedenle yedek, log, yapılandırma ve dışa aktarma dosyaları herkese açık dizinlerde tutulmamalıdır.
Hosting panelinde aynı işlevi yöneten “directory browsing” ayarı bulunabilir. Aynı davranışı birden fazla katmanda tekrar etmek yerine tek, belgelenmiş yöntemi kullanın.
Güvenli uygulama
- İndeks dosyası olmayan kontrollü bir klasörü doğrudan açarak listelemenin gerçekten etkin olduğunu doğrulayın.
- Etkin
.htaccessdosyasını web kök dizini dışında yedekleyin. Options -Indexesyönergesini doğru dizin kapsamına, WordPress işaretlerinin dışına ekleyin.- Klasör URL’sini anonim oturumda yeniden açın; listenin artık gösterilmediğini kontrol edin.
- Bilinen görsel, CSS, JavaScript ve indirilebilir dosyaların hâlâ çalıştığını sınayın.
Teknik doğrulama
403, otomatik listenin kapandığı yaygın bir sonuçtur. 500 hatası oluşursa sunucu hata logunda “Options not allowed here” benzeri mesaj arayın. Bu, yönergenin yazımından ziyade hosting firmasının AllowOverridepolitikasına işaret edebilir.
- WordPress kökünü, uploads dizinini, bir eklenti varlık klasörünü ve kontrollü boş dizini ayrı sınayın.
- Üst dizindeki
.htaccessdosyasından miras alınan seçenekleri kontrol edin. - Web kökünde ZIP, SQL, log ve eski yapılandırma kopyaları arayıp güvenli konuma taşıyın.
- Nginx kullanılıyorsa bu dosyanın etkisiz olduğunu ve eşdeğer ayarın sunucu yapılandırmasında yapılması gerektiğini unutmayın.
Riskler ve geri alma
Hosting ortamında Optionsyönergesi yasaksa değişiklik bütün siteyi 500 hatasına düşürebilir. Kural yanlış alt dizine eklenirse hiç etkili olmayabilir. Listeyi kapatıp hassas dosyaları yerinde bırakmak da sahte güven duygusu yaratır.
500 görülürse son çalışan dosyayı bağımsız hosting erişiminden geri yükleyin. Sağlayıcının desteklediği dizin tarama ayarını kullanın ve hassas dosyaları yine web kökünden çıkarın.
AIOWS nasıl yardımcı olur?
AIOWS Htaccess Düzenleyici
AIOWS Htaccess Düzenleyici, etkin dosyada dizin listeleme yönergesini inceleyip dar bir değişiklik olarak kaydetmenize yardımcı olur. Modül, dosyayı kaydetmeden önce yedek oluşturur; desteklenmeyen bir yönerge 500 hatasına yol açarsa bu yedekle son değişiklik geri alınabilir.
Modül hosting firmasının Optionspolitikasını değiştiremez ve herkese açık dizindeki hassas dosyaları kendiliğinden taşımaz. Kuralın desteklendiğini sunucu yanıtıyla doğrulayın; ayrıca web kök dizini dışında bağımsız yedek bulundurun.
AIOWS Htaccess Düzenleyici’yi inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- wp-config.php Dosyası .htaccess ile Nasıl Korunur?
- WordPress’te XML-RPC .htaccess ile Nasıl Engellenir?
- WordPress’te .htaccess ile Güvenlik Başlıkları: HSTS, CSP ve Daha Fazlası
Sonuç
Dizin indeksini doğru Apache kapsamında kapatın, fakat bunu dosya koruması sanmayın. Hassas yedek ve logları web kökünden çıkarın; normal WordPress dosyalarının erişilebilir kaldığını ayrıca sınayın.
