GraphQL API Güvenlik Testi: Resolver Yetkisi, Batching ve Maliyet

Kısa cevap

GraphQL güvenliği, endpoint başına erişim kontrolü yazmaktan ibaret değildir. Tek bir endpoint çok sayıda query, mutation ve nested resolver çalıştırabilir; yetki, alanlara ve ilişki kenarlarına kadar tutarlı uygulanmalıdır. Güvenlik testi şema keşfini, resolver davranışını, batching ve kaynak tüketimini aynı iş akışında inceler.

GraphQL’in esnek sorgu modeli ürün geliştirmeyi kolaylaştırır; aynı esneklik beklenmeyen veri kombinasyonları ve pahalı sorgular üretir. REST’te ayrı endpoint’lerde görülen erişim kontrolleri, GraphQL’de aynı nesneye farklı resolver yollarından ulaşılabildiği için eksik kalabilir.

Şema yüzeyini ve resolver zincirini çıkarın

Sürüm ve rol bazında açık query, mutation, subscription, custom scalar, interface ve union tiplerini haritalayın. Introspection üretimde kapalı olsa bile istemcilerin kullandığı operasyonlar, hata mesajları, belgeler ve persisted-query kayıtları şema hakkında bilgi verebilir. Introspection’ı kapatmak yetki açığını kapatmaz; asıl kontrol her resolver’ın doğru policy’yi uygulamasıdır.

Bir nesneye iki yoldan ulaşmayı deneyin: örneğin currentUser { invoices } ve invoice(id) gibi doğrudan sorgu. Liste resolver’ı tenant filtresi uygularken tekil resolver uygulamıyorsa aynı nesne farklı graph kenarından açığa çıkabilir. OWASP’nin “node” ve “edge” ayrımı burada önemlidir: ilişki listesini görme yetkisi, dönen her kaynağı okuma yetkisini otomatik vermez.

Mutation’larda yalnızca root alanına bakmayın. İç içe input nesnelerinde ownerId, tenantId, role, status veya fiyat gibi sunucunun belirlemesi gereken alanlar değiştirilebiliyor mu? Mutation başarılı cevabı döndürürken başka bir nesnenin yan etkisi oluşuyor mu? Her hassas değişiklik için hem işlem yetkisini hem hedef nesne sahipliğini doğrulayın.

Yetki matrisi oluşturun

Test hesabı A/B, farklı tenant’lar ve yönetici/üye/okuyucu rolleri belirleyin. Aynı query’yi şu varyantlarla deneyin:

Yetkiyi sadece route katmanına koymak yeterli değildir; resolver, domain/service katmanı veya veri erişim katmanı için ortak ve test edilebilir policy tasarımı gerekir. Resolver’ların her biri kendi erişim kararını veriyorsa kod incelemesinde kontrol unutulma riski yükselir.

Batching, derinlik ve sorgu maliyeti

GraphQL batching tek HTTP isteğinde çok sayıda operasyon veya nesne denemesine izin verebilir. Rate limit sadece IP veya HTTP istek sayısını sayıyorsa bir request içindeki pahalı işlemler görünmez kalır. Hassas login, OTP, kullanıcı arama ve parola sıfırlama alanlarında batch sayısı ve toplam işlem sayısı ayrıca sınırlandırılmalıdır.

Nested query derinliği, liste boyutu, pagination limiti ve resolver fan-out birlikte ele alınmalıdır. Derinliği sınırlamak tek başına yeterli değildir: sığ bir sorgu milyonlarca node döndürebilir; küçük limitlerle çok sayıda alias da resolver’ı tekrar tekrar çalıştırabilir. Sorgu maliyeti hesabı, timeout, kullanıcı bazlı rate limit ve veritabanı yük testini birlikte değerlendirin. Limitler aşılınca kısmi veri ya da sessiz truncation yerine anlaşılır ve güvenli ret beklenmelidir.

Hatalar ve üretim yapılandırması

Resolver exception’larının stack trace, SQL ayrıntısı, dosya yolu veya iç servis adlarını dışarı verdiğini kontrol edin. Tip önerileri veya schema introspection’ın varlığı tek başına zafiyet değildir; hassas işlevlerin anonim erişilebilir olması ve canlı veriye ulaşması etkiyi belirler. Debug/GraphiQL araçlarının üretimde açık olup olmadığını deployment profilleriyle doğrulayın.

Persisted query kullanılıyorsa, kayıt dışı query’nin üretimde kabul edilip edilmediğini ve allowlist’in yetkisiz operasyonu engelleyip engellemediğini test edin. Allowlist, resolver yetkisinin alternatifi değildir; kullanıcıya özel veriyi herkese açık operasyonla döndürebilir.

Güvenli test planı

1. Roller ve hassas graph nesneleri için erişim matrisi kurun.
2. Aynı kaynağa liste, doğrudan ID, nested relation ve mutation üzerinden erişin.
3. Alias, fragment, batching, derinlik, sayfa boyutu ve maliyet kontrollerini deneyin.
4. Subscription’ın oturum ve rol değişikliklerine tepkisini gözlemleyin.
5. Her bulguda query, rol, kaynak sahibi ve dönen/ değişen veriyi redakte edilmiş kanıtla kaydedin.
6. Düzeltme sonrası hem reddedilen çapraz erişimi hem de izinli akışın çalışmasını retest edin.

Gözlemlenebilirlik ve üretim limitleri

Resolver telemetry; operasyonu, rolü, tenant’ı ve maliyet davranışını gösterebilmelidir. Tüm değişkenleri veya kişisel veriyi loglamak yerine operasyon adı/hash’i, sonuç boyutu, resolver süresi ve policy kararı gibi alanları kullanın. Anormal sorgular görünür kalırken loglar yeni veri sızıntısı yüzeyi oluşturmaz.

Gateway, uygulama ve data loader limitlerini beraber inceleyin. Gateway isteği kabul etse bile resolver fan-out veritabanını tüketebilir; uygulama timeout’u alt servis sorgularını durdurmayabilir. Query iptalinin bağlantı havuzuna ve alt servislere yayıldığını; limit aşımlarının tutarlı, ölçülebilir bir ret ürettiğini doğrulayın.

GraphQL API’yi kimlik, nesne yetkisi ve iş akışlarıyla birlikte değerlendirmek için API güvenliği değerlendirmemize bakabilirsiniz.