403 Forbidden hatası, sunucunun isteğinizi anladığını ama yerine getirmeyi reddettiğini söyler. RFC 9110'daki tanım tam olarak budur: sunucu isteği anlamıştır ancak karşılamayı reddeder. Yani sayfa ortadan kalkmış değildir (o 404 olurdu) ve sunucu çökmüş de değildir (o 5xx olurdu); sunucu bilerek "buraya erişemezsiniz" demektedir.
Bu reddin arkasında çoğu zaman basit bir yapılandırma konusu vardır: yanlış dosya izni, eksik index dosyası, bir .htaccess erişim kuralı, güvenlik duvarı (WAF) veya IP engeli. Aşağıda önce ziyaretçinin kontrol edebileceklerini, sonra site sahibi için Apache, LiteSpeed, Nginx ve cPanel tarafındaki nedenleri, günlükte nasıl görüneceklerini ve güvenli çözümlerini anlatıyoruz.
403 ile 401 arasındaki fark
İki kod da erişim sorununu anlatır ama anlamları farklıdır. RFC 9110'a göre 401 Unauthorized, isteğin geçerli kimlik bilgileri olmadığı için uygulanmadığını belirtir ve sunucu bu yanıtla birlikte bir WWW-Authenticate başlığı göndermek zorundadır; yani "önce kimliğinizi kanıtlayın" der. 403 Forbidden ise kimlik bilgisi gönderilmişse bunların erişim için yetersiz görüldüğünü anlatır. MDN'nin ifadesiyle 403'te kimlik doğrulamak ya da yeniden doğrulamak bir şey değiştirmez.
RFC 9110 ayrıca isteğin kimlik bilgileriyle ilgisi olmayan nedenlerle de yasaklanabileceğini belirtir. Bir kaynağın varlığını gizlemek isteyen sunucu 403 yerine 404 de döndürebilir. Bu yüzden bazı sistemlerde aynı erişim engeli 404 olarak görünebilir. Diğer kodlar için HTTP durum kodları yazımıza bakabilirsiniz.
| Kod | Anlamı | Ne yapılır |
|---|---|---|
| 401 Unauthorized | Geçerli kimlik bilgisi yok | Giriş yapmak veya doğru kimlik bilgisi göndermek |
| 403 Forbidden | Sunucu anladı ama reddetti | İzin, kural veya engelin kaldırılması |
| 404 Not Found | Kaynak bulunamadı (veya gizleniyor) | Adresi kontrol etmek |
Ziyaretçiyseniz: kısa kontroller
403'ün nedeni çoğunlukla sunucudadır, ama bazı durumlarda sizin bağlantınız veya tarayıcınız da işin içindedir:
- Adresi kontrol edin. Sonu
/ile biten bir klasör adresine (örneğin/resimler/) gidiyorsanız ve o klasörde index sayfası yoksa 403 almanız normaldir. - VPN veya proxy kullanıyorsanız kapatıp tekrar deneyin. Bazı siteler belirli IP aralıklarını veya ülkeleri engeller.
- Tarayıcı çerezlerini ve önbelleğini o site için temizleyin ya da gizli pencerede açın.
- Başka bir ağdan (örneğin mobil veri) deneyin. Yalnızca bir ağdan hata alıyorsanız o IP adresi engellenmiş olabilir.
- Bir siteye giriş yapmanız gerekiyorsa çıkış yapıp yeniden giriş yapın; hesabınızın o sayfaya yetkisi olmayabilir.
Hiçbiri işe yaramazsa site sahibine adresi, saati ve kendi IP adresinizi bildirin. Engel bir güvenlik kuralından geliyorsa yönetici günlükte bu bilgilerle kaydı bulabilir.
Site sahibiyseniz: 403 nedenleri ve çözümleri
| Neden | Belirti | Çözüm |
|---|---|---|
| Yanlış dosya veya klasör izni | Tek dosyada ya da tüm sitede 403; Nginx günlüğünde "Permission denied" | Klasörler 755, dosyalar 644; sahipliği kontrol edin |
| Index dosyası yok, listeleme kapalı | Yalnızca klasör adreslerinde 403 | index.html veya index.php ekleyin ya da DirectoryIndex / index ayarını düzeltin |
| .htaccess erişim kuralı | Belirli dosyalarda veya tüm sitede 403 | Require all denied ya da eski Deny from all satırlarını inceleyin |
| Nginx deny kuralı | Belirli location veya IP için 403 | allow/deny sırasını kontrol edin |
| ModSecurity / WAF | Form gönderirken veya belirli URL'lerde 403 | Günlükteki kural kimliğini bulun, kuralı hosting firmasıyla birlikte değerlendirin |
| IP engeli | Yalnızca belirli ziyaretçilerde 403 | cPanel IP Blocker listesini kontrol edin |
| Hotlink koruması | Resimler başka sitede veya bazı uygulamalarda açılmıyor | İzin verilen adresler listesine kendi alan adlarınızı ekleyin |
1. Dosya izinleri ve sahiplik
Web sunucusu bir dosyayı okuyamıyorsa onu sunamaz ve 403 döndürür. WordPress belgeleri suEXEC kullanan sunucular için şu değerleri önerir: tüm klasörler 755 veya 750, tüm dosyalar 644 veya 640, wp-config.php ise sunucudaki diğer kullanıcıların okuyamaması için 440 veya 400. Aynı belge hiçbir klasöre, yükleme klasörleri dahil, 777 verilmemesi gerektiğini açıkça yazar. Ayrıntılar için WordPress dosya izinleri ve güvenlik rehberi yazımızı okuyun.
İzin kadar sahiplik de önemlidir. WordPress belgelerine göre suEXEC ortamında dosyalar web sunucusu kullanıcısına değil, sitenin kendi hesabına ait olmalıdır. Başka bir sunucudan taşınan veya root ile yüklenen dosyalar yanlış sahipte kalabilir; paylaşımlı hostingde bunu hosting firmanız düzeltir.
# Önce yedek alın. public_html içindeki izinleri kontrol etmek için:
ls -la ~/public_html
# Önerilen değerleri uygulamak için:
cd ~/public_html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;Nginx kullanan sunucularda, dosyanın kendisi okunabilir olsa bile yol üzerindeki klasörlerden biri Nginx'in çalıştığı kullanıcıya kapalıysa erişim reddedilir; günlükte genellikle "Permission denied" ifadesini görürsünüz. Linux izinleri hakkında temel bilgi için Linux sunucu komutları yazısına bakabilirsiniz.
2. Index dosyası eksik ve klasör listeleme kapalı
Bir klasör adresi istendiğinde sunucu önce index dosyasını arar. Apache'de bu DirectoryIndex yönergesiyle belirlenir ve varsayılanı index.html'dir. Apache belgelerine göre index bulunamazsa ve Indexes seçeneği açıksa sunucu klasörün listesini kendisi üretir. Listeleme kapalıysa (birçok hostingde güvenlik için kapalıdır) istek reddedilir ve ziyaretçi 403 görür. Apache günlüğünde bu durum genellikle AH01276: Cannot serve directory ... No matching DirectoryIndex ... found, and server-generated directory index forbidden by Options directive biçiminde görünür.
# .htaccess - önce yedek alın
# PHP sitesi için index sırasını belirtin
DirectoryIndex index.php index.html
# Klasör listelemeyi kapalı tutun (güvenli tercih)
Options -IndexesÇözüm listelemeyi açmak değil, klasöre doğru index dosyasını koymak veya DirectoryIndex sırasını düzeltmektir. Apache belgeleri bir ayrıntıya da dikkat çeker: .htaccess içinde Options yönergesini başında + veya - olmadan yazarsanız, devralınan seçeneklerin tamamını değiştirir ve listede olmayanlar kapanır. Örneğin yalnızca Options Indexes yazmak FollowSymLinks seçeneğini de kapatır; bu da per-directory bağlamda mod_rewrite'ın çalışmasını engeller. Bu yüzden Options -Indexes gibi işaretli yazım daha güvenlidir.
Nginx'te de mantık aynıdır. index yönergesinin varsayılanı index index.html; olduğundan PHP sitesinde index.php eklenmemişse ana sayfa 403 verebilir. Nginx belgelerine göre index modülü dosya bulamadığında istek genellikle autoindex modülüne geçer ve autoindex varsayılan olarak off durumdadır. Günlükte bu genellikle "directory index of ... is forbidden" şeklinde görünür.
server {
root /var/www/site;
index index.php index.html;
# autoindex varsayılan olarak kapalıdır, açmanız gerekmez
}3. .htaccess ve sunucu yapılandırmasındaki erişim kuralları
Apache 2.4 ile erişim denetimi değişti. Apache'nin geçiş belgesine göre 2.2'deki Order deny,allow ve Deny from all ikilisinin 2.4 karşılığı Require all denied, herkese açık erişimin karşılığı ise Require all granted yönergesidir. Eski yönergeler mod_access_compat ile hâlâ çalışabilir, ancak belge eski ve yeni yönergelerin karıştırılmamasını önerir; karışık kullanımda eski yönergeler öncelik kazanıp beklenmedik 403'lere yol açabilir.
# Belirli bir dosyaya erişimi kapatmak (Apache 2.4)
<Files "gizli.txt">
Require all denied
</Files>
# Yönetim klasörünü yalnızca tek IP'ye açmak
# (bu satırları yönetim klasöründeki .htaccess dosyasına koyun)
Require ip 203.0.113.10Tüm sitede 403 alıyorsanız kök klasördeki ve üst klasörlerdeki .htaccess dosyalarında Require all denied, Deny from all veya bir güvenlik eklentisinin eklediği blokları arayın. Yedek alıp şüpheli bloğu geçici olarak yorum satırına çevirerek test edebilirsiniz. Daha fazla örnek için .htaccess rehberi yazımıza göz atın.
Nginx'te IP tabanlı kısıtlama allow ve deny ile yapılır. Nginx belgelerine göre kurallar sırayla kontrol edilir ve ilk eşleşen kural uygulanır. Bu yüzden deny all; satırını izin satırlarından önce yazarsanız herkes engellenir.
location /yonetim/ {
allow 203.0.113.10;
deny all;
}4. ModSecurity ve web uygulama güvenlik duvarı (WAF)
Form gönderirken, belirli bir eklentiyi kullanırken ya da URL'de belirli karakterler varken 403 alıyorsanız sebep çoğu zaman bir WAF kuralıdır. cPanel'de Security bölümündeki ModSecurity ekranından alan adı bazında ModSecurity'yi açıp kapatabilirsiniz. Ancak cPanel belgeleri ModSecurity'nin tüm alan adlarında açık tutulmasını şiddetle önerir ve yalnızca sorun giderme sırasında kapatılmasını söyler.
5. IP engelleri ve hotlink koruması
cPanel'deki IP Blocker, belirli IP adreslerini, aralıkları veya CIDR bloklarını sitenize erişimden engeller. cPanel belgelerine göre bu engel yalnızca web sitesi erişimini etkiler ve kurallar sitenin .htaccess dosyasına eklenir. Tek bir ziyaretçi veya ofis 403 alıyorsa önce bu listeye bakın. Sunucu genelinde bir güvenlik duvarı da IP engelleyebilir; bunun için hosting desteğine başvurmanız gerekir. Güvenlik duvarı mantığı için UFW güvenlik duvarı yazısına bakabilirsiniz.
Hotlink Protection ise başka sitelerin sizin dosyalarınızı kendi sayfalarına gömmesini engeller. Yanlış yapılandırıldığında kendi alt alan adınız, CDN adresiniz veya bazı uygulamalar resimleri yükleyemeyebilir. Çözüm, kendi kullandığınız tüm adresleri izin verilenler listesine eklemektir. cPanel belgeleri, korumayı kapatmanın izin listesini sildiğini, bu yüzden önce listeyi kaydetmeniz gerektiğini de hatırlatır.
Günlükte 403'ün nedenini bulmak
Erişim reddi çoğu zaman hata günlüğüne de yazılır. cPanel'de Metrics > Errors ekranı en yeni 300 kaydı gösterir. SSH erişiminiz varsa Apache için Debian/Ubuntu'da /var/log/apache2/error.log, RHEL ailesinde /var/log/httpd/error_log; Nginx için /var/log/nginx/error.log dosyalarını izleyin. Satırda hangi dosya veya klasörün reddedildiği, hangi yönergenin ya da hangi güvenlik kuralının devreye girdiği yazar.
# Son 403 nedenini görmek için hatalı adresi yenilerken izleyin
sudo tail -f /var/log/apache2/error.logWordPress sitelerinde 403 bazen yalnızca wp-admin veya wp-login.php için görülür. Bunun nedeni genellikle bir güvenlik eklentisinin veya hosting firmasının giriş sayfasına koyduğu IP ya da ülke kısıtlamasıdır. Güvenlik eklentisini kalıcı olarak kapatmak yerine kendi IP adresinizi izin listesine ekleyin.
Sık Sorulan Sorular
403 Forbidden hatası SEO'yu etkiler mi?
Evet, kalıcı olursa etkiler. Google Search Central belgelerine göre Google 4xx döndüren URL'leri dizine eklemez ve önceden dizindeki URL'ler 4xx döndürmeye başlarsa dizinden çıkarılır. Aynı belge tarama hızını sınırlamak için 401 ve 403 kullanılmamasını da söyler.
Ana sayfam 403 veriyor ama alt sayfalar açılıyor, neden?
Bu genellikle kök klasörde index dosyasının olmadığını veya DirectoryIndex / Nginx index ayarında index.php bulunmadığını gösterir. Dosya adını ve ayarı kontrol edin.
Klasör listelemeyi açmak 403'ü çözer mi?
Açarsanız hata kaybolabilir, ama klasördeki tüm dosyaları herkese listelemiş olursunuz. Güvenli çözüm listelemeyi kapalı tutmak ve doğru index dosyasını eklemektir.
Yalnızca benim IP adresim engellenmiş olabilir mi?
Evet. cPanel IP Blocker, bir güvenlik eklentisi veya sunucu güvenlik duvarı tekrarlanan hatalı giriş denemelerinden sonra IP'nizi engellemiş olabilir. Başka bir ağdan sorunsuz giriyorsanız hosting desteğine IP adresinizi bildirin.
Yazılım, tarayıcı ve hizmet adları sahiplerine aittir. Bu yazı bağımsız bir teknik rehberdir; adı geçen şirketlerle ortaklık ilişkisi bulunduğu anlamına gelmez.
İlgili içerikler: WordPress dosya izinleri · 500 Internal Server Error · 503 Service Unavailable · .htaccess rehberi · Nginx yapılandırma rehberi · HTTP durum kodları