403 Forbidden Hatası Nedir, Erişim Neden Engelleniyor?

Dün sorunsuz açılan siteniz bugün karşınıza "403 Forbidden — You don't have permission to access this resource" yazan boş bir sayfayla çıktı. Belki de yalnızca yönetim paneline giremiyorsunuz, belki bir form gönderdiğinizde erişim engelleniyor, belki de siteyi başkaları görüyor ama siz göremiyorsunuz. 403 Forbidden hatası, 404'ten farklı olarak "böyle bir şey yok" demez; "var, ama sana kapalı" der. Yani sunucu kaynağı bulmuştur, isteği anlamıştır ve bilinçli olarak reddetmiştir.

Türkçe kaynakların ortak reçetesi burada tek satırdır: "dosya izinlerini 644, klasörleri 755 yapın." Bu doğru bir tavsiyedir ama pratikte gördüğüm 403'lerin küçük bir azınlığını açıklar. Asıl sebepler genelde başka yerdedir: cPanel IP Engelleyici'ye takılmış kendi IP'niz, cPHulk'un başarısız giriş denemeleri sonrası koyduğu geçici blok, tetiklenen bir ModSecurity kuralı ya da dizin listeleme kapalıyken index dosyasının bulunmaması. Bu yazıda 403'ü üreten beş ayrı katmanı tek tek ayırıyoruz ve en önemlisi: ModSecurity log satırından hangi kuralın tetiklendiğini okumayı öğreteceğiz — çünkü doğru kural numarasını bilmeden yapılan her müdahale ya işe yaramaz ya da güvenliğinizi gereksiz yere zayıflatır.

403 Forbidden Hatası Ne Anlama Geliyor#

403, HTTP'nin istemci hataları sınıfındadır (4xx) ve tanımı nettir: sunucu isteği anladı, ama yetkilendirmeyi reddediyor.

Yakın kodlarla karıştırmamak için ayrımlar:

403 ile 429 arasındaki fark özellikle önemlidir, çünkü bazı güvenlik duvarları hız sınırını 429 yerine 403 ile uygular. Sayfayı yenilediğinizde bazen açılıp bazen 403 veriyorsa, büyük ihtimalle bir hız sınırına takılıyorsunuzdur.

Hatayı kimin ürettiğini anlamanın hızlı yolu, yanıt gövdesine ve başlıklara bakmaktır:

curl -sSI https://ornek-siteniz.com/wp-admin/

HTTP/2 403
server: Apache
content-type: text/html; charset=iso-8859-1

Yanıt gövdesi Apache'nin sade "Forbidden" sayfasıysa engelleme sunucu katmanındadır. WordPress'in kendi temasıyla giydirilmiş bir "erişim reddedildi" sayfası görüyorsanız engelleme uygulama katmanındadır — yani bir güvenlik eklentisi. Cloudflare markalı bir sayfa görüyorsanız istek sunucunuza hiç ulaşmamıştır.

403'ü Üreten Beş Farklı Katman#

Bir istek, sunucuya ulaşana kadar birçok kapıdan geçer ve her kapı 403 üretebilir. Doğru kapıyı bulmak, çözümün kendisidir.

Teşhisi hızlandıran tek soru şudur: "Bu 403'ü herkes mi alıyor, yoksa sadece ben mi?"

Bunu kesinleştirmek için siteyi mobil veriyle (farklı IP) açmayı deneyin ya da bir tarayıcı gizli sekmesi yerine gerçekten farklı bir ağ kullanın. Sadece siz 403 alıyorsanız neredeyse kesinlikle bir IP engeli vardır ve dosya izinleriyle uğraşmak boşa zamandır. Herkes alıyorsa sorun izinlerde, .htaccess'te veya sunucu yapılandırmasındadır.

Katman 1: Dosya ve Dizin İzinleri#

Web sunucusunun bir dosyayı sunabilmesi için onu okuyabilmesi, bir dizine girebilmesi için o dizinde çalıştırma (execute) hakkına sahip olması gerekir. Doğru standart değerler şunlardır:

En sık yapılan hata, dizinlere 644 verilmesidir. 644 dizin için çalıştırma hakkı taşımaz; sunucu o dizine giremez ve içindeki her şey 403 döner. Tersine 777 vermek de yanlıştır — çoğu sunucu güvenlik nedeniyle grup veya diğerlerine yazma hakkı olan dizinleri kasten reddeder ve yine 403 üretir. Yani "izin sorununu 777 ile çözmek" çoğu zaman sorunu büyütür.

Mevcut durumu görün:

ls -la ~/public_html | head -20
stat -c "%a %n" ~/public_html/wp-content

Toplu düzeltme (kök dizinde çalıştırın, dikkatli olun):

find ~/public_html -type d -exec chmod 755 {} \;
find ~/public_html -type f -exec chmod 644 {} \;
chmod 600 ~/public_html/wp-config.php

Sahiplik de en az izinler kadar önemlidir. Dosyayı FTP ile bir kullanıcı, PHP ile başka bir kullanıcı yazdıysa sahiplik karışır:

ls -la ~/public_html/wp-content/uploads
chown -R kullaniciadi:kullaniciadi ~/public_html

Paylaşımlı hostingde chown genelde çalışmaz; sahiplik sorunlarını hosting sağlayıcınız düzeltir. İzin bitlerinin mantığını derinlemesine anlamak için linux dosya izinleri yazısına bakabilirsiniz.

Katman 2: Dizin Listeleme Kapalı ve index Dosyası Yok#

Bu, teknik olarak hiç arıza olmayan ama en çok panik yaratan 403 türüdür.

Bir klasörün adresine gittiğinizde (https://ornek-siteniz.com/belgeler/) sunucu önce o klasörde bir dizin dosyası arar: index.html, index.php, default.html gibi. Bulursa onu gösterir. Bulamazsa iki seçeneği vardır:

• Dizin listeleme açıksa: klasördeki dosyaları liste hâlinde gösterir.
• Dizin listeleme kapalıysa (varsayılan ve doğru olan): 403 Forbidden döndürür.

Yani /belgeler/ adresinde 403 alıp /belgeler/rapor.pdf adresinde dosyayı indirebiliyorsanız, ortada hata yoktur — sunucu sizi doğru şekilde korumaktadır.

Bu davranışı .htaccess ile yönetirsiniz:

# Dizin listelemeyi kapat (güvenli, önerilen)
Options -Indexes

# Belirli bir klasörde açmak isterseniz o klasörün .htaccess dosyasına:
Options +Indexes

cPanel'de bunun görsel karşılığı Dizin Gizliliği / Index Manager ekranıdır; klasör bazında listeleme davranışını oradan seçebilirsiniz.

Asıl tehlikeli senaryo şudur: sitenizin ana sayfası 403 veriyorsa, kök dizinde bir index.php veya index.html dosyası yok demektir. Bu genellikle yanlış bir taşıma işleminden (dosyalar public_html yerine alt bir klasöre yüklenmiş) veya bir malware temizliğinden sonra index.php'nin silinmesinden kaynaklanır. Önce kök dizini kontrol edin:

ls -la ~/public_html/index.*

Boş dönüyorsa dosya gerçekten yoktur; yedekten geri getirmeniz gerekir.

Katman 3: .htaccess Kuralları#

.htaccess, Apache'nin dizin bazlı yapılandırma dosyasıdır ve 403'ün en gizli kaynaklarından biridir — çünkü alt dizinlerdeki .htaccess dosyaları da devrededir ve çoğu kişi yalnızca kök dizindekine bakar.

403 üreten yaygın .htaccess kalıpları:

# Tüm erişimi reddet
Require all denied

# Eski sözdizimi
Order allow,deny
Deny from all

# Belirli dosya tiplerini engelle
<FilesMatch "\.(sql|log|bak|env)$">
    Require all denied
</FilesMatch>

# Belirli bir IP'yi engelle
<RequireAll>
    Require all granted
    Require not ip 203.0.113.44
</RequireAll>

Bunlardan biri istemeden geniş bir kapsama uygulanmışsa site komple 403 verir. Test yöntemi kesindir: .htaccess dosyasını silmeyin, yeniden adlandırın.

cd ~/public_html
mv .htaccess .htaccess.yedek

Siteyi yenileyin.

• Site açıldıysa suçlu .htaccess'tir. Dosyayı geri getirin (mv .htaccess.yedek .htaccess) ve kuralları blok blok yorum satırına alarak hangisinin engellediğini daraltın.
• Site hâlâ 403 veriyorsa suçlu başka katmandadır; devam edin.

⚠️ WordPress kullanıyorsanız .htaccess'i geri getirdikten sonra Ayarlar → Kalıcı Bağlantılar ekranını açıp Değişiklikleri Kaydet'e basın; WordPress kendi yönlendirme kurallarını yeniden yazar. Aksi halde iç sayfalar 404 vermeye başlar.

Alt dizinleri de taramayı unutmayın:

find ~/public_html -name ".htaccess" -exec echo "--- {} ---" \; -exec cat {} \;

Bu komut, sitedeki tüm .htaccess dosyalarını içerikleriyle listeler; unutulmuş bir alt dizin kuralını bulmanın en hızlı yoludur.

.htaccess kaynaklı bir 403'ün yakın akrabası, dizin parola korumasıdır: bir klasöre parola koyduysanız ve .htpasswd dosyasının yolu yanlışsa Apache 401 yerine 403 döndürebilir. Bu durumda AuthUserFile satırındaki mutlak yolun gerçekten var olduğunu doğrulayın.

Katman 4: IP Engeli — cPanel IP Engelleyici ve cPHulk#

Siteyi başkaları görüyor ama siz göremiyorsanız, buradasınız. Bu, Türkçe 403 içeriklerinde neredeyse hiç geçmeyen ama sahada en sık karşılaştığım senaryodur.

Önce kendi genel IP'nizi öğrenin — yerel ağ IP'niz (192.168.x.x) işe yaramaz. Kendi sunucunuza SSH ile bağlanabiliyorsanız:

who am i
last -i -n 5

Kontrol edilecek üç yer var:

1. cPanel → IP Engelleyici (IP Blocker)

Buradaki listeyi tek tek gözden geçirin. Geçmişte bir bot saldırısı sırasında geniş bir aralık (203.0.113.0/24 gibi) engellenmişse ve operatörünüz size o havuzdan yeni bir IP verdiyse, kendi kendinizi engellemiş olursunuz. Bu, dinamik IP kullanan işletmelerde şaşırtıcı derecede yaygındır. Ekranın kullanımı cpanel ip engelleyici yazısında.

2. WHM → cPHulk Brute Force Protection

cPHulk, art arda başarısız giriş denemelerinden sonra IP'nizi geçici olarak kilitler. Yanlış parolayla birkaç kez cPanel'e veya webmail'e girmeye çalışmak yeterlidir. Kilitlenen IP'ler Blacklist Management ve History Reports sekmelerinde görünür. Kendi IP'nizi kalıcı olarak beyaz listeye almak, bu sorunu bir daha yaşamamanın yoludur:

WHM → cPHulk Brute Force Protection → Whitelist Management → IP'nizi ekleyin.

Ayrıntılar için whm güvenlik cphulk yazısına bakın.

3. Sunucu güvenlik duvarı (CSF / firewalld / Imunify)

Kendi sunucunuzda CSF varsa engeli şu komutla görürsünüz:

csf -g 203.0.113.44

Çıktı, IP'nin hangi kural ve hangi sebeple engellendiğini gösterir. Kaldırmak için:

csf -dr 203.0.113.44
csf -a 203.0.113.44 "ofis IP - kalici izin"

Imunify360 gibi bir koruma katmanı kullanıyorsanız engeller kendi panelinden yönetilir. Bu üçünü de temizlediğiniz hâlde 403 devam ediyorsa, engel muhtemelen sunucuya ait değil, önündeki bir WAF/CDN katmanına aittir.

Katman 5: ModSecurity — Log Satırından Kuralı Okumak#

İşte Türkçe kaynaklarda gerçekten eksik olan bölüm. ModSecurity, Apache/LiteSpeed önünde çalışan bir web uygulama güvenlik duvarıdır. İsteğinizin içeriğini kurallara karşı tarar ve şüpheli bulduğunda 403 ile keser. Sorun şu ki meşru içerik de sık sık şüpheli görünür: içinde SQL benzeri kelime geçen bir blog yazısı, <script> etiketi içeren bir tema ayarı, uzun bir base64 dizesi taşıyan bir form alanı.

Belirtisi çok tipiktir: site normal çalışır, sadece bir işlemi yapınca 403 gelir. Yazı kaydederken, ürün eklerken, ayar formunu gönderirken, dosya yüklerken.

Teşhis, tek bir log satırından geçer. Kendi sunucunuzda:

tail -f /var/log/modsec_audit.log

Hatayı tekrarlatın ve düşen kaydı okuyun:

--a1b2c3d4-H--
Message: Access denied with code 403 (phase 2). detected SQLi using libinjection.
[file "/usr/local/apache/conf/modsec_vendor_configs/OWASP3/REQUEST-942-APPLICATION-ATTACK-SQLI.conf"]
[line "45"] [id "942100"] [msg "SQL Injection Attack Detected via libinjection"]
[data "Matched Data: 1 UNION SELECT found within ARGS:content"]
[severity "CRITICAL"] [tag "attack-sqli"]
[hostname "ornek-siteniz.com"] [uri "/wp-admin/post.php"] [unique_id "aB3xY..."]

Bu satırı okumayı bilmek, 403 teşhisini dakikalar yerine saniyeler alan bir işe çevirir:

• [id "942100"] — Tetiklenen kuralın numarası. Bir düzeltme yapacaksanız ihtiyacınız olan tek değer budur.
• [uri "/wp-admin/post.php"] — Hangi adreste tetiklendi.
• [data "Matched Data: ..."] — Kuralı tetikleyen tam metin. Genellikle burada gördüğünüz şey, formunuza yazdığınız masum bir cümledir.
• [msg ...] — Kuralın ne sandığı.
• [severity ...] — Kuralın ciddiyet derecesi.

Paylaşımlı hostingde modsec_audit.log'a erişiminiz olmaz. Bu durumda cPanel'in Hata Günlükleri ekranına bakın; bazı kurulumlarda ModSecurity kayıtları oraya da düşer. Düşmüyorsa, destek kaydı açarken hatayı yaşadığınız tam saati, sayfanın adresini ve kendi IP'nizi yazın — sağlayıcı kural numarasını sizin için bulup bildirebilir. cPanel hata günlüklerinin nasıl okunacağı cpanel hata kayıtları yazısında anlatılıyor.

Kural numarasını öğrendikten sonra ne yapılır:

cPanel'de ModSecurity Aracı (ModSecurity Tools) ekranı varsa, oradan yalnızca o kural numarasını devre dışı bırakabilirsiniz. WHM erişiminiz varsa aynı işi kural muafiyeti olarak tanımlarsınız:

<LocationMatch "/wp-admin/post.php">
    SecRuleRemoveById 942100
</LocationMatch>

⚠️ Buradaki en kritik nokta: ModSecurity'yi komple kapatmayın. Türkçe forumlarda en sık verilen tavsiye budur ve sitenizi otomatik saldırı taramalarına açık bırakır. Tek bir kural numarasını, tek bir adres için muaf tutmak, tüm duvarı yıkmaktan kat kat güvenlidir. Kuralın gerçekten yanlış pozitif olduğundan emin olun: Matched Data alanında sizin yazdığınız metni görüyorsanız yanlış pozitiftir; tanımadığınız bir yük görüyorsanız ModSecurity gerçek bir saldırıyı engellemiştir ve kuralı kaldırmak yanlış olur.

WordPress'e Özgü 403 Senaryoları#

WordPress'te 403 hatasının kendine has birkaç kaynağı vardır:

Güvenlik eklentisi kilidi. Bir güvenlik eklentisi, başarısız giriş denemeleri sonrası IP'nizi kilitlemiş olabilir. Panele giremiyorsanız eklenti klasörünü FTP üzerinden geçici olarak yeniden adlandırın:

mv ~/public_html/wp-content/plugins/wordfence ~/public_html/wp-content/plugins/wordfence-kapali

Panele girip kilidi kaldırdıktan sonra klasörü eski adına döndürün.

wp-admin klasöründe fazladan .htaccess. Bazı güvenlik eklentileri buraya kendi koruma dosyasını yazar. Eklenti kaldırıldığında dosya kalabilir ve yönetim panelini kilitler.

Hotlink koruması. Yalnızca görseller 403 veriyorsa, cPanel'in hotlink koruması devrededir ve kendi alan adınızı izinli listeye eklemeyi unutmuşsunuzdur — www ile www'suz sürümün ikisini de eklemek gerekir.

Leech Protect. Aynı hesapla çok sayıda eşzamanlı giriş yapılması hâlinde erişimi kesen bir cPanel özelliğidir; üyelik siteleri için sürprizli sonuçlar üretebilir.

Yanlış kalıcı bağlantı yapısı. Site kökü açılıyor ama tüm iç sayfalar 403 veriyorsa, .htaccess yeniden yazma kuralları bozulmuş olabilir. Kalıcı Bağlantılar ekranını kaydederek dosyayı yeniden ürettirin.

Adım Adım 403 Teşhis Akışı#

Aşağıdaki sırayı izlerseniz vakaların büyük kısmını 10 dakikanın altında kapatırsınız.

1. "Sadece ben mi alıyorum" sorusunu cevaplayın. Mobil veriyle test edin. Sadece siz alıyorsanız doğrudan 4. adıma (IP engeli) atlayın; dosya izinleriyle vakit kaybetmeyin.
2. Kapsamı daraltın. Tüm site mi, tek bir klasör mü, tek bir dosya tipi mi, yoksa yalnızca bir form gönderimi mi 403 veriyor? Tek bir işlem etkileniyorsa şüpheli ModSecurity'dir.
3. .htaccess'i yeniden adlandırıp test edin. Açılıyorsa suçlu bulunmuştur; kuralları blok blok daraltın.
4. IP engellerini tarayın. cPanel IP Engelleyici, WHM cPHulk beyaz/kara listeleri, sunucu güvenlik duvarı. Kendi ofis IP'nizi kalıcı olarak beyaz listeye alın.
5. İzin ve sahiplik kontrolü yapın. Dizinler 755, dosyalar 644 mü? 777 verilmiş dizin var mı? Sahiplik doğru kullanıcıda mı?
6. Kök dizinde index dosyası olduğunu doğrulayın. Yoksa yedekten geri getirin.
7. ModSecurity log'unu izleyerek hatayı tekrarlatın. Kural numarasını (id) not edin, yalnızca o kuralı ve yalnızca ilgili adres için muaf tutun.
8. Son değişikliği geri alın. Hata belirli bir eklenti kurulumu, güvenlik ayarı veya taşımadan sonra başladıysa önce onu geri alın, teşhis sonra gelir.

Bu adımların hepsi tükendiği hâlde 403 sürüyorsa, sunucu genelinde bir yapılandırma söz konusudur ve hosting sağlayıcınıza — tam saat, tam adres ve kendi IP'nizle birlikte — bildirmek en hızlı yoldur.

Sıkça Sorulan Sorular#

403 hatasını dosya izinlerini değiştirerek çözebilir miyim#

Bazen çözebilirsiniz ama 403'lerin çoğunun sebebi izin değildir. Dizinlerin 755, dosyaların 644 olduğundan emin olmak doğru bir başlangıçtır; ancak site sadece sizin için 403 veriyorsa sorun izinlerde olamaz, çünkü izinler ziyaretçiye göre değişmez. Ayrıca 777 vermek çözüm değildir; birçok sunucu yapılandırması yazılabilir dizinleri güvenlik gerekçesiyle reddeder ve bu tam olarak 403 üretir.

Site herkese açık ama ben giremiyorum, sebebi ne olabilir#

Bu neredeyse kesinlikle bir IP engelidir ve üç yerden birinde kayıtlıdır: cPanel IP Engelleyici listesinde geçmişte eklenmiş geniş bir aralık yeni IP'nizi kapsıyor olabilir; cPHulk art arda başarısız giriş denemesinden sonra IP'nizi geçici kilitlemiş olabilir; ya da sunucu güvenlik duvarı otomatik bir kuralla engellemiştir. Önce kendi genel IP adresinizi öğrenin, sonra bu üç listeyi tek tek kontrol edin. Kalıcı çözüm, sabit IP'nizi cPHulk ve güvenlik duvarı beyaz listesine eklemektir.

ModSecurity 403 hatasını nasıl anlarım#

Belirti çok tipiktir: site normal çalışır, sadece belirli bir işlemi yaptığınızda 403 gelir. Yazı kaydederken veya form gönderirken hata alıp diğer sayfalarda sorun yaşamıyorsanız, isteğin içeriği engelleniyor demektir ve bu ModSecurity'nin imzasıdır. Kesinleştirmek için modsec_audit.log dosyasını izlerken hatayı tekrarlayın; düşen kayıttaki id, uri ve Matched Data alanları hangi kuralın neden tetiklendiğini söyler. Paylaşımlı hostingde bu dosyaya erişemezseniz, hatanın tam saatini ve adresini sağlayıcınıza bildirerek kural numarasını öğrenebilirsiniz.

ModSecurity'yi tamamen kapatmak güvenli mi#

Hayır, güvenli değildir. ModSecurity otomatik zafiyet taramalarını, SQL enjeksiyonu denemelerini ve bilinen istismar kalıplarını sunucuya ulaşmadan keser; kapattığınızda sitenizi bunların hepsine açarsınız. Yanlış pozitif yaşıyorsanız doğru yaklaşım, log satırından tetiklenen kural numarasını bulup yalnızca o kuralı ve mümkünse yalnızca ilgili adres için devre dışı bırakmaktır.

Klasör adresinde 403 alıyorum ama içindeki dosyalar açılıyor#

Bu bir hata değil, doğru ve güvenli davranıştır. Klasörde index.html veya index.php gibi bir dizin dosyası bulunmadığında ve dizin listeleme kapalı olduğunda sunucu klasör içeriğini göstermek yerine 403 döndürür. Listelemeyi açmak mümkündür ama önerilmez; klasördeki tüm dosyaların herkese görünür olması demektir. İçeriğin görünmesini istiyorsanız o klasöre kendi hazırladığınız bir index.html koymak çok daha kontrollü bir çözümdür.

403 hatası siteme zararlı yazılım bulaştığının işareti olabilir mi#

Olabilir, özellikle hata aniden ve hiçbir değişiklik yapmadığınız hâlde ortaya çıktıysa. Bazı zararlı yazılımlar .htaccess dosyasına kendi kurallarını yazar; bazı durumlarda ise sağlayıcınızın malware tarayıcısı enfekte dosyaları karantinaya alır ve bu dosyalara erişim 403 döner. Tüm .htaccess dosyalarını içerikleriyle listeleyip tanımadığınız kural olup olmadığına bakın ve dosya değişiklik tarihlerini kontrol edin. Temizliğe girişmeden önce mevcut hâlin tam yedeğini alın; kanıtı yok etmek teşhisi imkânsızlaştırır.

403 hatası SEO'ma zarar verir mi#

Uzun süren 403 zarar verir, çünkü Googlebot da 403 alır ve sayfaya erişemez. Google 403'ü "bu içerik bana kapalı" olarak yorumlar; kısa süreli olursa tekrar dener, kalıcı olursa sayfayı dizinden düşürür. Özellikle bir güvenlik duvarı kuralı Googlebot'un IP aralıklarını yanlışlıkla engelliyorsa, siteniz ziyaretçilere normal görünürken arama sonuçlarından sessizce kaybolur. Bu yüzden 403'ü çözdükten sonra Search Console'un URL denetleme aracıyla sayfanın gerçekten getirilebildiğini doğrulayın.

Kapanış#

403 Forbidden, tek bir sebebi olan tek bir arıza değil; sunucunun önündeki beş ayrı kapıdan birinin kapalı olduğunu söyleyen ortak bir sinyaldir. Teşhis, "izinleri 755/644 yap" refleksiyle değil, "bu 403'ü herkes mi alıyor yoksa sadece ben mi" sorusuyla başlar. Yalnızca siz alıyorsanız cevap IP engel listelerindedir; herkes alıyorsa .htaccess, izinler veya eksik bir index dosyası devrededir; hata sadece belirli bir işlem sırasında çıkıyorsa suçlu neredeyse her zaman ModSecurity'dir ve modsec_audit.log içindeki tek bir satır size kural numarasını, tetikleyen metni ve etkilenen adresi birlikte verir. O kural numarasını bilmeden yapılan her müdahale ya boşa gider ya da güvenlik duvarını gereksiz yere devre dışı bırakır.

Bu katmanların çoğu — ModSecurity kural muafiyeti, cPHulk beyaz listesi, sunucu güvenlik duvarı — yönetim yetkisi ister. Bu ayarlara erişemediğiniz ve her yanlış pozitifte destek beklemek zorunda kaldığınız için tıkanıyorsanız, kuralları kendiniz yönettiğiniz bir ortama geçmek kalıcı rahatlama sağlar; VDS sunucu paketleri bu kontrolü size verir. Güvenlik duvarını kendiniz ayarlamak yerine yanlış pozitifleri azaltılmış, yönetilen bir koruma katmanı istiyorsanız WAF hizmeti tam bu ihtiyaca yanıt verir. WordPress tarafında güvenlik eklentisi kilitleri ve izin sorunlarıyla tek başınıza uğraşmak istemiyorsanız WordPress hosting paketleri bu yapılandırmaları hazır getirir; sunucu tarafındaki kural, log ve engel yönetimini tamamen devretmek için ise sunucu yönetimi hizmetine bakabilirsiniz.