WordPress güvenlik kontrol listesi: AB işletmeleri için (2026)

Bu WordPress güvenlik kontrol listesi, AB'de faaliyet gösteren her işletme sitesi için önerdiğimiz 25 önlemi altı alanda topluyor: barındırma (hosting), WordPress yazılımı, hesaplar, izleme, yedekleme ve dokümantasyon. Listeyi yukarıdan aşağıya doğru uygulayın: ilk üç grup saldırıların büyük bölümünü daha baştan önler; son üçü ise bir olayı fark etmenize, siteyi yeniden ayağa kaldırmanıza ve ne yaptığınızı kanıtlamanıza yardımcı olur.

Her maddede tek cümlelik bir gerekçe ve gerektiğinde ayrıntılı bir rehbere bağlantı bulacaksınız. Hiçbir kontrol listesi bir siteyi "%100 güvenli" hâle getiremez; ancak bu liste size bir müşteriye, bir denetçiye ya da bir denetim makamına rahatlıkla açıklayabileceğiniz bir koruma düzeyi sağlar.

Hız neden bu kadar önemli? Güvenlik şirketi Patchstack, 2025 yılında WordPress ekosisteminde 11.334 yeni güvenlik açığı saydı; bunların %91'i eklentilerdeydi. Aynı rapora göre yüksek etkili açıkların yaklaşık yarısı 24 saat içinde istismar edildi (Patchstack, State of WordPress Security in 2026; bir üretici raporu). Tek bir araçtan çok, düzenli bir rutin işe yarar.

Barındırma ve sunucu

Sunucu zayıfsa, WordPress içinde yaptığınız hiçbir ayar bu eksikliği tam olarak telafi edemez.

• Her sayfada HTTPS, ardından HSTS. HTTPS; girişleri, form kayıtlarını ve siparişleri aktarım sırasında şifreler. GDPR (AB Genel Veri Koruma Tüzüğü) de Md. 32(1)(a) hükmünde şifrelemeyi açıkça anar. HSTS'yi (RFC 6797) ancak HTTPS her yerde sorunsuz çalıştığında ve kısa bir max-age değeriyle başlayarak ekleyin: tarayıcılar bu süre boyunca düz HTTP bağlantılarını reddeder.
• Desteklenen bir PHP sürümü. Desteği sona ermiş PHP sürümleri artık güvenlik düzeltmesi almaz; kendi sürümünüzü resmî listeyle karşılaştırın.
• FTP yerine SFTP veya SSH ve her site için ayrı, yalıtılmış bir hesap. FTP parolaları şifrelemeden gönderir. Yalıtım olmadığında da ele geçirilen tek bir site, aynı hesaptaki diğer bütün siteleri enfekte edebilir.
• Uploads klasöründe PHP çalıştırılmasın. Yükleme klasöründe yalnızca medya dosyaları bulunmalıdır; orada bir PHP dosyası görüyorsanız bu neredeyse her zaman bir web shell'dir.

Apache 2.4 kullanıyorsanız aşağıdaki satırları wp-content/uploads/.htaccess dosyasına ekleyin:

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

nginx'te ise bu bloğu server bloğuna, genel location ~ \.php$ bloğunuzun üstüne ekleyin (eşleşen ilk regex location bloğu geçerli olur):

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ {
    deny all;
}

Yapılandırmayı yeniden yüklemeden önce nginx ayarlarını nginx -t ile test edin. Hangi sunucuyu kullanırsanız kullanın, ardından görsellerin hâlâ yüklendiğini ve uploads klasörüne koyduğunuz bir test .php dosyasının "403 Forbidden" yanıtı döndürdüğünü kontrol edin.

WordPress çekirdeği, eklentiler ve temalar

Güvenlik açıklarının çoğu eklentilerde ortaya çıktığı için bu grup haftalık bir rutin gerektirir. Açık barındıran WordPress eklentileri rehberimiz konuyu daha ayrıntılı ele alıyor.

• Çekirdeğin otomatik güvenlik güncellemelerini açık tutun. WordPress, güvenlik düzeltmelerini içeren küçük sürümleri varsayılan olarak arka planda kurar. Hiçbir ayarın ya da barındırma aracının bu özelliği kapatmadığından emin olun.
• Eklenti ve temaları aylar içinde değil, günler içinde güncelleyin. Patchstack, yoğun biçimde istismar edilen açıklarda kitlesel istismara kadar geçen ağırlıklı medyan süreyi beş saat olarak ölçtü. WordPress 5.5'ten beri sunulan otomatik güncellemeler, düşük riskli eklentilerde aradaki bu farkı kapatmaya yardımcı olur.
• Kullanmadığınız her şeyi silin. Devre dışı bırakılan bir eklentinin dosyaları sunucuda kalmaya devam eder ve hâlâ istismar edilebilir; wp plugin list --status=inactive komutu silinebilecek adayları listeler.
• Terk edilmiş eklentileri değiştirin, "nulled" kopyaları asla kullanmayın. Patchstack verilerine göre açıkların %46'sı kamuya duyurulduğu anda henüz düzeltilmemişti. Terk edilmiş bir eklenti hiçbir zaman düzeltme almayabilir; korsan bir kopya ise hiç güncelleme almaz.
• Yönetim panelindeki dosya düzenleyiciyi kapatın. wp-config.php dosyasına eklenen define( 'DISALLOW_FILE_EDIT', true ); satırı tema ve eklenti dosya düzenleyicilerini kaldırır. Böylece çalınmış bir yönetici hesabıyla bir tema dosyasına kolayca kod yapıştırılamaz.

Hesaplar ve girişler

Bir yönetici eklenti kurabilir; bu da sunucunuzda kod çalıştırabileceği anlamına gelir. WordPress'in varsayılan rolleri (Administrator, Editor, Author, Contributor, Subscriber) en az yetki ilkesini uygulamayı kolaylaştırır.

• Her Administrator ve Editor hesabı için benzersiz parola ve iki faktörlü kimlik doğrulama. Credential stuffing saldırıları tam da sızdırılmış ve tekrar kullanılan parolaları dener. WordPress çekirdeğinde yerleşik 2FA yoktur; seçenekleri iki faktörlü kimlik doğrulama rehberimizde bulabilirsiniz.
• Her kişiye kendi hesabı ve işini görecek en düşük rol. Ortak kullanılan "ajans" hesapları kimin ne yaptığını gizler ve temiz bir şekilde iptal edilemez.
• Eski hesapları ve kullanılmayan uygulama parolalarını kaldırın. Eski çalışanlar ve ajanslar, biri erişimlerini silene kadar sisteme girmeye devam edebilir. Uygulama parolaları (Application Passwords, WordPress 5.6'dan beri) her kullanıcının profil sayfasında listelenir.
• Giriş denemelerini sınırlayın, kullanılmıyorsa XML-RPC'yi kapatın. XML-RPC varsayılan olarak açıktır ve normal giriş formunun dışında da parola kabul eder. Kapatmadan önce bir eklentinin ya da uygulamanın ona hâlâ ihtiyaç duyup duymadığını kontrol edin.

İzleme ve tespit

72 saatlik bildirim süresine ancak ihlali zamanında fark ederseniz uyabilirsiniz.

• Zamanlanmış zararlı yazılım ve dosya bütünlüğü taramaları. Uploads klasöründe beliren yeni PHP dosyaları, değiştirilmiş çekirdek dosyaları ve gizlenmiş (obfuscated) kod, bir saldırının tipik izleridir. wp core verify-checksums komutu çekirdek dosyalarını WordPress.org'un resmî sağlama toplamlarıyla karşılaştırır. Ayrıca bkz. Sitenizin hacklendiğini gösteren 12 işaret.
• Etkinlik kayıtları ve yeni yöneticiler için uyarılar. Gizli yönetici hesapları, saldırganların erişimi elde tutmak için sık başvurduğu bir yöntemdir. Kayıtlar bir olayı sonradan adım adım yeniden kurmanıza yardımcı olur; IP adresleri içerdikleri için bir saklama süresi belirleyin.
• Gerçekten kullandığınız eklentiler için güvenlik açığı uyarıları. WPScan veya Patchstack gibi bir güvenlik açığı veritabanı, eklentilerinizden birinde bilinen bir sorun olduğunda size haber verir.
• Google Search Console ve erişilebilirlik (uptime) izleme. Search Console, Google'ın sitenizde tespit ettiği enjekte edilmiş spam gibi güvenlik sorunlarını bildirir; uptime kontrolleri ise kesintileri yakalar.

secaudit.eu tarafından geliştirilen Security Audit & Compliance eklentisi bu kontrollerin bir kısmını otomatik hâle getirir: dosya bütünlüğü, zararlı yazılım imzaları, gizli yöneticiler, güncel olmayan eklentiler, zayıf parolalar ve sıkılaştırma ayarları. Eklenti, bulgularını GDPR Md. 32 ve NIS2 Direktifi Md. 21 ile eşleştirir.

Yedekleme ve kurtarma

GDPR Md. 32(1)(c), bir olayın ardından kişisel verilerin erişilebilirliğini ve bunlara erişimi zamanında geri sağlama yeteneği ister. Bu sözü ancak test edilmiş yedekler tutabilir.

• Dosyaların ve veritabanının otomatik yedeği; aktif sitelerde en az günde bir kez. Siparişler ve form kayıtları her gün değişir; bir haftalık yedek bunları kaybettirir.
• En az bir kopya sunucunun dışında ve saldırganın ulaşamayacağı bir yerde. Web kök dizininde duran bir yedek arşivini, adını tahmin eden herkes indirebilir. Sitenin kendisinin silebildiği bir yedeği saldırgan da silebilir.
• Yılda en az iki kez geri yükleme testi yapın. Hiç geri yüklemediğiniz bir yedek bir plan değil, bir umuttur; Md. 32(1)(d) de önlemlerinizi düzenli olarak test etmenizi ister.
• Tek sayfalık bir olay müdahale planı. Kim karar veriyor, barındırma firmasını kim arıyor, temiz yedekler nerede duruyor ve bir veri ihlali 72 saat içinde nasıl bildirilir? Temizlik kısmını zararlı yazılım temizleme planımız anlatıyor.

Dokümantasyon ve uyumluluk

GDPR Md. 5(2) uyarınca aldığınız önlemleri kanıtlayabilmeniz gerekir. Bunun için kısa ve tarihli kayıtlar yeterlidir.

• Eklentilerin, temaların, harici hizmetlerin ve erişimlerin envanteri. Varlığından haberdar olmadığınız bir şeyi ne yamayabilir ne de gözden geçirebilirsiniz. Google'ın sunucularından yüklenen Google Fonts gibi üçüncü taraf istekleri de bu listeye girer.
• Barındırma firmanız ve ajansınızla veri işleme sözleşmeleri. Sizin adınıza kişisel veri işleyen herkesin, yönetici erişimi olan bir ajans da dahil, GDPR Md. 28 uyarınca böyle bir sözleşmeye ihtiyacı vardır.
• Bir ihlal ve olay kaydı. Md. 33(5), bildirmek zorunda olmadıklarınız da dahil olmak üzere her kişisel veri ihlalini belgelemenizi ister.
• Tarihli kanıtlar, yılda en az bir kez gözden geçirilmiş olarak. Güncelleme kayıtları, tarama raporları ve geri yükleme testleri, önlemlerinizin gerçekten işe yaradığını gösterir.

Bu WordPress güvenlik kontrol listesi GDPR ve NIS2 ile nasıl eşleşir?

GDPR Md. 32(1), teknolojinin son durumu, uygulama maliyetleri ve risk dikkate alınarak uygun teknik ve organizasyonel tedbirlerin alınmasını şart koşar. NIS2 Md. 21(2) ise kapsamındaki kuruluşlar için on asgari önlem sayar.

NIS2 esas olarak listelenen sektörlerdeki orta ve büyük ölçekli şirketleri kapsar ve ayrıntılar ülkeden ülkeye değişir; bu yüzden ülkenizin ulusal NIS2 yasasını mutlaka kontrol edin. Daha küçük tedarikçiler de dolaylı olarak etkilenir, çünkü kapsamdaki kuruluşlar tedarik zinciri güvenliğini yönetmek ve tedarikçilerinden kanıt istemek zorundadır. Ayrıntılar için GDPR Md. 32 ve NIS2 kapsamı hakkındaki yazılarımıza göz atın. Eklenti ya da tema satıyorsanız, Siber Dayanıklılık Yasası (CRA) size ayrıca üretici yükümlülükleri getirir.

Sık sorulan sorular

Bu kontrol listesini ne sıklıkla gözden geçirmeliyim?

Listenin tamamını en az yılda bir kez ve yeni bir barındırma firması ya da ajans gibi büyük değişikliklerden sonra baştan sona gözden geçirmenizi öneririz.

Kontrol listesini tamamlamak sitemi GDPR'a uygun hâle getirir mi?

Hiçbir kontrol listesi bunu tek başına sağlayamaz. Md. 32 risk temellidir: müşteri hesapları olan bir mağaza, basit bir tanıtım sitesinden daha fazlasına ihtiyaç duyar. Kontrol listesi teknik temeli kapsar; dokümantasyonunuz ise bu temelin neden sizin riskinize uygun olduğunu açıklar.

Sadece küçük bir tanıtım sitemiz var. Bu liste bizim için de geçerli mi?

Büyük ölçüde evet. Otomatik saldırılar şirketin büyüklüğüne bakmaz; bir iletişim formu kişisel veri toplamaya başladığı anda GDPR de devreye girer.

Bu makale genel bilgi niteliğindedir, hukuki danışmanlık değildir.