1. GİRİŞ

Oturum (session) güvenliği, modern web ve mobil uygulamaların en kritik güvenlik alanlarından biridir. Bir kullanıcının kimlik doğrulandıktan sonra sistemle kurduğu süreklilik, uygulamanın erişim kontrolü ve kullanıcı deneyimi için hayati önemdedir. Ancak yanlış tasarlanmış veya yetersiz korunmuş oturum yönetimi, hesap ele geçirilmesine (account takeover), veri sızıntısına ve lateral hareketlere yol açabilir. Bu yazı, session güvenliğinin neden bugün daha önemli olduğunu, hangi problemlere çözüm ürettiğini ve mühendislerin uygulamada neleri kaçırdığını detaylı şekilde ele alır.

Neden bugün önemli?

• SPA'ler, mobil uygulamalar ve API ekonomik ortamda oturum yönetimi farklı şekillerde uygulanıyor; yanlış tercihler ciddi güvenlik açıklarına sebep olabiliyor.
• XSS, CSRF, token leakage ve man‑in‑the‑middle saldırıları gibi modern vektörler oturum güvenliğini tehdit ediyor.
• Regülasyonlar ve kullanıcı mahremiyeti gereksinimleri, oturum boyunca veri kullanımının sınırlandırılmasını ve izlenmesini zorunlu kılıyor.

Kimler için önemli?

• Backend ve frontend geliştiricileri — session token üretimi ve doğrulama mekanizmaları tasarlayanlar
• Güvenlik mühendisleri ve DevSecOps — XSS/CSRF, token theft mitigasyonları
• Platform mühendisleri — dağıtık session management, sticky sessions, cache/DB politikaları
• Ürün yöneticileri — kullanıcı deneyimi ile güvenlik dengesi

2. KAVRAMSAL TEMELLER

2.1 Oturum nedir?

Oturum, bir kullanıcının kimlik doğrulandıktan sonra sistemle kurduğu sürekliliktir. Teknik olarak oturum; sunucunun veya client'in taşıdığı ve kimlik ile ilişkilendirilen bir referans (session id, token) aracılığıyla tanımlanır. Oturum yönetimi, bu referansların güvenli yaratılması, depolanması, doğrulanması, yenilenmesi ve sonlandırılmasını kapsar.

2.2 Temel bileşenler

• Session identifier: Sunucuda veya token içinde taşıyan benzersiz anahtar (ör. session id, JWT).
• Storage: Session state'in saklandığı yer — in‑memory cache (Redis), database veya tamamen stateless token'lar (JWT).
• Transport: Session bilgisi istemci‑sunucu arasında iletilirken kullanılan kanal (cookie, Authorization header).
• Lifecycle management: Timeout, idle timeout, refresh, revocation gibi mekanizmalar.

2.3 Terminoloji

• Idle timeout: Kullanıcının hareketsiz olduğu sürede oturumun sona ermesi.
• Absolute timeout: Oturumun toplam süresinin maksimum sınırı.
• Session fixation: Saldırganın kullanıcıya önceden belirlenmiş session id ataması ve kullanıcının bu id ile oturum açmasının sağlanması.
• Session hijacking: Oturum id veya token'ın ele geçirilmesiyle oturumun çalınması.
• Token rotation: Token'ların kullanım sırasında yenilenmesi ve eskilerinin iptal edilmesi.

3. NASIL ÇALIŞIR? — OTURUM YÖNETİMİNİN TEKNİK MİMARİSİ

3.1 Stateful vs Stateless yaklaşımlar

Oturum yönetiminde iki ana yaklaşım vardır: stateful ve stateless. Statefull yaklaşımlarda sunucu her oturum için state tutar (session store — Redis, DB). Stateless yaklaşımlarda ise oturum bilgisi (kullanıcı id, izinler vb.) token içine (ör. JWT) gömülür ve sunucu bu token'ın imzasını doğrulayarak oturum bilgisini elde eder.

• Stateful (server‑side): Revocation ve token invalidation kolaydır; büyük ölçeklerde session store yönetimi, replication ve performans sorunları oluşabilir.
• Stateless (token‑based): Ölçeklenebilirlik avantajı vardır; ancak token revocation zorlaşır ve token içinde hassas bilgi bulundurmamak gerekir.

3.2 Transport ve saklama yöntemleri

En yaygın taşıyıcılar: cookie ve Authorization header (Bearer token). Cookie kullanımı HttpOnly ve Secure flag'ler ile birlikte olduğunda XSS riskini azaltır ancak CSRF riskine yol açabilir; Authorization header ise CSRF'den bağışık olsa da token'ların client storage (localStorage) içinde tutulması XSS'e karşı savunmasız hale getirir.

3.3 Oturum lifecycle akışı (örnek)

1. Kimlik doğrulama: Kullanıcı başarılı giriş yaptığında sistem session id veya access token üretir.
2. Depolama: Statefull ise session store'da maplenir; stateless ise token client'a verilir.
3. Transport: Token cookie veya header ile her istekle gönderilir.
4. Doğrulama: Server token'ı doğrular (imza, expiry, claims) veya session store'dan state'i alır.
5. Yenileme/rotation: Belirli aralıklarda refresh token ile yeni access token verilir; eski token'lar invalid yapılır.
6. Sonlandırma: Logout veya revocation mekanizmalarıyla session kapatılır ve store temizlenir.

4. GERÇEK DÜNYA KULLANIMLARI

4.1 Web uygulamaları (server‑rendered)

Klasik server‑rendered uygulamalarda cookie‑based session management yaygındır. HttpOnly ve Secure flag'leri, SameSite cookie politikası ile birlikte güçlü bir kombinasyon sunar. Büyük platformlarda session store olarak Redis kullanılır; replica ve eviction stratejileri kritik öneme sahiptir.

4.2 Tek Sayfa Uygulamaları (SPA) ve mobil

SPA'lerde token tabanlı authentication (JWT) sık kullanılır. Token'ların localStorage'a veya memory'e konumu, XSS risklerini etkiler. Mobil uygulamalarda ise platform secure storage (Android Keystore, iOS Keychain) kullanmak en doğru yaklaşımdır.

4.3 Mikroservisler ve dağıtık oturumlar

Mikroservis mimarisinde session state'i yönetmek için birkaç strateji vardır: central session store (Redis), token propagation (JWT), veya service mesh altında identity delegation. Service‑to‑service çağrılarında kısa ömürlü service tokens ve mTLS kullanımı tavsiye edilir.

4.4 Büyük ölçek örnekleri

Netflix, Amazon gibi büyük platformlar session yönetimini ölçeklenebilir ve izlenebilir şekilde kurgular: session metadata'ları merkezi telemetriye gönderilir, anomaly detection ile sıra dışı oturum davranışları tespit edilir ve otomatik kontenjan/limitler uygulanır.

5. TEHDİTLER VE SINIRLAMALAR

5.1 Yaygın saldırılar

• Session hijacking: Token veya cookie çalınması sonucu oturumun ele geçirilmesi (XSS, network sniffing, leaked logs).
• Session fixation: Saldırganın önceden belirlediği oturuma hedefi yönlendirmesi.
• Replay attacks: Yakalanan isteklerin yeniden oynatılması.
• Token theft via third‑party: SDK veya üçüncü taraf script'ler aracılığıyla token'ın sızdırılması.

5.2 Tasarım sınırlamaları

• Stateless token'larda revocation güçlüğü: Uzun ömürlü token'lar risk taşır.
• Session store ölçekleme: Çok yüksek eşzamanlı kullanıcı sayısında state yönetimi maliyetlidir.
• Cookie vs header trade‑offs: CSRF vs XSS riskleri arasında denge kurmak gerekir.

6. ALTERNATİFLER VE KARŞILAŞTIRMA

7. EN İYİ PRATİKLER

7.1 Production kullanımı

• Short‑lived access tokens: Kısa ömürlü access token'lar kullanın ve refresh token mekanizması ile yenileyin. Böylece token leakage etkisi sınırlanır.
• Refresh token rotation & revocation: Refresh token'ı her kullanımda yenileyin (rotate) ve eskilerini blacklistleyin; refresh endpoint'lerinde anomalous usage tespiti yapın.
• Secure cookie flags: Cookie kullanıyorsanız HttpOnly, Secure ve SameSite=strict/lax seçeneklerini doğru şekilde uygulayın.
• Token binding / mTLS: Mümkünse token'ları istemci kimliğine bağlayın veya service‑to‑service çağrılarda mTLS kullanın.
• Session invalidation at privilege change: Parola değişikliği, logout veya kritik permission değişikliklerinde tüm aktif oturumları invalid edin.

7.2 Performans ve ölçeklenebilirlik

• Session store için Redis gibi hızlı in‑memory çözümler kullanın; replication, persistence ve eviction politikalarını planlayın.
• Decision caching: yetkilendirme ve session doğrulama sonuçlarını kısa TTL ile cacheleyin; invalidation stratejisini belirleyin.
• Sticky sessions yerine token‑based yaklaşımlar ile load balancer üzerinde esnek ölçek sağlayın; ancak stateful ihtiyaç varsa sticky policies dikkatle yönetin.

7.3 Güvenlik operasyonları

• Telemetry: login success/failure, token refresh frequency, abnormal geographic logins, concurrent session counts gibi metrikleri izleyin.
• Alerting: anormal token reuse, repeated failed refresh veya multiple token usage aynı anda gibi pattern'ler için uyarı kurun.
• Penetration testing: session fixation, session hijacking, token replay ve XSS odaklı testleri rutinleştirin.

8. SIK YAPILAN HATALAR

• LocalStorage'a uzun ömürlü token koymak ve XSS riskini görmezden gelmek.
• Refresh token'ları rotate etmeyip uzun süreli kullanımına izin vermek.
• Session id'leri tahmin edilebilir şekilde üretmek veya zayıf entropy kullanmak.
• Session invalidation süreçlerini eksik planlamak (örn. password reset, logout sonrası session temizliği yapılmaması).
• Cookie flaglerini atlamak — HttpOnly ve Secure olmadan cookie kullanmak.

9. GELECEK TRENDLER

9.1 AI destekli anomaly detection

Makine öğrenmesi tabanlı modeller, normal oturum davranışını öğrenerek token reuse, credential stuffing ve account takeover denemelerini gerçek zamanlı tespit edebilecek. Bu, false positive oranlarını azaltarak daha duyarlı müdahaleler sağlar.

9.2 Continuous session validation

Statik token onaylarından öte, oturum boyunca bağlam‑temelli kontroller (device posture, IP changes, behavior scoring) ile sürekli kimlik doğrulama ve adaptive re‑auth süreçleri yaygınlaşacak.

9.3 Privacy‑preserving session analytics

Kullanıcı mahremiyetini koruyarak oturum telemetrisi ve anomaly detection sağlamak için privacy preserving teknikler (differential privacy, aggregation) daha fazla kullanılacak.

EK BÖLÜMLER

Sık Sorulan Sorular (FAQ)

1. 1. Cookie mi yoksa token mı tercih etmeliyim?

   Duruma bağlıdır. Eğer web uygulamanız server‑rendered ise HttpOnly cookie ile server‑side session güvenli bir tercihtir. SPA ve mobil uygulamalarda short‑lived token + refresh pattern daha elverişlidir. CSRF ve XSS risklerini dikkate alarak karar verin.

2. 2. JWT ile revocation nasıl yapılır?

   JWT'ler stateless olduğundan doğrudan revocation zordur. Çözüm olarak short‑lived access token + server‑side stored refresh token, veya token blacklist (revocation list) kullanabilirsiniz. Ayrıca token identifier (jti) ile revocation kontrolü yapılabilir.

3. 3. Refresh token'ları nerede saklamalıyım?

   Refresh token'ları HttpOnly, Secure cookie veya mobilde secure storage'da saklayın. Sunucu tarafında refresh token metadata'sını (fingerprint, client id) saklayarak anomalous usage tespit edin.

4. 4. Oturum sayısını sınırlamak mantıklı mı?

   Evet. Aynı kullanıcı için eşzamanlı oturum sayısını sınırlamak, credential stuffing veya otomatik takeover girişimlerini azaltır. Ancak UX etkisini değerlendirin ve istisna süreçleri planlayın.

5. 5. Session fixation nasıl önlenir?

   Kimlik doğrulama sırasında yeni bir session id oluşturun (rotate session id) ve eski id'yi invalid edin. Ayrıca login öncesi herhangi bir user‑provided session id'yi kabul etmeyin.

6. 6. Oturum süresini nasıl belirlemeliyim?

   Business requirement ve risk profilinize göre idle timeout ve absolute timeout belirleyin. Finansal uygulamalarda sıkı (kısa) timeout, düşük riskli uygulamalarda daha esnek timeout tercih edilebilir.

7. 7. Session telemetry için hangi metrikleri izlemeliyim?

   Concurrent sessions per user, failed auth attempts, token refresh frequency, geographic/ device changes, unusual request patterns ve token reuse metrikleri izlenmelidir.

8. 8. Legacy sistemlerde hızlı risk azaltma adımları nelerdir?

   MFA zorunluluğu getirin, session timeoutlarını kısaltın, cookie flag'lerini düzeltin, ve refresh token rotation ile uzun ömürlü token kullanımını azaltın. Uzun vadeli refactor planı başlatın.

Anahtar Kavramlar

• Session id: Oturumu temsil eden benzersiz anahtar.
• HttpOnly: JavaScript tarafından erişimi engelleyen cookie flag'i.
• SameSite: CSRF riskini azaltmaya yardımcı cookie politikası.
• Token rotation: Token'ların kullanım sırasında yenilenmesi ve eskilerin iptal edilmesi.
• Idle / Absolute timeout: Oturumun sona erdiği süre tipleri.

Öğrenme Yol Haritası

1. 0–1 ay: HTTP, cookie kavramları, TLS, temel auth/token mekanizmaları ve XSS/CSRF temel kavramlarını öğrenin.
2. 1–3 ay: JWT, session store (Redis) kullanımı, secure cookie flag'leri ve token rotation pratiklerini uygulayın.
3. 3–6 ay: Mikroservislerde token propagation, mTLS, service identity ve distributed session yönetimi üzerinde deneyim kazanın.
4. 6–12 ay: AI destekli anomaly detection, continuous authorization, privacy preserving analytics ve enterprise scale session governance uygulamalarını öğrenin.