WordPress Güvenlik Rehberi 2026: A'dan Z'ye Koruma

WordPress Güvenliğinde Temel Yanılgılar

WordPress güvenlik rehberi arayışına girdiğinizde karşınıza çıkan ilk tavsiye genelde “şu güvenlik eklentisini kurun ve arkanıza yaslanın” olur. Oysa dijital güvenlik dünyasında durum bundan çok daha karmaşıktır. Patchstack 2024 güvenlik raporuna göre, WordPress ekosisteminde tespit edilen 7,966 yeni güvenlik açığının %96’sı üçüncü parti eklentilerden, %4’ü temalardan kaynaklanmıştır. WordPress çekirdeğinde (Core) ise sadece 7 adet açık tespit edilmiştir. Bir başka deyişle, sitenizi korumak için yüklediğiniz kod parçaları aslında sizin en büyük güvenlik riskinizi oluşturmaktadır.

Bu rehberde, “eklenti yükle ve unut” mantığından uzaklaşıp, WordPress çekirdeğini dışarıdan gelecek saldırılara karşı katmanlı bir savunma (Defense in Depth) stratejisiyle nasıl koruyacağınızı adım adım anlatıyoruz. Wordfence CEO’su Mark Maunder’ın da belirttiği gibi, “Bir hacker’ın sadece bir kez haklı olması yeterliyken, sizin her defasında haklı olmanız gerekir.” Bu yüzden hedefimiz, hacker’ların o “bir kez” haklı olma ihtimalini matematiksel olarak sıfıra yaklaştırmaktır.

1. Eklenti Ekosisteminin Yarattığı Tehlikeler

WordPress sitelerinin güvenlik zafiyetlerinin temel nedeni çekirdek yazılımın kendisi değildir. WordPress Core yazılımı oldukça güvenlidir ve yüzlerce profesyonel geliştirici tarafından sürekli olarak denetlenmektedir. Ancak, sisteme eklenen her yeni eklenti ve her yeni kod bloğu, sitenizin saldırı yüzeyini (attack surface) dramatik bir şekilde genişletir.

Zafiyetlerin Anatomisi: XSS ve SQL Injection

2024 yılında keşfedilen açıkların büyük bir çoğunluğu, yaklaşık %47.6’sı, Cross-Site Scripting (XSS) kaynaklıydı. Bunu Broken Access Control (hatalı yetki kontrolü) ve SQL Injection açıkları izledi. Daha da tehlikelisi, tespit edilen bu açıkların %43’ü hiçbir yönetici yetkisi veya kimlik doğrulama adımı olmadan tamamen uzaktan sömürülebiliyordu.

Peki bu noktada ne yapılmalı?

• Kullanılmayan eklentileri kalıcı olarak silin: Pasif durumda (deaktif) bekleyen eklentiler bile sunucuda barındığı sürece çalıştırılabilir dosya riskleri taşımaya devam eder. Sitenizde kullanmadığınız her eklentiyi sadece pasif konuma almakla yetinmeyin, dosyalarıyla birlikte tamamen silin.
• Kodla çözülebilecek basit işler için eklenti kurmayın: Örneğin Google Analytics kodunu eklemek, ufak bir CSS düzenlemesi yapmak veya yönlendirme (redirect) sağlamak için devasa eklentilere ihtiyacınız yoktur. Temanızın functions.php dosyası veya .htaccess üzerinden bu işleri çok daha güvenli ve hızlı bir şekilde çözebilirsiniz.
• Yalnızca saygın geliştiricilerden eklenti alın: Resmi WordPress deposunda (repository) yer alsa bile, uzun süredir güncellenmeyen, destek taleplerine yanıt verilmeyen eklentileri kullanmaktan kesinlikle kaçının.

2. wp-config.php ve Hassas Dosya Korumaları

wp-config.php, WordPress sitenizin kalbidir. Veritabanı kullanıcı adınız, veritabanı şifreniz, veritabanı sunucu adresiniz ve kritik güvenlik anahtarlarınız (salt keys) burada yer alır. Bu dosyanın dışarıdan okunmasını, indirilmesini veya değiştirilmesini engellemek birincil güvenlik önceliğidir.

Apache (.htaccess) ile Dosya Koruması

Eğer Apache sunucu mimarisi kullanıyorsanız, public_html dizininde yer alan .htaccess dosyanıza şu kuralları ekleyerek wp-config.php dosyasına olan tüm dış erişimi kapatabilirsiniz:

<files wp-config.php>
order allow,deny
deny from all
</files>

Nginx ile Erişim Kısıtlamaları

Sunucunuz Nginx altyapısına sahipse, .htaccess dosyası çalışmayacaktır. Bunun yerine, Nginx konfigürasyon (server block) dosyanıza aşağıdaki satırları ekleyerek koruma sağlayabilirsiniz:

location ~* wp-config.php {
    deny all;
}

wp-config.php Dosyasını Bir Üst Dizine Taşımak

Varsayılan olarak wp-config.php dosyası WordPress kök dizininde yer alır. WordPress’in kendi mimarisi, wp-config.php dosyasını bir üst dizinden de otomatik olarak okuyabilecek şekilde tasarlanmıştır. Örneğin siteniz /var/www/html/ klasöründeyse, wp-config.php dosyanızı /var/www/ klasörüne taşıyabilirsiniz. Böylece bir saldırgan web klasörünün dışına çıkamayacağı için bu hayati dosyaya ulaşması fiziksel olarak imkansız hale gelir.

3. XML-RPC Saldırılarını Kökten Durdurmak

xmlrpc.php, eskiden WordPress’in mobil uygulamalar, pingback mekanizmaları veya dış servislerle haberleşmesi için olmazsa olmaz bir protokoldü. Ancak WordPress’in WP-REST-API mimarisine geçiş yapmasıyla birlikte XML-RPC aslında tarihe karıştı. Buna rağmen, geriye dönük uyumluluk adına hala varsayılan olarak açık gelir.

DDoS ve Brute-Force Saldırılarında XML-RPC Rolü

Açık bırakılan bir XML-RPC dosyası, hacker’lar için kaba kuvvet (brute-force) saldırıları ve DDoS atakları için mükemmel bir arka kapı görevi görür. Çünkü XML-RPC üzerinden tek bir HTTP isteği ile yüzlerce farklı şifre denemesi aynı anda yapılabilir. Bu da saldırganların çok az kaynak harcayarak sunucunuzu felç etmesini sağlar.

XML-RPC’yi Güvenle Kapatma Yolları

XML-RPC’yi kapatmak için temanızın functions.php dosyasına şu satırı ekleyebilirsiniz:

add_filter('xmlrpc_enabled', '__return_false');

Ancak bu yöntem dosyaya gelen istekleri en başta engellemez, WordPress yüklendikten sonra engeller. Bu yüzden yine de sunucu kaynağı tüketilmiş olur. En kesin çözüm sunucu seviyesinde tamamen erişime kapatmaktır. Nginx için:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

Apache (.htaccess) için:

<files xmlrpc.php>
order deny,allow
deny from all
</files>

4. Yönetici Paneli (wp-admin) Güvenliği

Otomatize edilmiş bot saldırıları genellikle sitenizin standart wp-admin dizinini veya wp-login.php dosyasını hedefe oturtur. Bu saldırıları boşa çıkarmanın ve sunucu yükünü azaltmanın en kolay yolu, giriş yolunu maskelemek ve kimlik doğrulama süreçlerini sertleştirmektir.

İki Aşamalı Kimlik Doğrulama (2FA)

Artık sadece karmaşık bir şifreye sahip olmak hacker’ları durdurmaya yetmemektedir. Kimlik avı (phishing) veya zararlı yazılımlar şifrenizi çalabilir. Yönetici hesapları başta olmak üzere tüm yetkili hesaplar için Google Authenticator veya benzeri bir Time-based (TOTP) uygulama ile 2FA (İki Aşamalı Kimlik Doğrulama) zorunluluğu getirmelisiniz.

wp-admin Dizinine IP Kısıtlaması (Allow/Deny)

Eğer WordPress sitenize giriş yapan kişi veya ekip sabit IP adreslerine sahipse, yönetici panelini tüm dünyaya açmanızın hiçbir mantığı yoktur. .htaccess üzerinden sadece belirlediğiniz IP adreslerine izin verebilirsiniz:

<ifmodule mod_rewrite.c>
rewriteengine on
rewritecond %{request_uri} ^(.*)?wp-login\.php(.*)$ [or]
rewritecond %{request_uri} ^(.*)?wp-admin$
rewritecond %{remote_addr} !^123\.456\.789\.000$
rewriterule ^(.*)$ - [r=403,l]
</ifmodule>

(Yukarıdaki IP adresini kendi statik IP adresinizle değiştirmeniz gerekmektedir.)

5. Dosya İzinleri ve chown / chmod Ayarları

Güvenlik açıklarının en çok suistimal edildiği noktalardan biri de sunucudaki yanlış dosya izinleridir (file permissions). WordPress klasörlerinin “777” iznine sahip olması demek, sunucuya erişebilen herkesin o klasörlere dilediği zararlı dosyayı (shell, backdoor) yazabilmesi demektir.

WordPress İçin İdeal chmod Değerleri

Güvenli bir Linux/Unix sunucusunda dosya izinleri katı bir şekilde ayarlanmalıdır:

• Tüm klasörler (directories): 755 (veya daha katı isteniyorsa 750)
• Tüm dosyalar (files): 644 (veya 640)
• wp-config.php: Çok daha katı bir şekilde 440 veya 400 olmalıdır (Sadece okuma yetkisi).

Dosya izinlerini SSH üzerinden topluca düzenlemek için şu komutları kullanabilirsiniz:

find /path/to/your/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/your/wordpress/ -type f -exec chmod 644 {} \;

6. Veritabanı Tablo Ön Ekini Değiştirmek

WordPress kurulumu standart bir şekilde yapıldığında veritabanı tabloları varsayılan olarak wp_ ön eki (prefix) ile oluşturulur. Bu durum, olası bir SQL Injection saldırısında hacker’ların tablolarınızın tam adını doğrudan bilmesi anlamına gelir.

SQL Injection Riskini Düşürmek

Güvenli bir altyapıda, kurulum anında bu ön ek wp_x7k9m2_ gibi karmaşık ve rastgele bir diziye dönüştürülmelidir. Halihazırda canlıda çalışan ve veri dolu bir sitede tablo ön ekini değiştirmek manuel olarak riskli olabilir. Ancak veritabanı yedeği kesinlikle alındıktan sonra, bu işlem WP-CLI komutları aracılığıyla komut satırından hatasız bir şekilde gerçekleştirilebilir.

7. Katmanlı Güvenlik (Defense in Depth) ve WAF Kullanımı

Sadece tek bir koruma katmanına, örneğin sadece iyi bir şifreye veya sadece gizli bir login URL’sine güvenmek ölümcül bir hatadır. Sitenizin güvenliği iç içe geçmiş katmanlardan (Defense in Depth) oluşmalıdır.

WAF (Web Application Firewall) Nedir?

1. Sunucu Seviyesi (DNS/WAF): Cloudflare gibi profesyonel bir Web Application Firewall (WAF) kullanarak kötü niyetli botları, DDoS ataklarını ve SQL Injection denemelerini sitenize hiç ulaşmadan, DNS seviyesinde durdurun.
2. Uygulama Seviyesi (WordPress Core): Güçlü şifreler, 2FA, XML-RPC kapatma, IP bazlı kısıtlamalar.
3. Yazılım Seviyesi (Eklentiler/Temalar): Düzenli güncellemeler ve güvenlik bültenlerinin aktif takibi.

Patchstack CEO’su Oliver Sild’in dediği gibi: “Güvenlikte hız her şeydir. Yalnızca bildiğiniz şeyi koruyabilirsiniz.” Yeni keşfedilen açıkları tespit edebilen ve anında sanal yamalama (virtual patching) yapabilen bir güvenlik sisteminin arka planda çalışması, özellikle e-ticaret siteleri için hayati önem taşır.

8. SSL, TLS ve HTTP Security Header Kullanımları

Sitenizin HTTPS üzerinden çalışması artık bir seçenek değil zorunluluktur. Ancak sadece SSL sertifikası kurmak yeterli değildir. Trafiği dinlemek isteyenlere (Man-in-the-Middle) karşı ek korumalar için HTTP Güvenlik Başlıklarını (Security Headers) aktif etmelisiniz.

• Strict-Transport-Security (HSTS): Tarayıcıların sitenize sadece HTTPS üzerinden bağlanmasını zorunlu kılar.
• X-Frame-Options: Sitenizin başka bir sitede iframe içinde açılmasını engelleyerek Clickjacking saldırılarını durdurur.
• Content-Security-Policy (CSP): Hangi kaynaklardan CSS, JS veya resim yüklenebileceğini beyaz liste ile belirleyerek XSS saldırılarının çalışmasını engeller.

Sonuç ve Eylem Planı

WordPress güvenliği, bir hafta sonu mesaisi ile çözülüp bir daha bakılmayacak bir işlem değil, aksine sürekli gözlem ve proaktif müdahale gerektiren dinamik bir süreçtir. Her yeni eklenti sitenizde yeni bir kapı açar ve kodu yazan kişinin insafına kalmanıza neden olur. Sisteminizde sadece işinizi görecek en temel eklentileri barındırarak, varsayılan yolları (XML-RPC, wp-admin) kapatarak ve Cloudflare gibi bir WAF üzerinden trafiğinizi süzerek gelebilecek saldırıların neredeyse %99’unu kapıda durdurabilirsiniz.

Siteniz eğer çoktan siber saldırıya uğradıysa veya zararlı kod içeriyorsa kesinlikle paniğe kapılmayın. WordPress hacklendi sorun sayfamızı inceleyerek profesyonel bir kurtarma ve temizleme planı için gerekli adımları öğrenebilir veya bizimle iletişime geçerek acil müdahale gerektiren sorun çözümü hizmetlerimizle anında tanışabilirsiniz.