Saldırı WordPress'e
ulaşmadan durur.

Sorun — Eklenti olarak çalışan bir güvenlik duvarı, WordPress ve diğer tüm eklentiler belleğe yüklendikten sonra devreye girer; zararlı istek o ana kadar çoktan kod çalıştırmıştır.

Çözüm — Derlenmiş imza motoru PHP'nin en başında, WordPress'in tek satırı yüklenmeden önce koşar ve isteği orada keser.

Sorun — Parola denemeleri yalnız wp-login.php'den gelmez; XML-RPC, REST ve uygulama parolaları aynı hesaba ayrı kapılardan girer ve tek kapıyı sayan bir kilit bunları görmez.

Çözüm — Bütün giriş yolları tek kimlik kapısına bağlanır; kilit IP başına, hesap başına ve küresel olarak aynı anda sayar.

Sorun — Çalınmış bir yönetici parolası tek başına tam yetki demektir — ve parola sızıntıları çoğunlukla sizin sitenizden değil, başka bir servisten gelir.

Çözüm — TOTP, kurtarma kodu veya passkey kimlik doğrulama kapısında zorunlu kılınır; uygulama parolalarının ikinci faktörü atlatmadığı ayrıca denetlenir.

Sorun — Otomatik araçlar saniyede yüzlerce parola dener; bir insan için görünmez olan maliyet, bir bot için ölçek sorunudur.

Çözüm — Giriş isteği tarayıcıda çözülen bir proof-of-work ister — kullanıcı için milisaniyeler, yüz binlik bir deneme kampanyası için taşınamaz bir maliyet.

Sorun — Saldırı parola denemesiyle değil, geçerli kullanıcı adı listesiyle başlar; WordPress bu listeyi ?author=1, REST /users ve giriş hata mesajlarıyla kendiliğinden verir.

Çözüm — Üç sızıntı yolu da kapatılır ve giriş hatası, kullanıcının var olup olmadığını ayırt etmeyen tek bir metne indirilir.

Sorun — Parolayı değiştirmek, saldırganın elindeki çerezi geçersiz kılmaz; oturum açık kaldığı sürece parola değişikliği hiçbir şey çözmez.

Çözüm — Parola sıfırlama tüm oturumları, parola değişimi diğer tüm oturumları anında düşürür; kalanlar tek ekrandan toplu iptal edilir.

Sorun — wp-login.php'yi korumak yetmez; admin-ajax.php ve REST uçları kimlik doğrulaması olmadan da çağrılabilir ve aynı işi daha büyük ölçekte yapar.

Çözüm — REST ve AJAX yolları da hız sınırına bağlanır; şüphe götürmeyen eşleşmeler engellenir, gri kalanlar bloklanmadan kaydedilir.

Sorun — Tek bir XSS açığı, tarayıcı hiçbir kısıt uygulamadığında oturum çerezini, formu ve sayfadaki her şeyi saldırgana açar.

Çözüm — CSP, X-Frame-Options, Referrer-Policy ve Permissions-Policy gönderilir; zamanlanmış denetim başlıkların tarayıcıya gerçekten vardığını ayrıca ölçer.

Sorun — Başlıkları PHP gönderir; görsel, PDF ve JS dosyalarını sunucu doğrudan verir — o yanıtlarda PHP hiç çalışmaz, dolayısıyla hiçbir güvenlik başlığı bulunmaz.

Çözüm — Aynı başlıkları sunucu seviyesinde ekleyen kural üretilir ve denetim, kuralın kurulu olup olmadığını ölçer; kurulu değilse satır yeşile dönmez.

Sorun — WordPress'in varsayılanları uyumluluk için açıktır: sürüm numarası, RSD/WLW bağlantıları, pingback ve panel içindeki dosya düzenleyici. Her biri saldırgana ya bilgi ya doğrudan kod yazma imkânı verir.

Çözüm — Bu kalemler tek profille kapatılır ve her biri ayrı ayrı işaretlenir; hangisinin hâlâ açık olduğu gizlenmez.

Sorun — Uzantı ve MIME başlığı, istemcinin söylediği şeydir; .jpg uzantılı bir dosya pekâlâ PHP olabilir.

Çözüm — İzin listesi, uzantı-MIME-içerik üçlü eşleşmesi ve yeniden kodlama uygulanır; görüntü olduğunu söyleyip görüntü olarak çözülemeyen dosya reddedilir.

Sorun — wp-content/uploads dizini tanım gereği dışarıdan yazılabilir; oraya düşen tek bir PHP dosyası doğrudan çağrılabiliyorsa, yükleme filtresini atlatmak yeter.

Çözüm — Dizin altında PHP yürütmeyi kapatan sunucu kuralı yazılır ve zamanlanmış denetim kuralın hâlâ yerinde olduğunu ölçer.

Sorun — Arka kapı çoğunlukla yeni bir dosya değil, var olan bir çekirdek dosyasına eklenen birkaç satırdır; gözle bakınca fark edilmez.

Çözüm — Her çekirdek dosya WordPress.org'un yayımladığı resmî sağlama toplamıyla karşılaştırılır; bağımsız güncellenen paket eklentileri kapsam dışı tutulur, yoksa tertemiz bir kurulum bile alarm verir.

Sorun — Yavaşlatan bir güvenlik katmanı er geç kapatılır — ve sayfa ağırlığının büyük kısmı görsellerdir.

Çözüm — Yüklenen görsellerin WebP/AVIF karşılıkları üretilir; iş parça parça ve zamanlanmış koşar, tek istekte sunucuyu tıkamaz.

Sorun — Sıkılaştırma kurulumda bir kez yapılır; sonra biri WP_DEBUG'u açar, bir eklenti yetki ekler, bir kullanıcı administrator olur — ve kimse fark etmez.

Çözüm — On kalem her gün ölçülür: tehlikeli yetkiler, kayıt rolü, kritik sabitler, dosya izinleri, sahipsiz cron, zayıf yönetici parolası ve ömrü dolmuş PHP. İlk koşuda alınan temel ileri taşınmaz — onaylanmamış bir değişiklik yeni normal olamaz.

Sorun — wp-config.php, .htaccess ve object-cache.php gibi dropin dosyaları WordPress'ten önce yüklenir; birine yazabilen saldırgan her isteğe kod ekler.

Çözüm — Bu dosyaların içeriği temellenir ve her değişiklik ayrı bir bulgu olarak yükseltilir.

Sorun — Zararlı bulunan dosyayı silmek, yanlış pozitifte siteyi çökertir; hiç dokunmamak ise saldırganın dosyasını yerinde bırakır.

Çözüm — Dosya atomik taşımayla karantinaya alınır, hiçbir şey otomatik silinmez ve geri yükleme tek adımdır.

Sorun — Yönetici yetkisi ele geçiren saldırganın ilk işi izleri temizlemektir; silinebilen bir kayıt, olaydan sonra hiçbir şey anlatmaz.

Çözüm — Kayda yalnız ekleme yapılabilir ve her satır bir öncekinin özetini taşır; araya girildiğinde zincir kırılır ve bu ölçülebilir.

Sorun — Bir güvenlik ayarını sertleştirmek bazen siteyi bozar; geri dönüş yolu yoksa doğru olan değişiklik de hiç yapılmaz.

Çözüm — Her yazma öncesi snapshot alınır; bozulan ayar tek adımda geri alınır.

Sorun — Metin araması zararlı kodu bulamaz — bir eval çağrısı base64, değişken fonksiyon adı ya da string birleştirmeyle rahatça gizlenir.

Çözüm — Dosyalar PHP'nin kendi token akışı üzerinden çözümlenir; gizlenmiş çağrı, kaynakta nasıl yazıldığından bağımsız olarak görünür.

Sorun — Reklam enjeksiyonu dosyada değil veritabanında yaşar: bir option, bir gönderi içeriği ya da bir meta alanı. Dosya taraması bunu hiç görmez.

Çözüm — Option, gönderi ve meta içerikleri enjekte edilmiş markup için ayrıca taranır.

Sorun — Bir eklentinin bugün bilinen açığı olmayabilir; ama iki yıldır güncellenmiyorsa, yarın bulunacak açık için yama da gelmeyecektir.

Çözüm — Envanterdeki her eklenti ve tema için bakım sinyalleri okunur; bu bir zafiyet taraması değil, terk edilmişlik ölçümüdür.

Sorun — Önbellek anahtarına girmeyen bir başlık yanıtı etkiliyorsa, saldırganın tek isteği bütün ziyaretçilere servis edilen zehirli bir sayfa üretebilir.

Çözüm — Yanıtı değiştiren ama anahtara girmeyen girdiler denetlenir; bulunan her biri bulgu olarak yükseltilir.

Sorun — Parola sıfırlama, giriş uyarısı ve güvenlik bildirimi e-postayla gider; sunucunun kendi mail() yolu sessizce spam'e düşerse uyarı hiç ulaşmaz.

Çözüm — Giden posta kimliği doğrulanmış bir SMTP sunucusuna bağlanır ve teslimin gerçekleştiği ölçülür.

Sorun — Sertifikanın süresi dolduğunda site erişilemez hâle gelir — ve bunu genellikle önce ziyaretçiler fark eder.

Çözüm — Sertifikanın kalan ömrü, zinciri ve yenileme durumu düzenli ölçülür; süre dolmadan önce uyarılır.

Sorun — Bu üç kayıt eksikse alan adınız adına sahte e-posta göndermek serbesttir; ve bunu kendi sitenizin içinden göremezsiniz.

Çözüm — Kayıtlar dışarıdan, bağımsız bir çözücüyle okunur; eksik ya da zayıf politika somut düzeltme metniyle raporlanır.

Sorun — Yedek yarıda kesilir, tarama tamamlanmaz, yükleme başarısız olur — sebep çoğu zaman güvenlik değil, memory_limit ya da max_execution_time'dır.

Çözüm — Çalışma anındaki gerçek limitler ölçülür ve hangi işin hangi limite takıldığı açıkça yazılır.

Sorun — Doğrulanmamış bir yedek yedek değildir; çoğu yedek ilk kez geri yükleme anında denenir ve tam orada bozuk çıkar.

Çözüm — Yedek alınır ve geri yüklenebilirliği ayrıca doğrulanır; doğrulanmamış bir yedek "alındı" sayılmaz.

Sorun — Süresi dolmuş transient, eski revizyon, spam yorum ve sahipsiz meta veritabanını şişirir; şişen veritabanında her sorgu yavaşlar.

Çözüm — Bu dört sınıf düzenli olarak sayılır ve temizlenir; neyin silineceği silinmeden önce gösterilir.

Sorun — Giriş yapmış bir kullanıcının sayfası önbelleğe alınıp anonim ziyaretçiye servis edilirse, oturuma ait içerik ve bazen nonce'lar dışarı sızar.

Çözüm — Giriş yapmış isteklerin önbelleği fiilen atladığı ölçülür; atlamıyorsa bulgu yükseltilir.

Sorun — Açık yönlendirme, kendi alan adınızı kimlik avı için kullanılabilir hâle getirir; kırık bağlantılar ise hem ziyaretçiyi hem sıralamayı kaybettirir.

Çözüm — Yönlendirmeler tek yerden tanımlanır ve hedefler kısıtlanır; hiç yönlendirme tanımlı olmaması korunuyor olmakla aynı şey değildir, o yüzden bu durum ayrıca yazılır.

Sorun — wp-config.php, .git/, .env ve debug.log gibi dosyalar tarayıcıdan doğrudan istendiğinde PHP hiç çalışmaz; sunucuda kural yoksa dosya olduğu gibi verilir.

Çözüm — Hassas yolları kapatan sunucu kuralı üretilir; sunucu .htaccess okumuyorsa (nginx, LiteSpeed) eşdeğer yapılandırma elle uygulanmak üzere ekranda gösterilir ve satır yeşil sayılmaz.

Sorun — autoload işaretli option'lar her istekte belleğe okunur; eklentilerin geride bıraktığı birkaç megabayt, sitenin tamamını kalıcı olarak yavaşlatır.

Çözüm — Autoload yükü ölçülür, en ağır kalemler tek tek listelenir ve gereksiz olanlar autoload'dan çıkarılır.

Sorun — Bu eklentinin taramalarının çoğu WordPress zamanlayıcısına asılıdır ve o zamanlayıcı ziyaretçi trafiğiyle çalışır: site sessizse ya da barındırıcı DISABLE_WP_CRON koyduysa hiçbir tarama koşmaz — ekranlar "henüz taranmadı" der, operatör korunduğunu sanır.

Çözüm — Eklenti zamanlanmış işin bu sunucuda gerçekten koşup koşmadığını ölçer ve koşmuyorsa bunu sessiz bir gecikme gibi değil, adıyla söyler.

Sorun — Bir site yavaşladığında ilk şüpheli güvenlik eklentisidir ve kimse aksini gösteremez, çünkü hiçbir eklenti kendi maliyetini ölçmez.

Çözüm — Eklenti kendi maliyetini — istek başına süresini, kendi otomatik yüklenen seçeneklerini, yönetici sorgularını — ilan ettiği bütçeye karşı ölçer ve bütçeyi aştığında bunu kendisi bildirir.

Sorun — Kurulu eklentilerin CVE listesi tek başına eyleme dönüşmez: yüzlerce açığın hangisinin gerçekten istismar edildiğini söylemez.

Çözüm — Envanter, CISA KEV (fiilen istismar edilenler) ve EPSS (istismar olasılığı) ile birleştirilir; sıralama tahmine değil ölçüme dayanır.

Sorun — Yama henüz yayımlanmamışsa ya da güncelleme siteyi bozacağı için erteleniyorsa, açık kapatılana kadar açık kalır.

Çözüm — Bilinen açığın istismar biçimini kesen kural WordPress'ten önceki katmanda uygulanır; eklentinin kendi koduna dokunulmaz.

Sorun — Tek bir site, kendisine yönelen saldırının yeni bir kampanyanın parçası mı yoksa rastgele gürültü mü olduğunu bilemez.

Çözüm — İmza ve gösterge beslemeleri merkezden dağıtılır; bir sitede ölçülen yeni davranış diğerlerinde kural olarak karşılanır.

Sorun — Olay anında asıl sorun uyarı eksikliği değil, sırayı bilmemektir: neyi önce izole etmeli, neyi geri almalı, neyi kanıt olarak saklamalı.

Çözüm — Bulgular tek bir zaman çizelgesinde toplanır; izolasyon, geri alma ve kanıt saklama adımları sırasıyla yürütülür.

Sorun — NS ya da MX kaydının değişmesi, sitenin tamamının ve tüm e-postanın devredilmesi demektir — ve site bunu kendi içinden göremez.

Çözüm — NS, MX, A/AAAA, TXT ve DMARC kayıtları dışarıdan temellenir; sapma raporlanırken "çözemedim" ile "kayıt yok" birbirine karıştırılmaz.

Sorun — Site kendi içinden bakınca sağlıklı görünür; dışarıya ne sızdırdığını — açık dizin listesi, erişilebilir yedek dosyası, karışık içerik — ancak dışarıdan bakan görür.

Çözüm — Bağımsız bir konumdan başlıklar, yönlendirmeler, sunucu banner'ı ve bilinen hassas yollar ölçülür; taranmamış bir yol için "yok" denmez.

Sorun — Alan adınız için üçüncü bir tarafın sertifika çıkartması, ele geçirilmiş DNS'in ilk görünür işaretidir — ve sunucunuzda hiçbir iz bırakmaz.

Çözüm — Herkese açık CT günlükleri izlenir; tanınmayan bir kuruluş adına sertifika çıktığında uyarılır, operatörün kapattığı parmak izi bir daha sorulmaz.