Backend Auth ve Session Mimarisi

Modern backend sistemlerinde auth katmanı çoğu zaman "login endpoint'i çalışıyor mu?" seviyesinde ele alınır. Oysa gerçek güvenlik sorusu farklıdır: Kullanıcı sisteme girdikten sonra token ne kadar süre yaşar, hangi cihazla bağlanır, hangi tenant sınırında kalır, refresh akışı nasıl iptal edilir ve servisler bu kimliği nasıl doğrular?

Backend auth mimarisi sadece kimlik doğrulama değildir. Session yönetimi, yetkilendirme modeli, token yaşam döngüsü, cihaz bağlama, denetim kaydı ve servisler arası güven kararlarının birleşimidir. Bu yüzden auth hataları genellikle tek bir bug olarak değil, zincir halinde istismar edilen tasarım kusurları olarak karşımıza çıkar.

BOLA/IDOR zafiyetleri nesne seviyesinde yetki kontrolü eksikliğinden doğarken, AI uygulamalarında session yönetimi context taşıyan LLM akışlarında aynı sorunu daha karmaşık hale getirir. Backend ekibi için hedef, her endpoint'in sadece "kim bu?" değil, "bu kullanıcı bu nesne üzerinde bu işlemi bu bağlamda yapabilir mi?" sorusuna cevap verebilmesidir.

JWT Tek Başına Güvenlik Modeli Değildir

JWT, doğru kullanıldığında kullanışlı bir taşıyıcıdır; güvenlik modeli değildir. En sık görülen hata, token içinde role: admin veya tenantId gibi alanların varlığını yeterli sanmaktır. Backend tarafında her kritik aksiyon için server-side politika kontrolü yoksa token sadece saldırganın elindeki yetki iddiasına dönüşür.

Sağlıklı bir mimaride access token kısa ömürlü olur, refresh token ayrı saklanır, her refresh hareketi izlenir ve riskli davranışlarda session zinciri iptal edilebilir. Kullanıcı şifresini değiştirdiğinde, rolü geri alındığında veya cihazı riskli hale geldiğinde eski tokenların yaşamaya devam etmesi kabul edilebilir bir davranış değildir.

Token tasarımında şu kararlar açık olmalıdır:

• Access token kısa yaşar ve sadece gerekli claim'leri taşır.
• Refresh token rotasyon kullanır ve tekrar kullanım tespit edildiğinde zincir iptal edilir.
• Tenant, organization ve workspace sınırları backend policy katmanında doğrulanır.
• Admin işlemleri için step-up authentication veya yeniden doğrulama gerekir.
• Logout sadece client state temizliği değil, server-side session invalidation anlamına gelir.

RBAC Yetmez: Resource Policy Gerekir

RBAC, kullanıcının rolünü tanımlar; resource policy ise o kullanıcının belirli bir nesne üzerinde ne yapabileceğini belirler. SaaS backend'lerinde asıl sızıntılar genellikle RBAC eksikliğinden değil, resource ownership kontrolünün unutulmasından kaynaklanır.

Örneğin project:read yetkisi olan bir kullanıcı gerçekten her projeyi okuyabilir mi, yoksa sadece kendi organization içindeki projeleri mi? invoice:update yetkisi finans ekibi için yeterli mi, yoksa invoice'ın bağlı olduğu hesap, ülke, ödeme durumu ve approval seviyesi de kontrol edilmeli mi?

Bu kontroller route içinde dağınık if bloklarıyla bırakıldığında zamanla kırılır. Daha iyi yaklaşım, policy kararını merkezi ve test edilebilir bir katmana taşımaktır:

const decision = await policy.can(user).update(invoice, {
  tenantId: request.tenantId,
  source: "admin-panel",
});

if (!decision.allowed) {
  throw new ForbiddenError(decision.reason);
}

Bu tarz bir yapı sadece güvenliği artırmaz; test yazmayı, audit log üretmeyi ve ileride yeni rol eklemeyi de kolaylaştırır.

Session Binding ve Device Trust

Kurumsal uygulamalarda session, sadece token string'i değildir. Kullanıcının cihazı, IP paterni, MFA durumu, tarayıcı parmak izi, son riskli işlem zamanı ve organization politikası session kararının parçası olabilir.

Özellikle admin panelleri, ödeme akışları, API key üretimi ve veri export işlemleri için session binding kritiktir. Çalınmış bir tokenın farklı cihazdan, farklı ülkeden veya otomasyon benzeri davranışla kullanılması sessizce kabul edilmemelidir.

Backend tarafında düşük maliyetli ama etkili kontroller şunlardır:

• Yeni cihazda hassas işlem öncesi MFA istemek.
• API key, webhook secret ve export işlemlerini ayrı audit event olarak yazmak.
• Refresh token tekrar kullanımını yüksek riskli olay saymak.
• Session listesi ve "diğer cihazlardan çıkış" özelliği sunmak.
• Admin session'larını normal kullanıcı session'larından daha kısa tutmak.

Auth Testleri Sadece Login Testi Değildir

Backend testlerinde login başarı/başarısızlık senaryoları genellikle yazılır; asıl eksik yetki matrisi testleridir. Her kritik endpoint için en az üç farklı bağlam test edilmelidir: yetkili kullanıcı, aynı tenant içinde yetkisiz kullanıcı, farklı tenant içindeki kullanıcı.

Bu testler API seviyesinde yazılmadığında BOLA, privilege escalation ve cross-tenant data leak hataları production'a taşınır. Daha kötüsü, bu hataların çoğu monitoring sistemlerinde hata olarak görünmez; backend 200 OK döndürdüğü için sistem her şey normal sanır.

Eresus Yaklaşımı

Eresus Security, backend auth mimarisini sadece endpoint bazlı test etmez; session yaşam döngüsünü, RBAC/ABAC kararlarını, tenant izolasyonunu, refresh token zincirini ve admin iş akışlarını birlikte inceler. Backend Security Engineering çalışmalarında amaç bir liste dolusu teorik öneri üretmek değil, exploit edilebilir yetki zincirlerini kanıtlamak ve mühendislik ekibinin uygulayabileceği net düzeltme modelini çıkarmaktır.

Auth katmanınız büyüdükçe "şimdilik çalışıyor" yaklaşımı en pahalı teknik borca dönüşür. Eresus ile yapılacak backend auth review, hem güvenlik riskini hem de ilerideki geliştirme maliyetini görünür hale getirir.

Sık Sorulan Sorular

Bu konuda ilk adım ne olmalı?

Önce varlık, veri, kimlik ve iş etkisi birlikte haritalanmalıdır. Böylece güvenlik testi araç odaklı değil risk odaklı ilerler.

Profesyonel destek ne zaman gerekir?

Sistem üretime yakınsa, hassas veriye erişiyorsa veya bulgular birden fazla ekibi etkiliyorsa bağımsız güvenlik değerlendirmesi gerekir.

Uygulama Notları

API güvenliğinde en tehlikeli hata genellikle “endpoint çalışıyor” ile “endpoint doğru kişiye doğru veriyi veriyor” cümlelerini aynı sanmaktır. Yetkilendirme route seviyesinde değil, nesne ve iş kuralı seviyesinde doğrulanmalıdır.

Pratik inceleme için şu liste kullanılabilir:

• Her endpoint hangi business object üzerinde çalışıyor?
• Object owner, tenant ve rol kontrolü nerede yapılıyor?
• Aynı kullanıcı farklı tenant ID ile istek atınca ne oluyor?
• Webhook, queue veya async job tarafında aynı kontrol tekrar ediliyor mu?
• Rate limit sadece IP’ye mi, kullanıcıya ve maliyetli aksiyona da mı bağlı?

Karar Çerçevesi

SaaS ve fintech sistemlerinde küçük bir BOLA hatası veri sızıntısı, fraud ve regülasyon riskini aynı anda üretir. Bu yüzden API testi yalnızca Postman koleksiyonu çalıştırmak değil, sistemin iş kurallarını saldırgan gibi çaprazlamaktır.

Profesyonel Destek Eşiği

Aşağıdaki durumlardan biri varsa konu artık yalnızca iç kontrol maddesi değildir:

• Production verisi veya müşteri hesabı etkilenebilir.
• Yetki sınırı birden fazla rol ya da tenant üzerinden çalışır.
• Bulgu zincirlenince veri sızıntısı, kalıcı erişim veya operasyon kesintisi doğurabilir.
• Ekipte test kanıtını yeniden üretecek ve remediation önceliği çıkaracak zaman yoktur.

Eresus Security bu noktada bulguyu sadece raporlamakla kalmaz; istismar kanıtı, etki analizi, remediation sırası ve retest kriteriyle birlikte ele alır. Böylece ekip “ne açık?” sorusundan “neyi, hangi sırayla kapatmalıyız?” kararına geçer.

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?