403 Hatasını Giderme: Bilmeniz Gereken Dört Kaynak

Sunucu 403 Forbidden döndürüyor, ancak dosyanın hosting'de olduğundan ve yolu doğru girdiğinizden eminsiniz. Erişim logu da yalnızca 403 kodunu gösteriyor ve nedenine dair hiçbir ipucu vermiyor. Bu durum can sıkıcıdır çünkü neredeyse her zaman kod hatası anlamına gelen 500 hatasının aksine, 403 hatası tamamen farklı dört yerden gelebilir ve her birinin ayrı bir çözümü vardır. Kaynağı tespit edene kadar dosyalarda yapacağınız her değişiklik sadece tahminden ibarettir.

Yapmanız gereken ilk şey, 403'ün web sunucusundan mı yoksa uygulamadan mı geldiğini anlamaktır. Apache veya Nginx'in varsayılan HTML yanıtını görüyorsanız, sorun web sunucusu katmanındadır. Kendi özel sayfanız 403 koduyla dönüyorsa, büyük olasılıkla uygulama (PHP, WordPress, framework) bu kodu üretiyordur ve kodu veya eklentileri araştırmanız gerekir.

Birinci Kaynak: Linux'ta Dosya ve Dizin İzinleri

Paylaşımlı hosting'de 403'ün en yaygın nedeni dosya veya dizin üzerindeki yanlış izinlerdir. Web sunucusu www-data veya nobody gibi bir kullanıcıyla çalışır ve bu kullanıcının dosyayı okuma izni yoksa 403 yanıtı alırsınız. Basit bir komutla durumu görebilirsiniz:

ls -la /home/user/public_html/index.php
find /home/user/public_html -type d -not -perm 755
find /home/user/public_html -type f -not -perm 644

İlk komutun çıktısı izin sütununu gösterir; -rw------- gibi bir şey, yalnızca sahibin okuyabileceği ve web sunucusunun erişimi olmadığı anlamına gelir. Standart kural şudur: dizinler 755 ve dosyalar 644. Düzeltmek için:

find /home/user/public_html -type d -exec chmod 755 {} \;
find /home/user/public_html -type f -exec chmod 644 {} \;

Burada bir hata yapılır: birçok kişi sorunu hızlıca çözmek için her şeyi 777 yapar. Site açılır, ancak artık sunucudaki her script dosyalarınızı yeniden yazabilir. Belirtisi de geç ortaya çıkar; genellikle yükleme dizininde bilinmeyen bir PHP dosyası belirdiğinde veya sitenizin ana sayfası sizin müdahaleniz olmadan değiştiğinde fark edersiniz. 777 izni hiçbir zaman çözüm değildir, yalnızca sorunu gözden gizler.

İkinci Kaynak: Dizinde Index Eksikliği

Bir dizinin adresini açtığınızda ve içinde index.php veya index.html dosyası yoksa, web sunucusunun iki seçeneği vardır: dosya listesini göstermek veya 403 döndürmek. Çoğu hosting güvenlik nedeniyle ikinci seçeneği tercih eder. Yani example.com/blog/ adresini girip 403 alıyorsanız, önce o dizinde index adında bir dosya olup olmadığına bakın:

ls -la /home/user/public_html/blog/

Boşsa veya yalnızca yan dosyalar varsa, sorun budur. Ya bir index dosyası oluşturmalısınız ya da .htaccess içinde yolu başka bir dosyaya yönlendirmelisiniz:

DirectoryIndex index.php index.html home.php

Daha az görülen bir nokta: bazen index dosyası vardır ancak adı büyük harfle başlar, örneğin Index.php. Linux sunucularda dosya adları büyük-küçük harfe duyarlıdır ve web sunucusu onu bulamaz. Bu durum Windows'ta asla yaşanmaz ve bu nedenle siteyi bir Windows hosting'den taşıdığınızda aniden 403 ile karşılaşırsınız.

Üçüncü Kaynak: htaccess Kuralları ve IP Kısıtlaması

.htaccess dosyası erişimi açıkça reddedebilir. İki yaygın kalıp:

# Apache 2.4
Require all denied

# Apache 2.2 (eski)
Order deny,allow
Deny from all

Bu satırlar dosyada varsa, tüm istekler 403 alır. Daha ince durum, IP tabanlı bir kuralınız olduğunda ve IP'niz değiştiğinde ortaya çıkar:

Require ip 185.55.10.20
Require ip 91.98.0.0/16

Burada yalnızca listelenen IP'lerin girişine izin verilir ve diğerleri 403 alır. IP'niz değiştiyse, kendiniz de kilitlenirsiniz. Test etmek için .htaccess dosyasını geçici olarak .htaccess.bak olarak yeniden adlandırın ve sayfayı tekrar açın. Sorun çözüldüyse, suçlu bu dosyadır ve satır satır incelemeniz gerekir. Test sonrası dosyayı geri koymayı unutmayın.

Pratik bir not: IP'niz dinamikse ve sürekli değişiyorsa, yönetim paneli için IP tabanlı kısıtlama kötü bir seçimdir. Daha iyi bir alternatif, IP'ye bağımlı olmamak için panelin kendisinde iki adımlı kimlik doğrulamadır.

Dördüncü Kaynak: ModSecurity ve Web Katmanı Güvenlik Duvarı

Bu durum en çok kafa karıştıranıdır, çünkü dosyalar ve izinler sağlamdır ve .htaccess de sorunsuzdur, ancak isteğiniz siteye ulaşmadan engellenir. ModSecurity, istekleri güvenlik kurallarına göre inceleyen bir web katmanı güvenlik duvarıdır ve şüpheli bir kalıp tespit ederse 403 koduyla yanıt verir.

Belirtisi şudur: belirli bir form çalışmaz veya belirli bir parametreye sahip adresler 403 alır, ancak sitenin geri kalanı sağlamdır. Örneğin, parametrede union select kelimesiyle bir sorgu göndermek veya uzantısı kara listede olan bir dosya yüklemek. Kesin nedeni görmek için ModSecurity logunu görmeniz gerekir:

tail -f /var/log/modsec_audit.log
grep "403" /var/log/apache2/error.log | tail -20

Logda kural kimliğini arayın; SQL Injection'a işaret eden [id "942100"] gibi bir şey. İsteğinizin temiz olduğundan eminseniz, o belirli kuralı devre dışı bırakabilirsiniz, ancak bunu yalnızca belirli kural için yapın, tüm ModSecurity için değil. Güvenlik duvarını tamamen kapatmak, siteyi gerçek saldırılara karşı savunmasız bırakır.

Hangi Kaynağın Olduğunu Hızlıca Nasıl Anlarız

İnceleme sırasını değiştirmeyin. Önce curl ile yanıt başlıklarını görün:

curl -I https://example.com/blog/

Server: Apache veya Server: nginx başlığı varsa ve varsayılan 403 sayfası döndüyse, sorun web sunucusu katmanındadır. Uygulamaya özgü başlıklar (örneğin X-Powered-By: PHP) görürseniz, sorun koddadır. Ardından sırasıyla dosya izinlerini, index varlığını, htaccess kurallarını ve son olarak ModSecurity'yi kontrol edin. Bu sıralama basitten karmaşığa doğrudur ve genellikle ilk iki adımda çözülür.

Linux hosting üzerinde çalışıyorsanız ve ModSecurity loglarına erişiminiz yoksa, destek ekibinden kural kimliğini sizin için çıkarmalarını isteyin; bu bilgi genellikle kullanıcı düzeyinde gösterilmez. Ağ ve DNS sorunlarını incelemek için de isteğin sunucuya doğru ulaştığından emin olmak amacıyla DNS ve ağ kontrol aracını kullanabilirsiniz.

Pratikte sık karşılaştığım bir nokta: siteyi yakın zamanda başka bir sunucudan taşıdıysanız ve 403 alıyorsanız, eski .htaccess dosyasının önceki sunucu ayarlarıyla yeni sunucuda sorun yaratma olasılığı yüksektir. Herhangi bir şey yapmadan önce bu dosyayı geçici olarak devre dışı bırakın. Ayrıca içerik yönetim sistemleri kullanıyorsanız, wp-admin veya eşdeğeri dizini kontrol edin, çünkü bazı güvenlik eklentileri güncellemeden sonra yönetici erişimini kapatan ek bir kural ekler.

403'ü giderdikten sonra site yavaşlığıyla ilgili sorunları gidermek için yavaş site sorun giderme kılavuzuna bakın. Bir test ortamı kuruyorsanız da staging ortamı oluşturma kılavuzu, ana siteye dokunmadan değişiklikleri test etmenize yardımcı olur.

Sık Sorulan Sorular

403 ve 401 hatası arasındaki fark nedir?

401 hatası, kimlik doğrulamanın yapılmadığı veya kullanıcı adı ve parolanın yanlış olduğu anlamına gelir; sunucu önce kendinizi tanıtmanızı söyler. 403 hatası ise kimliğinizin belirli olduğu ancak o kaynağa erişim izniniz olmadığı anlamına gelir. Pratikte, bir sayfa 401 ile dönerse genellikle bir giriş penceresi görürsünüz, ancak 403 doğrudan reddedilir.

403 hatası CDN tarafından gelebilir mi?

Evet. Bazı CDN'ler kendi güvenlik kurallarına göre istekleri engeller ve 403 kodu döndürür. Tespit etmek için yanıt başlıklarını curl -I ile inceleyin; ana web sunucusu yerine CDN sunucusunun adını görürseniz, o hizmetin kurallarını kontrol etmelisiniz.

Neden yalnızca ben 403 alıyorum ve diğer kullanıcılar sorun yaşamıyor?

Muhtemelen IP tabanlı bir kısıtlama uygulanmış veya hesabınız engellenenler listesine alınmıştır. Başka bir internet bağlantısı veya VPN ile test edin. Sorun çözülürse, suçlu .htaccess içindeki IP tabanlı kural veya sunucu güvenlik duvarıdır.

Dosya iznini 777'ye değiştirmek sorunu çözer mi?

Geçici olarak siteyi açabilir, ancak bu güvenliği ciddi şekilde düşürür ve doğru çözüm değildir. Dosyalar için doğru izin 644, dizinler için 755'tir. Bu değerlerle hâlâ 403 alıyorsanız, sorun başka bir yerdedir ve onu bulmanız gerekir.

Sonraki adım, hemen şimdi curl -I ile yanıt başlıklarını almak ve 403'ün hangi katmandan geldiğini belirlemektir. Bunu bilene kadar dosyalarda yapacağınız her değişiklik sadece zaman kaybıdır.