WordPress debug.log dosyası neden herkese açık olmamalıdır?

WordPress’in wp-content/debug.log dosyası hata ayıklama sırasında PHP, WordPress çekirdeği ve eklentilerin ürettiği kayıtları tutar. Dosya web kökünde ve doğrudan erişilebilir durumdaysa, adresi bilen herkes bu kayıtları okuyabilir. İçeriğe bağlı olarak sunucu yolları, eklenti adları ve sürüm bilgileri, istek ayrıntıları, hata mesajları ve bir eklentinin yanlışlıkla yazdığı hassas veriler açığa çıkabilir. Bu nedenle debug.log yalnızca gerektiğinde tutulmalı, normal kullanımda tarayıcıdan erişilememelidir.

Dosya nasıl oluşur ve risk nereden gelir?​

WordPress hata ayıklama etkinleştirildiğinde WP_DEBUG_LOG değeri true ise kayıtlar genellikle wp-content/debug.log dosyasına yazılır. WordPress bu dosyayı oluşturmuş olsa bile, web sunucusunun her dosyayı otomatik olarak koruyacağı varsayılamaz. Dosya için özel bir erişim engeli yoksa şu tür bir istek başarılı olabilir:

/wp-content/debug.log

Örneğin bir eklenti hatasında log içinde /var/www/example.com/wp-content/plugins/ornek-eklenti/ gibi sunucu yolları, sınıf ve dosya adları görülebilir. Bir eklenti hata ayıklama amacıyla oturum bilgisi, API yanıtı veya istek verisi yazıyorsa risk daha da büyür. Her debug.log kesin olarak parola içerir denemez; ancak içeriğin eklenti ve tema koduna bağlı olması, dosyayı herkese açık bırakmamak için yeterli nedendir.

Uygulanabilir düzeltme adımları​

Önce dosyanın gerçekten dışarıdan okunabildiğini kontrol edin. Tarayıcıda veya bir HTTP istemcisinde debug.log adresini açın. İçerik görünüyorsa dosya herkese açıktır; 403 veya uygun bir 404 yanıtı erişimin engellendiğini gösterir. 200 yanıtı alıp boş içerik görmeniz ise güvenli olduğu anlamına gelmez; sunucu yapılandırmasını ayrıca doğrulayın.

1. Aktif bir teşhis gerekmiyorsa WordPress yapılandırmasında hata ayıklamayı kapatın. wp-config.php içinde mevcut debug tanımlarını çoğaltmadan şu değerleri kullanın:
   
   Kod:

   define( 'WP_DEBUG', false );
   define( 'WP_DEBUG_LOG', false );
   define( 'WP_DEBUG_DISPLAY', false );

   Aynı sabitler dosyada daha önce tanımlıysa yeni satır eklemek yerine mevcut satırları düzenleyin. Tanımların WordPress’in “That's all, stop editing” satırından önce bulunması gerekir.
2. Gerekli olay kanıtını ve yedekleri koruyarak mevcut logun HTTP erişimini kapatın; dosyayı web kökü dışında yalnız yetkili erişime açık tutun. Önce ihtiyaç varsa dosyayı yalnızca yetkili yöneticinin erişebildiği yerel bir ortama indirin. Dosya daha önce herkese açıksa, indirilmiş veya önbelleğe alınmış kopyaların var olabileceğini varsayın.
3. Teşhis için log tutulması gerekiyorsa ek olarak web sunucusunda erişimi engelleyin. Apache ve .htaccess kullanılabilen bir kurulumda, wp-content dizinindeki uygun erişim yapılandırmasına şu kural eklenebilir:
   
   Kod:

   <Files "debug.log">
       Require all denied
   </Files>

   Bu kural her sunucuda çalışmaz. Nginx, farklı bir Apache yapılandırması veya yönetilen hosting kullanıyorsanız aynı dosyayı sunucu yönetim panelindeki dosya erişim kuralıyla engelleyin; .htaccess dosyasına yazmak tek başına yeterli olmayabilir.
4. Erişimi tekrar test edin. Beklenen sonuç dosyanın içeriğinin verilmemesi, çoğunlukla 403 veya 404 yanıtıdır. 200 yanıtı alıyorsanız kural yanlış yerde olabilir, sunucu bu dosyayı uygulamıyor olabilir ya da CDN eski yanıtı önbellekten sunuyor olabilir.
5. Teşhis tamamlanınca WP_DEBUG ve WP_DEBUG_LOG değerlerini kapalı bırakın, logları gerekli saklama/olay inceleme politikasına göre özel alanda koruyun ve gerekiyorsa CDN’de açığa çıkmış yanıtın önbelleğini geçersiz kılın. Tüm kayıtları incelemeden silmeyin.

WP_DEBUG_LOG’un çalışması için WP_DEBUG da etkin olmalıdır. Teşhiste WP_DEBUG_LOG değerine web kökü dışındaki mevcut ve PHP kullanıcısının yazabildiği mutlak bir dosya yolu verilebilir; bu dizini önceden uygun izinle hazırlayın. Sadece WP_DEBUG_DISPLAY=false tarayıcıdan dosya erişimini engellemez. PHP/webserver’ın ayrı error_log hedefi de ayrıca incelenir.

Sık yapılan hatalar​

Yalnızca dosyayı silip ayarı açık bırakmak: WordPress veya bir eklenti sonraki hatada dosyayı yeniden oluşturabilir. Kaydı kapatmak veya erişimi kalıcı biçimde engellemek gerekir.

Ekranda hata görünmüyor diye logu güvenli sanmak: WP_DEBUG_DISPLAY=false yalnızca hataların sayfa üzerinde gösterilmesini etkiler; log dosyasının HTTP üzerinden okunmasını engellemez.

Logu yeniden adlandırmayı yeterli görmek: Yeni ad tahmin edilmesi zor olsa bile güvenlik kuralı yerine geçmez. Dosya sunulabildiği sürece benzer risk devam eder.

Eski içeriği yok saymak: Erişim sonradan kapatılsa bile geçmişte yayımlanmış içerik tarayıcı, proxy veya üçüncü taraf önbelleklerde kalabilir. Logda sır niteliğinde bir değer bulunduğundan şüpheleniyorsanız ilgili parolayı, anahtarı veya belirteci yenileyin.

Kaynaklar​

• WordPress: Debug ve özel log dosya yolu
• Apache: Files erişim kapsamı

Sık sorulan sorular​

debug.log tamamen silinirse WordPress bozulur mu?​

Hayır. Dosya bir WordPress çekirdek bileşeni değil, hata kayıtlarının yazıldığı bir günlük dosyasıdır. Ancak hata ayıklama ayarı açık kalırsa sonraki hatada yeniden oluşturulabilir.

403 yanıtı güvenlik sorununu tamamen çözer mi?​

Dosyanın doğrudan okunmasını engeller; fakat sunucuda başka bir kopya, yedek veya CDN önbelleği bulunup bulunmadığını göstermez. Gerekli eski kayıtları özel alanda korumak, yayımlanan kopyalara erişimi kapatmak ve gerekiyorsa hassas bilgileri yenilemek ayrıca değerlendirilmelidir.