WordPress REST API 403 Hatası Veriyorsa 9 Kontrol

WordPress güvenlik eklentileri, şüpheli kabul edilen HTTP isteklerini engelleyebilir.

Bazı durumlarda meşru bir Gutenberg kaydetme isteği veya eklenti API çağrısı güvenlik kuralıyla eşleşebilir.

Belirtiler

• REST API isteğinde 403 görünür.
• Güvenlik eklentisinde engellenen istek kaydı vardır.
• Yalnızca belirli kullanıcı veya IP adresinde sorun oluşur.
• Bir eklenti güncellemesinden sonra hata başlamıştır.

Çözüm

1. Güvenlik eklentisinin engelleme kayıtlarını açın.
2. Hatalı isteğin URL’sini ve zamanını karşılaştırın.
3. Eşleşen kuralı belirleyin.
4. Gerekirse kontrollü test ortamında geçici karşılaştırma yapın.
5. Yalnızca yanlış pozitif kuralı düzeltin.

REST API isteği WordPress’e ulaşmadan önce Cloudflare, hosting güvenlik duvarı veya ModSecurity tarafından reddedilebilir.

Bu durumda WordPress uygulamasında herhangi bir PHP hata kaydı bulunmayabilir.

WordPress ve sunucu 403 yanıtı nasıl ayırt edilir?

Çözüm

Hatalı isteğin zamanını, URL’sini, HTTP yöntemini ve güvenlik olayı kimliğini kaydedin.

Hosting sağlayıcısından ilgili isteği engelleyen ModSecurity veya WAF kuralının incelenmesini isteyin.

Cloudflare kullanıyorsanız güvenlik olaylarında aynı isteğe ait engelleme bulunup bulunmadığını doğrulayın.

Gutenberg, WordPress yönetim panelinde REST API çağrıları gerçekleştirirken oturum ve nonce doğrulamasından yararlanır.

WordPress’in rest_cookie_check_errors() işlevi geçersiz REST nonce tespit ettiğinde rest_cookie_invalid_nonce koduyla 403 döndürebilir.

Örnek hata

{
  "code": "rest_cookie_invalid_nonce",
  "message": "Cookie check failed",
  "data": {
    "status": 403
  }
}

Hata mesajının dili WordPress kurulumuna göre farklı olabilir.

Olası nedenler

• Yönetim oturumu süresi dolmuş.
• Sayfa uzun süre açık kalmış.
• Önbellekten eski nonce sunulmuş.
• Oturum çerezi isteğe eklenmemiş.
• www ve www olmayan adresler arasında oturum farklılığı oluşmuş.
• Özel JavaScript yanlış REST nonce kullanıyor.

Çözüm

1. Önce taslağınızın güvenli kopyasını alın.
2. WordPress oturumunu yenileyin.
3. Yönetim panelinde tekrar giriş yapın.
4. Yönetim sayfasının yanlışlıkla önbelleklenmediğini doğrulayın.
5. WordPress URL ve Site URL ayarlarını karşılaştırın.
6. Özel API istemcisinin geçerli nonce gönderdiğini kontrol edin.

REST API uç noktaları her kullanıcıya aynı işlemleri sunmaz.

Örneğin yazıları okumak mümkün olsa bile yazı yayımlamak, başkasının içeriğini düzenlemek veya yönetim verilerini görüntülemek için ek yetkiler gerekebilir.

WordPress current_user_can() işleviyle kullanıcıya tanımlanan yetkileri kontrol edebilir.

Kontrol edilecekler

• İstek yapan kullanıcı gerçekten giriş yapmış mı?
• Kullanıcı rolü ilgili işlemi destekliyor mu?
• Özel rol düzenleme eklentisi izinleri değiştirmiş mi?
• İstek özel veya taslak içeriğe mi erişiyor?
• API uç noktası farklı bir capability gerektiriyor mu?

Çözüm

Uç noktanın ihtiyaç duyduğu yetkiyi belirleyin. Sonra ilgili kullanıcıya gereksiz yönetici yetkisi vermeden doğru rol ve capability yapılandırmasını uygulayın.

WordPress REST API isteklerinin doğru işlenebilmesi için sunucunun URL yönlendirme kurallarının uygun olması gerekir.

Apache sunucusunda .htaccess dosyası, Nginx kurulumunda ise sunucu yapılandırması bu süreci etkileyebilir.

Yaygın problemler

• /wp-json/ yolunun sunucu düzeyinde engellenmesi
• Güvenlik kuralının API yollarını kısıtlaması
• Yanlış yeniden yazma kuralı
• Authorization başlığının uygulamaya ulaşmaması
• REST API sorgu parametrelerinin yönlendirmede kaybolması

Ön kontrol

WordPress’te Ayarlar → Kalıcı bağlantılar bölümünü açın. Mevcut ayarları not ederek kaydedin.

Bu işlem bazı yeniden yazma kurallarının güncellenmesine yardımcı olabilir. Ancak gerçek bir WAF engelini tek başına çözmez.

Alternatif REST API testi

Standart yol:
https://example.com/wp-json/

Alternatif sorgu:
https://example.com/?rest_route=/

Standart REST yolu çalışmıyor ancak alternatif sorgu çalışıyorsa yeniden yazma kuralları araştırılmalıdır.

LiteSpeed Cache, sunucu önbelleği ve CDN yapılandırmaları normalde site hızını artırmak amacıyla kullanılır.

Ancak yanlış önbellek kuralı, REST API’ye veya yönetim oturumuna ait yanıtların hatalı sunulmasına neden olabilir.

Kontrol edilecekler

• Giriş yapmış kullanıcıların yönetim yanıtları önbellekleniyor mu?
• REST API için özel cache kuralı var mı?
• Önbellekten eski nonce dönüyor mu?
• CDN katmanı 403 yanıtını önbelleğe alıyor mu?
• LiteSpeed ve güvenlik eklentisi aynı isteği farklı biçimde işliyor mu?

Çözüm

1. Hatalı REST API isteğinin URL’sini belirleyin.
2. Önbellek yanıt başlıklarını inceleyin.
3. Gerekirse güvenli test ortamında önbellek etkisini karşılaştırın.
4. Yetki gerektiren REST yanıtlarının herkese açık önbellekte sunulmadığını doğrulayın.
5. Yanlış cache kuralını düzeltin ve ilgili önbelleği temizleyin.

WordPress eklentileri REST API uç noktaları oluşturabilir veya mevcut API isteklerinin işlenmesini değiştirebilir.

Güvenlik, üyelik, kullanıcı rolü, optimizasyon ve özel yazılım eklentileri buna örnek olabilir.

Belirtiler

• Hata belirli eklenti güncellemesinden sonra başladı.
• Yalnızca tek bir eklentinin API yolu etkileniyor.
• Gutenberg bazı içerikleri kaydediyor, bazılarını kaydetmiyor.
• REST API izinleri özel kodlarla değiştirilmiş.

Çözüm

Önce tam yedek alın. Mümkünse staging ortamında test yapın.

WordPress Site Sağlığı sorun giderme araçları veya kontrollü eklenti testleriyle çakışmanın kaynağını belirleyin.

Eklentileri canlı sitede topluca devre dışı bırakmak yerine etkileri değerlendirilmiş, geri alınabilir bir test planı kullanın.

WordPress geliştiricileri register_rest_route() ile özel REST API uç noktaları oluşturabilir.

Bu uç noktalarda permission_callback, isteğin yetkili olup olmadığını kontrol eder.

Yanlış bir callback, yetkili kullanıcıların isteklerini de reddedebilir.

Yetki kontrolü örneği

<?php
// Yalnızca geliştirici örneği.
// WordPress eklentisi veya özel kod içindir.

add_action('rest_api_init', function () {

    register_rest_route(
        'ornek/v1',
        '/kayit',
        [
            'methods'  => 'GET',

            'callback' => function () {
                return rest_ensure_response([
                    'durum' => 'basarili'
                ]);
            },

            'permission_callback' => function () {
                return current_user_can(
                    'edit_posts'
                );
            }
        ]
    );

});

Bu örnekte edit_posts yetkisi bulunmayan kullanıcılar için erişim reddedilir. Bu, istenen güvenlik davranışıdır.

Kontrol edilecekler

• Callback doğru capability kontrolünü yapıyor mu?
• Kullanıcı gerçekten doğrulanmış mı?
• Yanlış rol veya kullanıcı kimliği mi kontrol ediliyor?
• Özel filtreler yetki sonucunu değiştiriyor mu?
• Uç noktanın gerçekten herkese açık olması gerekiyor mu?

WordPress REST API’ye harici yazılımlar üzerinden erişiliyorsa Application Passwords kullanılabilir.

WordPress 5.6’dan itibaren sunulan bu özellik, HTTPS üzerinden uygun şekilde doğrulanan API isteklerini destekler.

Yaygın sorunlar

• Normal WordPress parolasıyla API çağrısı yapılıyor.
• Application Password geçersiz veya iptal edilmiş.
• Authorization başlığı proxy tarafından siliniyor.
• İlgili kullanıcı yeterli yetkiye sahip değil.
• WordPress kurulumunda uygulama parolaları devre dışı bırakılmış.
• Harici istemci farklı alan adına istek gönderiyor.

Çözüm

Kullanıcının WordPress profilinde uygun Application Password oluşturma imkanını kontrol edin.

Harici istemcinin kimlik doğrulama başlığını doğru biçimde gönderdiğinden emin olun.

Ayrıca istek yapılan kullanıcının ilgili REST işlemini gerçekleştirmeye yetkisi bulunmalıdır.