MongoDB ve Node.js API Performans Güvenliği

MongoDB Performansı Bir Güvenlik Meselesidir

MongoDB optimizasyonu çoğu ekipte yalnızca performans konusu olarak görülür. Yavaş sorgu, yüksek CPU veya memory pressure yaşandığında indeks eklenir ve problem çözülmüş sayılır. Fakat modern backend sistemlerinde veritabanı performansı doğrudan güvenlik meselesidir.

Bir saldırganın API'nizi kırması için her zaman auth bypass bulması gerekmez. Bazen tek yapması gereken pahalı sorguları tekrar tekrar tetiklemek, limitsiz pagination kullanmak veya regex tabanlı aramayı kötüye kullanmaktır. Sonuçta sistem çalışır görünür ama veritabanı kaynakları tükenir, kullanıcı deneyimi bozulur ve bulut maliyeti yükselir.

En Sık Görülen MongoDB Riskleri

Node.js API'lerde MongoDB kaynaklı riskler genellikle şu kalıplarda karşımıza çıkar:

Filtrelenmemiş kullanıcı girdisiyle dinamik query üretimi
Limitsiz find() ve büyük response döndürme
Offset pagination ile büyüyen veri setlerinde yüksek maliyet
Yanlış veya eksik compound index
Regex aramaların sınırsız çalışması
Aggregation pipeline içinde tenant filtresinin geç uygulanması
Cache key içinde tenant veya authorization bağlamının unutulması

Bu hataların bazıları veri sızıntısına, bazıları ise kaynak tüketimi saldırısına yol açar.

Tenant Filtresi Query'nin Sonunda Değil Başında Olmalı

Çok kiracılı SaaS backend'lerinde MongoDB aggregation kullanırken en tehlikeli hata, tenant filtresini pipeline'ın ilerleyen adımlarına bırakmaktır. Eğer $lookup, $unwind veya pahalı hesaplama tenant filtresinden önce çalışıyorsa sistem gereksiz veri işler. Daha kötüsü, yanlış join veya projection ile başka tenant verisi response içine sızabilir.

Güvenli yaklaşım şudur:

const pipeline = [
  { $match: { tenantId: session.tenantId, status: "active" } },
  { $sort: { createdAt: -1 } },
  { $limit: 100 },
  // diğer aşamalar burada
];

Tenant sınırı uygulama kodunda değil, query'nin ayrılmaz parçası olmalıdır.

Pagination ve Export Ayrı Tasarlanmalı

API endpoint'i hem UI listesi hem de full export için kullanılıyorsa risk artar. UI için 50 kayıt yeterliyken export için milyonlarca satır işlenebilir. Bu iki kullanım aynı endpoint ve aynı permission modeliyle çalışmamalıdır.

Sağlıklı tasarımda:

UI listeleri cursor-based pagination kullanır.
Maksimum page size backend tarafından sabitlenir.
Export işlemleri async job olarak çalışır.
Export yetkisi ayrı permission ister.
Export edilen veri maskeleme ve audit log kontrolünden geçer.

Bu ayrım yoksa saldırgan list endpoint'ini veri çekme ve maliyet üretme aracına çevirebilir.

Regex ve Arama Endpoint'leri

MongoDB regex sorguları özellikle kullanıcı girdisiyle birleştiğinde tehlikelidir. Çok geniş regex, indeks kullanamayan arama ve case-insensitive pattern'ler veritabanını kolayca yorabilir. Arama endpoint'leri için minimum karakter limiti, allowlist alanlar, timeout ve indeks stratejisi net olmalıdır.

Arama ihtiyacı büyüdüyse MongoDB üzerinde her şeyi regex ile çözmek yerine dedicated search altyapısı, materialized view veya sınırlı autocomplete modeli düşünülmelidir.

Observability Olmadan Optimizasyon Kördür

Backend ekibi şu metrikleri görmüyorsa MongoDB güvenliği eksiktir:

Query latency percentiles
Collection scan oranı
Endpoint bazlı DB time
Tenant bazlı sorgu hacmi
Aggregation memory kullanımı
Timeout ve killed operation sayısı
Export job maliyeti

Bu metrikler yalnızca performans iyileştirme için değil, saldırı tespiti için de kullanılır.

Eresus Yaklaşımı

Eresus Security, backend güvenlik testlerinde MongoDB sorgularını iş mantığı ve kaynak tüketimi açısından inceler. BOLA, tenant isolation, slow query abuse, export sızıntısı ve aggregation kaynaklı maliyet saldırıları aynı test planında ele alınır.

Operasyonel İnceleme Checklisti

Object ownership kontrolü her endpointte var mı?
Tenant ID sunucu tarafında doğrulanıyor mu?
JWT kapsamı gerçek yetkilendirme yerine kullanılmıyor mu?
Webhook ve async job aynı yetki modelini izliyor mu?
Rate limit maliyetli aksiyonlara göre ayrıldı mı?
Admin ve düşük yetkili kullanıcı çapraz test edildi mi?
BOLA ve IDOR senaryoları kanıtla doğrulandı mı?
Provider token kapsamı daraltıldı mı?
Hata cevapları gereksiz veri sızdırıyor mu?
API dokümantasyonu gerçek davranışla uyumlu mu?
Kapsam net yazıldı mı?
Etkilenen varlık sahibi belli mi?
Test ortamı production etkisinden ayrıldı mı?
Kullanıcı rolleri doğru temsil ediliyor mu?
Hassas veri sınıfı tanımlandı mı?
Yetki sınırı teknik olarak doğrulandı mı?
Log kaynağı ve saklama süresi belli mi?
Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
İş etkisi teknik etkiden ayrı açıklandı mı?
Düzeltme sahibi belirlendi mi?
Retest kriteri yazıldı mı?
Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
Monitoring veya alert tarafında görünürlük var mı?
Olay müdahale adımı gerekiyorsa planlandı mı?
Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?