Web Sitenizde 403 Forbidden Hatasını Düzeltmenin 8 Yolu

Bir 403 Forbidden hatası, bir web sunucusunun istemcinin isteğini anladığı ancak yetersiz izinler nedeniyle yerine getirmeyi aktif olarak reddettiği durumlarda döndürdüğü bir HTTP durum kodudur. 404’ten (kaynak bulunamadı) farklı olarak, 403 kaynağın var olduğunu doğrular — sunucu yalnızca erişime izin vermez. Bu ayrım, temel nedeni teşhis ederken son derece önemlidir.

Hata, bir düzine farklı katmandan kaynaklanabilir: dosya sistemi izinleri, .htaccess direktifleri, sunucu düzeyinde yapılandırma blokları, IP engelleme kuralları, CDN veya WAF politikaları ya da hatalı çalışan bir WordPress eklentisi. Bu kılavuz, olasılık sırasına göre her anlamlı düzeltmeyi, tam komutlar, yapılandırma parçacıkları ve çoğu öğreticinin tamamen atladığı uç durumlarla birlikte ele almaktadır.

403 Forbidden Hatasını Tetikleyen Nedir

Herhangi bir düzeltme uygulamadan önce, bir web sunucusunun izlediği karar ağacını anlamak yardımcı olur. Apache veya NGINX bir istek aldığında şunları değerlendirir:

1. Dosya sistemi izinleri — sunucu işlem kullanıcısının dosyaya okuma erişimi var mı?
2. Sahiplik — dosya doğru kullanıcıya mı ait (genellikle www-data, apache veya nginx)?
3. Sunucu yapılandırma direktifleri — <Directory>, <Location> veya server {} blokları erişimi açıkça reddediyor mu?
4. .htaccess kuralları — varsayılanları geçersiz kılan Deny, Require veya Options direktifleri var mı?
5. Uygulama katmanı kuralları — bir CMS eklentisi, WAF veya güvenlik modülü isteği engelliyor mu?
6. IP düzeyinde bloklar — istekte bulunan IP adresi bir engelleme listesinde mi?

Hangi katmanın sorumlu olduğunu belirlemek, sorun giderme sürenizi yarıya indirir.

Düzeltme 1: Dosya ve Dizin İzinlerini Düzeltin

Yanlış UNIX izinleri, paylaşımlı ve VPS barındırma ortamlarında 403 hatalarının en yaygın tek nedenidir. Web sunucusu işleminin dosyalar üzerinde en az okuma (r) iznine ve istenen kaynağa giden yoldaki her dizin üzerinde okuma + çalıştırma (rx) iznine sahip olması gerekir.

Standart izin değerleri:

Kritik uç durum: Yoldaki herhangi bir üst dizin, sunucu kullanıcısı için çalıştırma (x) izninden yoksunsa, içindeki her dosya 403 döndürür — dosyanın kendisi doğru izinlere sahip olsa bile. Her zaman yalnızca hedef dosyayı değil, tüm yolu denetleyin.

SSH aracılığıyla izinleri yinelemeli olarak düzeltmek için:

# Fix directory permissions
find /var/www/html -type d -exec chmod 755 {} ;

# Fix file permissions
find /var/www/html -type f -exec chmod 644 {} ;

# Fix ownership (replace www-data with your server user)
chown -R www-data:www-data /var/www/html

Web sunucunuzun hangi kullanıcı olarak çalıştığını kontrol etmek için:

ps aux | grep -E 'apache|nginx|httpd' | grep -v grep | awk '{print $1}' | sort -u

Root erişimine sahip bir VPS Hosting planındaysanız, bu komutları doğrudan çalıştırabilirsiniz. Paylaşımlı barındırmada, kontrol panelinizin Dosya Yöneticisini veya FileZilla gibi bir FTP istemcisini kullanın, dosyaya veya dizine sağ tıklayın ve “İzinleri Değiştir” seçeneğini belirleyin.

Düzeltme 2: .htaccess Dosyasını Teşhis Edin ve Onarın

Apache, web kökünden istenen kaynağa kadar her dizin düzeyinde .htaccess dosyalarını okur. Tek bir hatalı biçimlendirilmiş direktif — veya bir güvenlik eklentisi tarafından eklenen bir direktif — sitenizin tüm bir bölümüne erişimi engelleyebilir.

Adım 1: .htaccess‘ın neden olup olmadığını belirleyin

Geçici olarak devre dışı bırakmak için dosyayı yeniden adlandırın:

mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

Sayfayı yeniden yükleyin. 403 kaybolursa, .htaccess dosyası suçludur.

Adım 2: Sorunlu direktifi belirleyin

403 hatalarına neden olan yaygın .htaccess direktifleri:

# Overly broad IP deny rule
Deny from all

# Missing Allow directive paired with Deny
Order deny,allow
Deny from all
# (Allow from all is absent)

# Incorrect Options directive
Options -Indexes -ExecCGI
# This is fine, but the following blocks everything:
Options None

# Require directive blocking all (Apache 2.4+)
Require all denied

Adım 3: WordPress için temiz bir .htaccess oluşturun

WordPress panosunda Ayarlar > Kalıcı Bağlantılar bölümüne gidin ve herhangi bir şeyi değiştirmeden Değişiklikleri Kaydet‘e tıklayın. WordPress geçerli bir .htaccess yeniden oluşturacaktır. Standart WordPress .htaccess şöyle görünür:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

Adım 4: Ana sunucu yapılandırmasında AllowOverride‘ı doğrulayın

AllowOverride None httpd.conf‘da veya bir sanal ana bilgisayar bloğunda ayarlanmışsa, Apache .htaccess dosyalarını tamamen yok sayar — ancak bazı direktifler ana yapılandırmadan hâlâ uygulanabilir ve beklenen davranışla çakışabilir.

grep -r "AllowOverride" /etc/apache2/

.htaccess‘ın çalışması için en azından şunlara ihtiyacınız vardır:

<Directory /var/www/html>
    AllowOverride All
</Directory>

Düzeltme 3: WordPress Eklentilerini ve Temalarını Devre Dışı Bırakın

Güvenlik eklentileri (Wordfence, iThemes Security, Sucuri), 403 hatalarına yol açan IP tabanlı engelleme kuralları, mod_security direktifleri veya özel .htaccess girişleri sıklıkla ekler — bazen site sahibini de kilitler.

FTP veya SSH aracılığıyla tüm eklentileri toplu olarak devre dışı bırakın:

mv /var/www/html/wp-content/plugins /var/www/html/wp-content/plugins_disabled

Hata temizlenirse, klasörü yeniden adlandırarak eklentileri tek tek yeniden etkinleştirin, ardından suçluyu belirleyene kadar bireysel eklenti dizinlerini dışarı ve içeri taşıyın.

Temaya özgü 403 hataları daha az yaygındır, ancak bir temanın functions.php‘ı istek işlemeye bağlandığında veya bir tema belirli sayfalarda oturum açma gereksinimleri uyguladığında ortaya çıkar. Test etmek için, panoya erişemiyorsanız phpMyAdmin aracılığıyla varsayılan bir WordPress temasına (Twenty Twenty-Four) geçin:

UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'template';
UPDATE wp_options SET option_value = 'twentytwentyfour' WHERE option_name = 'stylesheet';

Düzeltme 4: Tarayıcı Önbelleğini ve Çerezleri Temizleyin

Tarayıcılar, hata yanıtları da dahil olmak üzere HTTP yanıtlarını agresif biçimde önbelleğe alır. Bir kez sunulan 403, temel sorun çözüldükten sonra bile önbelleğe alınıp yeniden oynatılabilir. Bu durum, özellikle sunucunuzun önünde bir CDN veya ters proxy (Cloudflare, Varnish) bulunduğunda geçerlidir.

Tarayıcı düzeyinde düzeltme:

Tarayıcınızın geliştirici araçlarını açın (F12), Ağ sekmesine gidin, başarısız olan isteğe sağ tıklayın ve Tarayıcı Önbelleğini Temizle‘yi seçin — veya zorla yenileme kullanın:

• Windows/Linux: Ctrl + Shift + R
• macOS: Cmd + Shift + R

CDN/proxy düzeyinde düzeltme:

Cloudflare kullanıyorsanız, Cloudflare panosunda Önbelleğe Alma > Önbellek Temizleme > Özel Temizleme altından belirli URL için önbelleği temizleyin.

Önemli nüans: 403, Cloudflare’in kendisi tarafından sunuluyorsa (“Error 1020” veya Cloudflare markalı bir hata sayfası göreceksiniz), blok kaynak sunucunuz tarafından değil, bir Güvenlik Duvarı Kuralı veya IP itibar bloğu aracılığıyla CDN katmanında uygulanıyor demektir. Bu senaryoda sunucu izinlerini düzeltmenin hiçbir etkisi olmaz. Onaylamak için Cloudflare’in Güvenlik > Olaylar günlüğünü kontrol edin.

Düzeltme 5: IP Engelleme Kurallarını ve Güvenlik Duvarı Bloklarını İnceleyin

IP tabanlı 403 hataları, güvenlik eklentileri, fail2ban veya manuel iptables kuralları kendi IP adresiniz dahil meşru bir IP adresini engellediğinde yaygındır.

cPanel’de (IP Engelleyici):

1. cPanel’e giriş yapın.
2. Güvenlik > IP Engelleyici‘ye gidin.
3. Engellenen IP listesini inceleyin ve orada olmaması gereken girişleri kaldırın.

Apache .htaccess veya httpd.conf‘da:

# Apache 2.2 syntax
Order deny,allow
Deny from 203.0.113.45

# Apache 2.4 syntax
<RequireAll>
    Require all granted
    Require not ip 203.0.113.45
</RequireAll>

fail2ban aracılığıyla (VPS ortamlarında yaygın):

# List all jails
fail2ban-client status

# Check if your IP is banned in the apache-auth jail
fail2ban-client status apache-auth

# Unban an IP address
fail2ban-client set apache-auth unbanip 203.0.113.45

iptables aracılığıyla:

# List rules with line numbers
iptables -L INPUT -n --line-numbers

# Remove a specific DROP rule (replace 5 with the actual line number)
iptables -D INPUT 5

Tam ağ yığınını kontrol ettiğiniz bir Dedicated Server‘da, sorunun web sunucusu yapılandırmanızda olduğu sonucuna varmadan önce her zaman hem uygulama düzeyinde hem de çekirdek düzeyinde güvenlik duvarı kurallarını doğrulayın.

Düzeltme 6: Hotlink Korumasını Devre Dışı Bırakın veya Yeniden Yapılandırın

Hotlink koruması, HTTP Referer başlığını inceleyerek çalışır. Onaylanan listede olmayan bir Referer ile bir istek gelirse, sunucu 403 döndürür. Bu mekanizma birkaç senaryoda yanlış çalışabilir:

• Doğrudan URL erişimi — bazı yapılandırmalar, Referer başlığı olmayan istekleri engeller; bu durum, URL’yi doğrudan yazan, e-posta istemcilerindeki bağlantılara tıklayan veya yönlendirici başlıkları kaldıran gizlilik odaklı tarayıcılar kullanan kullanıcılar için geçerlidir.
• HTTPS’den HTTP’ye geçişler — tarayıcılar, bir HTTPS sayfasından bir HTTP kaynağına geçerken Referer başlığı göndermez; bu da hotlink korumasının isteği engellemesine neden olur.
• API veya betik erişimi — programatik istekler genellikle Referer başlığını tamamen atlar.

cPanel’de (Hotlink Koruması):

1. Güvenlik > Hotlink Koruması‘na gidin.
2. Etki alanınızın (hem http:// hem de https:// varyantları) Erişime İzin Verilecek URL’ler listesinde olduğundan emin olun.
3. Test ediyorsanız, geçici olarak Devre Dışı Bırak‘a tıklayın ve 403’ün çözülüp çözülmediğini onaylayın.

Doğrudan .htaccess‘da:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(www.)?yourdomain.com/ [NC]
RewriteRule .(jpg|jpeg|png|gif|webp|svg)$ - [F,L]

Doğrudan erişime (boş Referer) izin vermek için RewriteCond %{HTTP_REFERER} !^$ satırını kaldırın.

Düzeltme 7: Apache veya NGINX Sunucu Yapılandırmasını Düzeltin

Sunucuyu kendiniz yönettiğinizde — cPanel ile VPS‘de veya bare-metal özel bir örnekte olduğu gibi — yanlış yapılandırılmış sanal ana bilgisayar veya sunucu bloğu direktifleri, 403 hatalarının sık görülen bir kaynağıdır.

Apache Yapılandırması

Yaygın yanlış yapılandırma — eksik Require all granted:

Apache 2.4’te yetkilendirme modeli önemli ölçüde değişti. Eski Allow from all direktifi kullanımdan kaldırıldı. Açık bir Require ifadesi olmadan, Apache varsayılan olarak erişimi reddeder.

<VirtualHost *:80>
    ServerName yourdomain.com
    DocumentRoot /var/www/html

    <Directory /var/www/html>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

Options -Indexes için kontrol edin: Bu direktif, dizin listelemeyi engeller (dizin dosyası olmadığında 403 döndürür). Bir dizinde index.html veya index.php yoksa, Apache 403 döndürür. Bu kasıtlı bir güvenlik davranışıdır — ancak dizin listesi bekliyorsanız Options +Indexes ekleyin.

Yapılandırmanızı doğrulayın ve yeniden başlatın:

apachectl configtest
systemctl reload apache2

NGINX Yapılandırması

Yaygın yanlış yapılandırma — yanlış root yolu veya eksik dizin dosyası:

server {
    listen 80;
    server_name yourdomain.com;
    root /var/www/html;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }
}

root direktifi var olmayan bir yola veya nginx işlem kullanıcısının okuyamadığı bir yola işaret ediyorsa, her istek 403 döndürür.

Tam neden için NGINX hata günlüklerini kontrol edin:

tail -n 50 /var/log/nginx/error.log

NGINX’ten gelen 403 neredeyse her zaman şöyle bir günlük girişi üretir:

2024/01/15 10:23:45 [error] 1234#0: *1 "/var/www/html/index.html" is forbidden (13: Permission denied)

13 hata kodu, işletim sistemi düzeyinde İzin reddedildi anlamına gelir — Düzeltme 1’e geri dönün ve dosya sistemi izinlerini ve sahipliğini denetleyin.

NGINX’i test edin ve yeniden yükleyin:

nginx -t
systemctl reload nginx

Apache ve NGINX: 403 Sorun Giderme Karşılaştırması

Düzeltme 8: SSL Sertifikasını ve HTTPS Yönlendirme Yapılandırmasını Denetleyin

Bu düzeltme çoğu 403 kılavuzunda yer almaz, ancak gerçek ve sıklıkla gözden kaçan bir nedendir. Yanlış yapılandırılmış SSL yönlendirme kuralları, belirli senaryolarda 403 hatalarına yol açabilir.

Senaryo 1: Sertifika geçerli olmadan önce HTTPS’yi zorlamak

Bir .htaccess yönlendirmesi tüm trafiği HTTPS’ye yönlendiriyorsa ancak SSL sertifikası henüz sağlanmamışsa veya süresi dolmuşsa, bazı sunucu yapılandırmaları sertifika hatası yerine 403 döndürür.

# Problematic if SSL is not configured on the server
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

HTTPS yönlendirmelerini uygulamadan önce sertifikanızın etkin ve düzgün kurulu olduğunu doğrulayın.

Senaryo 2: mod_ssl istemci sertifikası gereksinimi

Apache yapılandırmanız kimlik doğrulama için istemci tarafı SSL sertifikaları gerektiriyorsa ve tarayıcı bir tane sunmuyorsa, Apache 403 döndürür:

<Directory /var/www/secure>
    SSLVerifyClient require
    SSLVerifyDepth 1
</Directory>

Karşılıklı TLS (mTLS) uygulamayı kasıtlı olarak gerçekleştirmediyseniz, kaldırın veya SSLVerifyClient none olarak ayarlayın.

Senaryo 3: Yanlış yönlendirme zinciriyle HSTS ön yükleme

Çakışan HSTS başlıkları ve HTTP’den HTTPS’ye kurallarından kaynaklanan bir yönlendirme döngüsü, belirli tarayıcı/proxy kombinasyonlarında 403 olarak kendini gösterebilir. Tam yönlendirme zincirini şununla inceleyin:

curl -I -L --max-redirs 10 http://yourdomain.com

Sistematik Teşhis: Hata Günlüklerinizi Okumak

Yukarıdaki her düzeltme, gerçek zamanlı günlük izlemeyle eşleştirilmelidir. Günlükleri okumadan tahmin yürütmek zaman kaybettirir.

Apache — hata günlüğünü canlı izleyin:

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

NGINX — hata günlüğünü canlı izleyin:

tail -f /var/log/nginx/error.log | grep 403

cPanel ortamları — günlüklere şu yoldan erişin:

tail -f /usr/local/apache/logs/error_log

Günlük girişi neredeyse her zaman size tam olarak hangi dosyanın 403’ü tetiklediğini ve nedenini söyler — izin reddedildi, eksik dizin dosyası veya açık bir reddetme kuralı.

Karar Matrisi: Doğru Düzeltmeyi Seçmek

Belirtilerinize göre en olası düzeltmeyi belirlemek için bu matrisi kullanın:

Temel Teknik Çıkarımlar

• Her zaman önce sunucu hata günlüğünü okuyun — 403’ün tam dosyasını ve nedenini saniyeler içinde tespit eder.
• Apache 2.4+’da, her <Directory> bloğunda Require all granted zorunludur. Bunu atlamak, yeni sunucu kurulumlarında 403’ün en yaygın nedenidir.
• Dosya izinleri tek başına yeterli değildir — sahiplik, web sunucusu işlem kullanıcısıyla (www-data, apache, nginx) eşleşmelidir.
• Bir CDN (Cloudflare, Fastly) tarafından sunulan 403, kaynak sunucunuz tarafından sunulan 403’ten tamamen ayrıdır. Birini düzeltmenin diğeri üzerinde hiçbir etkisi yoktur.
• WordPress sitelerinde, sunucu düzeyinde teşhise zaman harcamadan önce her zaman eklentileri toplu olarak devre dışı bırakarak test edin.
• Kendi altyapınızı bir VPS veya Dedicated Server üzerinde yönetiyorsanız, fail2ban günlüklerini ve iptables kurallarını kapsam dahilinde tutun — bunlar web sunucusu katmanının altında çalışır ve uygulama düzeyindeki hata ayıklama araçlarına görünmez.
• Boş Referer başlıklarını engelleyen hotlink koruması kuralları, gizlilik tarayıcılarındaki ve e-posta bağlantısı tıklamalarındaki meşru kullanıcıları etkiler — her zaman boş yönlendiriciler için bir istisna ekleyin.

SSS

403 Forbidden hatası ile 401 Unauthorized hatası arasındaki fark nedir?

401 Unauthorized hatası, sunucunun kimlik doğrulama gerektirdiği ve istemcinin geçerli kimlik bilgileri sağlamadığı anlamına gelir — yeniden kimlik doğrulama sorunu çözebilir. 403 Forbidden ise sunucunun kim olduğunuzu belirlediği (veya kimlik doğrulama gerektirmediği) ancak erişimi ne olursa olsun açıkça reddettiği anlamına gelir. Kimlik bilgileri sağlamak 403 ile yardımcı olmaz.

403 hatası web sitemi SEO sıralamalarını etkiler mi?

Evet. Googlebot bir sayfayı tararken 403 alırsa, o sayfayı dizine ekleyemez. Önemli URL’lerdeki kalıcı 403 hataları, bu URL’lerin arama sonuçlarından düşmesine neden olur. Googlebot’un sayfalarınıza erişip erişemediğini kontrol etmek için Google Search Console’un URL İnceleme aracını kullanın ve 403 ile ilgili tarama hataları için Kapsam raporunu izleyin.

Neden yalnızca belirli dosya türlerinde (resimler, PDF’ler) 403 hatası alıyorum?

Bu neredeyse her zaman hotlink korumasına (Düzeltme 6) veya .htaccess‘daki MIME türüne özgü bir kurala işaret eder. Belirli uzantıları hedefleyen FilesMatch veya RewriteRule direktiflerini kontrol edin. Ayrıca bu dosyaları içeren dizinin 755 izinlerine sahip olduğunu ve doğru sunucu kullanıcısına ait olduğunu doğrulayın.

SSH veya FTP erişimim yoksa 403 hatasını nasıl düzeltirim?

Dosya izinlerini ve .htaccess dosyalarını incelemek ve değiştirmek için barındırma sağlayıcınızın web tabanlı Dosya Yöneticisini (cPanel, Plesk veya DirectAdmin’de mevcuttur) kullanın. WordPress’e özgü sorunlar için, kontrol panelinizin terminali aracılığıyla kullanılabiliyorsa WP-CLI aracı veya phpMyAdmin aracılığıyla doğrudan veritabanı erişimi, SSH olmadan eklentileri devre dışı bırakmaya ve temaları değiştirmeye yardımcı olabilir.

403 hatası web sitemi hacklendiği anlamına mı gelir?

Mutlaka değil, ancak bir belirti olabilir. Kötü amaçlı yazılımlar bazen .htaccess dosyalarına reddetme kuralları enjekte eder veya erişimi önlemek için dosya izinlerini değiştirir. 403 için yapılandırma tabanlı bir neden belirleyemiyorsanız, rkhunter, Wordfence (WordPress’e erişebiliyorsanız) veya barındırma sağlayıcınızın kötü amaçlı yazılım tarayıcısı gibi bir araç kullanarak dosyalarınızı yetkisiz değişiklikler açısından tarayın. Mevcutsa, dosya karmalarını bilinen iyi yedeklerle karşılaştırın.