- Katılım
- 21 May 2023
- Mesajlar
- 539
- Tepki
- 17
- Puan
- 18
Canlı bir sitede sayfanın ortasında beliren sarı bir PHP uyarısı ya da veritabanı bağlantı bilgilerini içeren bir hata metni, ilk bakışta yalnızca can sıkıcı, zararsız bir görsel bozukluk gibi görünür. Oysa ekrana yazdırılan her satır, aslında sunucunun içini gösteren bir pencere.
Bu yazı, PHP'nin hata gösterme ayarının resmî olarak ne dediğini ve bu ayarın açık kalmasının neden güvenlik riski sayıldığını gösteriyor.
display_errors tam olarak ne yapıyor?
PHP'nin resmî kılavuzuna göre `display_errors` yönergesi, PHP hatalarının çıktı akışına (genelde tarayıcı ekranına) yazdırılıp yazdırılmayacağını kontrol ediyor; varsayılan değeri "On". Yönerge "Off", "On", "stdout" veya "stderr" değerlerini alabiliyor; CLI ortamında `stderr` seçilerek hatalar terminale, tarayıcıya değil, yönlendirilebiliyor.
Kılavuz bu ayarı bir geliştirme kolaylığı olarak tanımlıyor ve tam bu noktada dikkat çekici bir uyarı içeriyor: "Bu, geliştirmenizi desteklemek için bir özelliktir ve üretim sistemlerinde (örneğin internete bağlı sistemlerde) asla kullanılmamalıdır." Yani bu ayarın canlı bir sitede açık kalması, dokümantasyonun kendisinin açıkça karşı çıktığı bir durum.
Bu ayarın nerede tanımlı olduğu da önemli: `php.ini` dosyasında, sunucu bazında ya da `.htaccess`/sanal sunucu yapılandırmasında ayrı ayrı belirlenebiliyor. Bazı barındırma ortamlarında geliştirme sırasında elle "On" yapılan bu değer, siteyi canlıya alırken geri "Off"a çevrilmeyi unutulan bir ayar olarak kalabiliyor; sorun kötü niyetli bir yapılandırmadan değil, çoğu zaman bu tür bir unutkanlıktan kaynaklanıyor.
Ekrana yazdırılan hata gerçekte neyi ifşa ediyor?
Bir PHP hatası genelde dosya yolunu, satır numarasını ve bazen çalıştırılan sorgunun bir kısmını içeriyor. OWASP'ın Error Handling Cheat Sheet'ine göre her saldırı bir keşif (reconnaissance) aşamasıyla başlıyor ve saldırgan hedef hakkında teknik bilgi toplamaya çalışıyor; işlenmeyen hata mesajları tam olarak bu keşif aşamasını kolaylaştıran bilgiyi -sunucu/framework sürümü, kütüphane detayları, dosya yapısı- doğrudan saldırgana sunuyor.
Bu iki belgeyi yan yana okuduğunuzda ortaya çıkan tablo net: PHP'nin kendi kılavuzu bunu bir geliştirme özelliği olarak sınırlarken, OWASP aynı davranışın saldırganın işini nasıl kolaylaştırdığını gösteriyor. OWASP'ın verdiği örnekler arasında sunucu ve framework sürüm bilgisi taşıyan yığın izleri (stack trace) ve bazen doğrudan SQL sorgusunun kendisi de yer alıyor; bir saldırgan için bu bilgiler, hangi bilinen açığı deneyeceğine karar vermek için gereken haritayı çıkarıyor.
display_errors ile error_reporting karıştırılmamalı
Bu iki ayar sık karıştırılıyor ama PHP'nin kılavuzu ikisini net biçimde ayırıyor: `error_reporting()` hangi hata seviyelerinin (E_ALL, E_NOTICE, E_WARNING gibi) yakalanıp raporlanacağını belirlerken, `display_errors` bu raporlanan hataların ekrana yazdırılıp yazdırılmayacağını kontrol ediyor. Yani biri "hangi hatalar önemli" sorusuna, diğeri "bu hatalar nereye gitsin" sorusuna cevap veriyor.
Bu ayrımı bilmemek yaygın bir yanlış varsayıma yol açıyor: yalnızca `error_reporting(0)` ile hata raporlamayı kapatıp `display_errors`'ı unutmak. Bu durumda hatalar günlüğe de düşmüyor, hiçbir yerde iz bırakmadan kayboluyor; oysa amaç hataları gizlemek değil, doğru kanala (günlük dosyasına) yönlendirmek. Üretimde önerilen kombinasyon `error_reporting(E_ALL)` ile tüm hataları yakalayıp `display_errors = Off`, `log_errors = On` ile bunları yalnızca günlük dosyasına yazdırmak.
Üretimde doğru yapılandırma nasıl kuruluyor?
PHP kılavuzu, `display_errors` kapatıldığında hataların kaybolmaması için ayrı bir mekanizma öneriyor: `log_errors` yönergesini açmak ve `error_log` ile hataların yazılacağı dosyayı belirlemek. Bu sayede hata kullanıcı ekranında görünmüyor ama sunucu tarafında bir günlük dosyasına düşmeye devam ediyor; geliştirici siteyi ziyaret etmeden, günlüğü okuyarak sorunu takip edebiliyor.
Pratikte bu üç satırlık bir değişiklik: `display_errors = Off`, `log_errors = On`, `error_log = /var/log/php-errors.log` (ya da barındırma sağlayıcınızın belirlediği yol). Paylaşımlı hostingde bu ayarlara doğrudan erişiminiz olmayabilir; bu durumda `.htaccess` veya panel üzerindeki PHP ayarları bölümünden aynı değerleri değiştirmeniz gerekiyor. Değişikliği yaptıktan sonra ayarın gerçekten uygulandığını doğrulamak da ayrı bir adım: `phpinfo()` çıktısında `display_errors` satırının "Off" göründüğünü teyit etmeden, ayarın etkin olduğunu varsaymak yanıltıcı olabiliyor, çünkü bazı panellerde birden fazla php.ini dosyası aynı anda devrede olabiliyor.
UTF-8 gibi başka çıktı sorunlarıyla karışmasın
Ekranda beliren her garip karakter bir güvenlik sorunu değil; bazen görsel bir kodlama sorunu, hata mesajıyla karışabiliyor. Türkçe karakterlerin soru işaretine dönüştüğü bir sorunla karşılaşıyorsanız bu farklı bir teşhis konusu; karakter kodlama zincirini nasıl izleyeceğinizi anlatan yazı bu ayrımı netleştiriyor. İkisini karıştırmamak, doğru düzeltmeyi doğru yere uygulamanızı sağlıyor: biri sunucu ayarı, diğeri karakter kümesi/veritabanı bağlantı ayarı meselesi.
Genel bir güvenlik denetimi yaparken hata gösterimi tek başlık değil; daha geniş bir kontrol listesi sunan yazı display_errors dışındaki yaygın yapılandırma hatalarını da bir arada topluyor. PHP'nin bir web projesinde diğer bileşenlerin neresinde durduğunu genel hatlarıyla hatırlamak isteyenler için de bu genel bakış yazısı bir başlangıç noktası sunuyor.
Üretim ortamına geçmeden önce kontrol edilmesi gereken üç ayar:
- display_errors: Üretimde "Off" olmalı, yalnızca geliştirme ortamında "On" kalmalı.
- log_errors + error_log: Hatalar ekrandan kalksa da bir günlük dosyasına düşmeye devam etmeli.
- Ortam ayrımı: Geliştirme ve üretim için ayrı php.ini/panel ayarları kullanmak, unutkanlıktan kaynaklanan sızıntıyı önlüyor.
Kontrol noktası' Alıntı:
Sık Sorulan Sorular
PHP hata gösterme nasıl kapatılır?
Üretim ortamında hataların ekrana basılması kapatılır, bunun yerine dosyaya günlüklenir. Böylece hata kaybolmaz ama ziyaretçiye görünmez.
PHP hata gösterme ile hata raporlama aynı şey mi?
Değildir. Biri hangi hata türlerinin yakalanacağını belirler, diğeri yakalanan hatanın ekrana yazılıp yazılmayacağını. İkisi ayrı ayrı ayarlanır.
Hata mesajları neden riskli sayılıyor?
Hata çıktısı dosya yolu, veritabanı adı ve sorgu parçaları gibi iç bilgileri açığa çıkarabilir. Bu bilgiler saldırgan için keşif malzemesidir.
Özetle
PHP'nin kendi kılavuzu `display_errors` yönergesini açıkça bir geliştirme özelliği olarak tanımlıyor ve üretimde kullanılmamasını öneriyor; OWASP'ın hata yönetimi rehberi de bu hataların saldırgana keşif bilgisi sağladığını doğruluyor. Doğru çözüm hataları yok saymak değil, ekrandan kaldırıp günlük dosyasına yönlendirmek.
Canlı sitenizde display_errors ayarını son olarak ne zaman kontrol ettiniz?
Güncelleme: 24 Ağustos 2026.
Dijital Dünyanıza Yön Veren Pusula
