Skip to main content

> graphql_kalıcı_sorgular_ve_derinlik_sınırlandırma

GraphQL Kalıcı Sorgular ve Derinlik Sınırlandırma

Yüksek verimli canlı mimarilerde GraphQL Kalıcı Sorgular ve Derinlik Sınırlandırma yapısını nasıl doğru kurar ve yönetirsiniz?

ÖZET VE TEKNİK CEVAP

GraphQL kalıcı sorgular ve derinlik sınırlandırma, istemci sorgularını önceden onaylanmış şifreleme özetleriyle (hash) sınırlandırıp aşırı iç içe geçmiş sorguları reddederek üretim API'lerini DoS saldırılarından ve veritabanı kilitlenmelerinden korur.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

GraphQL ön yüz geliştiricilere sorgu esnekliği sunsa da, genel internete keyfi sorgu çalıştırıcısı açmak büyük güvenlik açıklarına yol açar. Bir saldırgan iç içe geçmiş döngüsel sorgular (`author { posts { author { posts { ... } } } }`) göndererek tek istekte milyonlarca join sorgusu tetikleyebilir. Üretimde derinlik sınırları ve Kalıcı Sorgular zorunlu kılınır.

2. Doğru Kullanım Senaryosu

Kalıcı Sorgular (Persisted Queries), GraphQL sorgu metinlerinin istemci derleme aşamasında SHA-256 ile özetlenip API Gateway üzerinde bir izin listesine kaydedildiği ve istemcinin çalışma zamanında yalnızca bu özeti (hash) gönderdiği bir güvenlik ve performans desenidir.

3. Prodüksiyon Arıza Modları

Derinlik sınırı veya karmaşıklık analizi olmadan ham GraphQL uç noktasını canlıya almak. Kimliği doğrulanmamış genel istemcilerin keyfi GraphQL mutasyonları çalıştırmasına izin vermek. Kullanıcıların tarayıcı konsolundan sorguları değiştirmesini önlemek için yalnızca kod sıkıştırmaya (minification) güvenmek.

4. Teşhis ve Telemetri Sinyalleri

aşırı iç içe geçmiş kötü niyetli GraphQL sorgusu veritabanını çökertir, sınırsız döngüsel ilişki sorgusu sunucuda bellek tükenmesine yol açar, devasa ham GraphQL sorgu metinlerinin bant genişliğini şişirmesi

5. Önleme ve Mimari Bariyerler

Yüksek trafikli okuma sorguları için HTTP GET isteklerinde CDN önbelleklemesi destekleyen Otomatik Kalıcı Sorguları (APQ) etkinleştirin. Sıkı derinlik sınırları (genellikle 5-7 seviye) koyun ve tüm liste alanlarına sayfalama çarpan maliyeti atayın. Otomatik şema taramasını önlemek için genel üretim ortamlarında introspection (`__schema` / `__type`) özelliğini kapatın.

6. Mimari Ödünleşimler (Trade-offs)

Kalıcı sorgular ve derinlik analizi olmadığında, açık bir GraphQL uç noktası veritabanından sınırsız veri çekme proxy'sine dönüşür; saldırganlar 2 KB'lık tek bir istekle sunucu CPU'sunu tüketebilir.

Vaka İncelemesi (TinyCTO Örneği)

Üretim ortamında GraphQL güvenliği çok katmanlı bir savunma gerektirir: 1. **Sorgu Derinlik Sınırı:** Sorgu çalıştırılmadan önce Soyut Sözdizimi Ağacı (AST) taranır ve azami derinlik hesaplanır. Belirlenen sınırı (örn. derinlik > 6) aşan istekler tek bir veritabanı satırı dahi okunmadan HTTP 400 ile reddedilir. 2. **Sorgu Karmaşıklık ve Maliyet Analizi:** Şemadaki her alana karmaşıklık puanı atanır (skaler = 1, sayfalı liste = `1 * limit`). Toplam puan bütçeyi (örn. azami maliyet 1000) aşarsa istek iptal edilir. 3. **Kalıcı Sorgu İzin Listesi (Safe Mode):** Canlı ortamda GraphQL sunucusu 'yalnızca izin verilenler' moduna alınır. Dinamik metin sorguları tamamen engellenir; sunucu hafızasında veya Redis'te karşılığı olmayan `sha256Hash` istekleri doğrudan kenarda düşürülür.

İnteraktif Konsept Alıştırmaları

2 Alıştırma
Q1

Kısıtlanmamış canlı GraphQL uç noktalarının temel güvenlik açığı nedir?

Üstel veritabanı join'leri tetikleyen keyfi iç içe ve döngüsel sorgular yoluyla sunucuda CPU tükenmesi ve DoS yaratılması.
Q2

Kalıcı Sorgular (Persisted Queries), GraphQL POST isteklerini nasıl önbelleklenebilir HTTP GET isteklerine dönüştürür?

Büyük sorgu metnini URL parametresi olarak iletilen kısa bir hash ile değiştirerek (`?extensions=...`), CDN'lerin yanıtları önbelleğe almasını sağlar.

GraphQL Kalıcı Sorgular ve Derinlik Sınırlandırma — Sıkça Sorulan Sorular

Bir saldırgan 20 seviye iç içe geçmiş alan (`user { friends { friends { ... } } }`) içeren bir istek gönderiyor. Hangi mekanizma veritabanı tek bir SQL çalıştırmadan önce bu isteği engeller?

AST Sorgu Derinlik Sınırlandırması (Query Depth Limiting). AST Sorgu Derinlik Sınırı, sorgu ağacını analiz ederek izin verilen derinliği aşan istekleri resolver katmanına girmeden anında reddeder.

Genel canlı ortamlarda GraphQL introspection (`__schema` / `__type`) özelliğini kapatmak neden standart bir en iyi uygulamadır?

Kötü niyetli kişilerin tüm veri modelinizi, iç alan adlarını ve kullanım dışı uç noktaları otomatik olarak haritalandırmasını önlemek için. Introspection API şemanızın tüm planını dışarı açar. Canlıda kapatılması saldırganların belgelenmemiş alanları ve iç servis yapılarını keşfetmesini zorlaştırır.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • GraphQL kalıcı sorgular ve derinlik sınırlandırma, istemci sorgularını önceden onaylanmış şifreleme özetleriyle (hash) sınırlandırıp aşırı iç içe geçmiş sorguları reddederek üretim API'lerini DoS saldırılarından ve veritabanı kilitlenmelerinden korur.
  • Kalıcı Sorgular (Persisted Queries), GraphQL sorgu metinlerinin istemci derleme aşamasında SHA-256 ile özetlenip API Gateway üzerinde bir izin listesine kaydedildiği ve istemcinin çalışma zamanında yalnızca bu özeti (hash) gönderdiği bir güvenlik ve performans desenidir.

Yaygın Yanılgılar

  • Derinlik sınırı veya karmaşıklık analizi olmadan ham GraphQL uç noktasını canlıya almak.

Karar Kılavuzu & Önceliklendirme

Kalıcı sorgular ve derinlik analizi olmadığında, açık bir GraphQL uç noktası veritabanından sınırsız veri çekme proxy'sine dönüşür; saldırganlar 2 KB'lık tek bir istekle sunucu CPU'sunu tüketebilir.

Doğrulanmış Kaynaklar & Referanslar