Web uygulamalarında oturum yönetimi: çerezler, JWT'ler ve yenileme belirteçleri

Oturum yönetimi gerçekte ne yapar

Oturum, biri giriş yaptıktan sonra uygulamanızın yanıtladığı bir sorudur: "Şu an kim oluyorsun?" Bu cevap güvenilir olduğunda, uygulama kullanıcının ne görebileceğine, neleri değiştirebileceğine ve hangi işlemlerin engellenmesi gerektiğine karar verir.

"Girişte kalmak" aynı zamanda bir güvenlik tercihidir. Kullanıcı kimliğinin ne kadar süre geçerli olacağını, kimlik kanıtının nerede saklanacağını ve o kanıt kopyalanırsa ne olacağını belirlersiniz.

Çoğu web uygulaması kurulumunda üç temel yapı taşı kullanılır:

• Cookie-based server sessions: tarayıcı bir çerez saklar ve sunucu her istekte oturumu arar.
• JWT access tokens: istemci imzalı bir belirteç gönderir, sunucu bunu veritabanı sorgusu olmadan doğrulayabilir.
• Refresh tokens: daha uzun ömürlü bir kimlik bilgisi olup yeni, kısa ömürlü erişim belirteçleri almak için kullanılır.

Bunlar birbirleriyle rekabet eden "üsluplar"dan çok aynı ödünleşimleri (hız vs kontrol, basitlik vs esneklik, "bunu şimdi iptal edebilir miyiz?" vs "kendiliğinden süresi doluyor mu?") çözmenin farklı yollarıdır.

Tasarımı değerlendirmek için faydalı bir bakış: bir saldırgan uygulamanızın kimlik kanıtı olarak ne sakladığını çalarsa (çerez ya da belirteç), ne yapabilir ve ne kadar süreyle yapabilir? Sunucu tarafı oturumlar, anında çıkış veya kilitlenme gibi güçlü sunucu tarafı kontrollere ihtiyaç duyduğunuzda genellikle avantajlıdır. JWT'ler hizmetler arası durumsuz doğrulamalar için uygundur, ancak hemen iptal gereksinimi olduğunda zorlaşırlar.

Hiçbir seçenek her alanda üstün değildir. Doğru yaklaşım tehdit modelinize, çıkış gereksinimlerinizin ne kadar sıkı olduğuna ve ekibinizin ne kadar karmaşıklığı sürdürebileceğine bağlıdır.

Doğru cevabı değiştiren tehdit modelleri

İyi oturum tasarımı "en iyi" belirteç türünden çok hangi saldırılara karşı hayatta kalmanız gerektiğine bağlıdır.

Bir saldırgan tarayıcı depolamasından (localStorage gibi) veri çalarsa, JWT erişim belirteçleri sayfa JavaScript'i tarafından kolayca okunabildiği için kolayca elde edilir. HttpOnly olarak ayarlanmış bir çerez farklıdır: normal sayfa kodu onu okuyamaz, dolayısıyla basit "belirteç alma" saldırıları zorlaşır. Ancak saldırgan cihazı ele geçirmişse (kayıp dizüstü, kötü amaçlı yazılım, ortak bilgisayar), çerezler yine tarayıcı profilden kopyalanabilir.

XSS (sitenizde çalışan saldırgan kodu) her şeyi değiştirir. XSS ile saldırgan bir şeyi çalmaya ihtiyaç duymayabilir; kurbanın zaten giriş yapmış oturumunu kullanarak eylemler gerçekleştirebilir. HttpOnly çerezler oturum gizlerini okumayı engellemeye yardımcı olur, ama saldırganın sayfadan istek yapmasını durdurmaz.

CSRF (farklı bir sitenin istenmeyen eylemler tetiklemesi) esas olarak tarayıcıların çerezleri otomatik eklemesi nedeniyle çerez tabanlı oturumları tehdit eder. Çerezlere güveniyorsanız, SameSite ayarları, anti-CSRF tokenleri ve durum değiştiren isteklerin dikkatli işlenmesi gibi net CSRF savunmalarına ihtiyacınız var. Authorization başlığında gönderilen JWT'ler klasik CSRF'ye karşı daha az açıktır, ancak JavaScript'in okuyabildiği bir yerde saklanırlarsa XSS'e açıktırlar.

Yeniden oynatma saldırıları (çalınmış kimlik bilgisinin yeniden kullanılması), sunucu tarafı oturumların parladığı yerdir: bir oturum kimliğini hemen geçersiz kılabilirsiniz. Kısa ömürlü JWT'ler tekrar oynatma süresini kısaltır, ancak belirteç geçerli olduğu sürece tekrar oynatmayı durdurmazlar.

Paylaşılan cihazlar ve kayıp telefonlar "çıkış yap"ı gerçek bir tehdit modeline çevirir. Kararlar genellikle şu sorulara dönüyor: bir kullanıcı diğer cihazlardan çıkış yaptırabilir mi, bunun etkisi ne kadar çabuk olmalı, bir refresh token çalınırsa ne olur ve "beni hatırla" oturumlarına izin veriyor musunuz? Birçok ekip ayrıca personel erişimine müşteri erişiminden daha katı standartlar uygular; bu da zaman aşımı ve iptal beklentilerini değiştirir.

Çerez oturumları: nasıl çalışır ve neyi korur

Çerez tabanlı oturumlar klasik kurulumdur. Girişten sonra sunucu bir oturum kaydı oluşturur (genellikle kullanıcı kimliği, oluşturulma zamanı ve sona erme gibi alanlarla birlikte bir ID). Tarayıcı yalnızca oturum ID'sini bir çerezde saklar. Her istekte tarayıcı o çerezi geri yollar ve sunucu oturumu arayıp kullanıcının kim olduğunu belirler.

Büyük güvenlik avantajı kontroldür. Oturum her seferinde sunucuda doğrulanır. Birini hemen çıkarmak istiyorsanız sunucu tarafı oturum kaydını silersiniz veya devre dışı bırakırsınız; o zaman kullanıcı çereze sahip olsa bile oturum hemen çalışmaz.

Korumanın büyük kısmı çerez ayarlarından gelir:

• HttpOnly: çerezin JavaScript tarafından okunmasını engeller.
• Secure: çerezin yalnızca HTTPS üzerinden gönderilmesini sağlar.
• SameSite: tarayıcının çerezi çapraz site isteklere ne zaman göndereceğini sınırlar.

Oturum durumunu nerede sakladığınız ölçeklemeyi etkiler. Uygulama belleğinde oturum tutmak basittir, ancak birden fazla sunucu çalıştırdığınızda veya sık yeniden başlatma yaptığınızda bozulur. Kalıcılık için bir veritabanı iyi çalışır. Birçok aktif oturum ve hızlı arama gerektiğinde Redis yaygındır. Önemli olan nokta aynı: sunucu her istekte oturumu bulup doğrulayabilmelidir.

Çerez oturumları, personel panoları veya bir yönetici rol değişikliğinden sonra anında çıkış gerektiren müşteri portalları gibi katı çıkış davranışına ihtiyaç duyduğunuzda güçlü bir uyum sağlar. Bir çalışan ayrıldığında, sunucu tarafı oturumlarını devre dışı bırakmak erişimi hemen sona erdirir; belirteçlerin süresinin dolmasını beklemeniz gerekmez.

JWT erişim belirteçleri: güçlü yanlar ve keskin kenarlar

JWT (JSON Web Token), kullanıcı hakkında birkaç iddia (kullanıcı ID'si, rol, tenant gibi) ve bir sona erme süresi taşıyan imzalı bir stringtir. API'niz imzayı ve sürenin dolup dolmadığını yerel olarak doğrular, veritabanına bakmadan isteği yetkilendirir.

Bu yüzden JWT'ler API-öncelikli ürünlerde, mobil uygulamalarda ve birden fazla hizmetin aynı kimliği doğrulaması gerektiği sistemlerde popülerdir. Birden çok backend örneğiniz varsa her biri aynı belirteci doğrulayabilir ve aynı sonuca ulaşabilir.

Güçlü yanları

JWT erişim belirteçleri hızlı kontrol edilir ve API çağrılarına eklenmesi kolaydır. Ön uç birçok uç noktayı çağırıyorsa, kısa ömürlü bir erişim belirteci akışı basit tutar: imzayı doğrula, kullanıcı kimliğini oku, devam et.

Örnek: bir müşteri portalı ayrı servislerde "Faturaları listele" ve "Profili güncelle" çağrıları yapıyor. Bir JWT müşteri ID'sini ve customer gibi bir rolü taşıyabilir; böylece her hizmet oturum sorgusu yapmadan isteği yetkilendirir.

Keskin kenarlar

En büyük ödün revokasyondur. Bir belirteç bir saat geçerli ise, genellikle kullanıcı "çıkış yap" düğmesine bassın veya bir yönetici hesabı devre dışı bıraksın, o saat boyunca her yerde geçerli kalır; ekstra sunucu tarafı kontroller eklemediğiniz sürece.

JWT'ler ayrıca sıradan yollarla sızar. Yaygın hata noktaları localStorage (XSS bunu okuyabilir), tarayıcı belleği (kötü amaçlı uzantılar), loglar ve hata raporları, başlıkları yakalayan proxy'ler ve analiz araçları, ya da destek sohbetlerindeki veya ekran görüntülerindeki kopyalanmış belirteçlerdir.

Bu yüzden JWT erişim belirteçleri "sonsuz giriş" için değil kısa ömürlü erişim için daha uygundur. İçlerine hassas kişisel veri koymayın, süresini kısa tutun ve çalındığında belirtecin süresi dolana kadar kullanılabilir olacağını varsayın.

Yenileme belirteçleri: JWT kurulumlarını uygulanabilir kılmak

JWT erişim belirteçleri kısa ömürlü olacak şekilde tasarlanmıştır. Bu güvenlik için iyidir, ama pratik bir sorun yaratır: kullanıcıların her birkaç dakikada bir tekrar giriş yapmaması gerekir. Yenileme belirteçleri, eski erişim belirteci süresi dolduğunda uygulamanın arka planda yeni bir erişim belirteci almasını sağlar.

Yenileme belirtecini nerede sakladığınız, erişim belirtecinin saklandığından daha da önemlidir. Tarayıcı tabanlı bir web uygulamasında en güvenli varsayılan HttpOnly, Secure çerez kullanmaktır, böylece JavaScript bunu okuyamaz. LocalStorage uygulaması daha kolaydır ama XSS açıkları varsa daha kolay çalınır. Tehdit modeliniz XSS'i içeriyorsa, uzun ömürlü gizleri JavaScript'in erişebileceği yerlere koymaktan kaçının.

Rotasyon, yenileme belirteçlerini gerçek sistemlerde kullanılabilir kılan şeydir. Aynı yenileme belirtecini haftalarca kullanmak yerine her kullanımda onu değiştirirsiniz: istemci yenileme belirteci A sunar, sunucu yeni bir erişim belirteci ve yeni bir yenileme belirteci B verir ve A geçersiz olur.

Basit bir rotasyon düzeni genellikle şu kuralları içerir:

• Erişim belirteçlerini kısa tutun (dakikalar, saatler değil).
• Yenileme belirteçlerini sunucu tarafında durum ve son kullanım zamanı ile saklayın.
• Her yenilemede rotasyon yapın ve önceki belirteci geçersiz kılın.
• Mümkünse yenileme belirteçlerini bir cihaza veya tarayıcıya bağlayın.
• Kötüye kullanımı soruşturabilmek için yenileme olaylarını kaydedin.

Yeniden kullanım tespiti ana alarmdır. Yenileme belirteci A zaten değiş tokuş edildiyse ama daha sonra tekrar görürseniz, kopyalandığını varsayın. Yaygın yanıt tüm oturumu (çoğu zaman o kullanıcı için tüm oturumları) iptal etmek ve yeniden giriş gerektirmektir; çünkü hangi kopyanın gerçek olduğunu bilemezsiniz.

Çıkış için sunucunun uygulayabileceği bir şeye ihtiyacınız vardır. Bu genellikle yenileme belirteçlerini iptal eden bir oturum tablosu (veya iptal listesi) anlamına gelir. Erişim belirteçleri hâlâ süresi dolana kadar çalışabilir, ama bunu küçük tutarak pencereyi sınırlayabilirsiniz.

Çıkış gereksinimleri ve gerçekte ne uygulanabilir

Çıkış basit gibi görünür ta ki onu tanımlayana kadar. Genelde iki farklı istek olur: "bu cihazdan çıkış yap" (bir tarayıcı veya telefon) ve "her yerden çıkış yap" (cihazlar arasındaki tüm aktif oturumlar).

Ayrıca zamanlama sorunu vardır. "Anında çıkış" demek, uygulamanın kimliği hemen reddetmesi demektir. "Süre dolduğunda çıkış" demek, uygulamanın mevcut oturum veya belirteç doğal olarak sona erdiğinde kabul etmemesidir.

Çerez tabanlı oturumlarda anında çıkış kolaydır çünkü sunucu oturuma sahiptir. Çerezi istemciden siler ve sunucu tarafı oturum kaydını geçersiz kılar veya silersiniz. Daha önce çerez değeri kopyalanmışsa sunucu reddi çıkışı gerçekten uygular.

Sadece JWT'ye dayanan doğrulamada (durumsuz erişim belirteçleri ve sunucu kontrolü yoksa) gerçek anlamda anında çıkışı garanti edemezsiniz. Çalınmış bir JWT, sunucunun nerede "bu belirteç iptal edildi" diye kontrol edebileceği bir yer olmadığı için süresi dolana kadar geçerlidir. Bir denylist ekleyebilirsiniz ama o zaman durum tutuyor ve onu kontrol ediyorsunuz demektir; bu da orijinal sadeliğin çoğunu ortadan kaldırır.

Pratik bir desen, erişim belirteçlerini kısa ömürlü tutmak ve çıkışı yenileme belirteçleri üzerinden uygulamaktır. Erişim belirteci birkaç dakika boyunca çalışmasına izin verilir, ama oturumu canlı tutan yenileme belirtecidir. Bir dizüstü çalındığında, yenileme belirteci ailesini iptal etmek gelecekteki erişimi hızlıca keser.

Kullanıcılara gerçekte vaat edebilecekleriniz:

• Bu cihazdan çıkış yap: o oturumu veya yenileme belirtecini iptal edin ve yerel çerezleri veya depolamayı silin.
• Her yerden çıkış yap: hesabın tüm oturumlarını veya tüm yenileme belirteç ailelerini iptal edin.
• "Anında" etki: sunucu oturumlarında garanti edilir, erişim belirteçlerinde süresine kadar en iyi çaba gösterilir.
• Zorunlu çıkış olayları: şifre değişikliği, hesap devre dışı bırakma, rol düşürme.

Şifre değişiklikleri ve hesap devre dışı bırakmada "kullanıcının çıkış yapmasını beklemeyin." Hesap genelinde bir oturum sürümü (veya "belirtecin geçerli olduğu tarih" zaman damgası) saklayın. Her yenilemede (ve bazen her istekte) bunu karşılaştırın. Değiştiyse, reddedin ve yeniden giriş isteyin.

Adım adım: uygulamanız için bir oturum yaklaşımı seçmek

Oturum tasarımını basit tutmak istiyorsanız önce kurallarınızı belirleyin, sonra mekanikleri seçin. Çoğu sorun ekiplerin popüler diye JWT veya çerez seçmesiyle başlar; aslında risklere ve çıkış gereksinimlerine uyup uymadığına bakılmamıştır.

Önce kullanıcıların nerelerde oturum açtığını listeleyin. Bir tarayıcı uygulaması, yerel mobil uygulama, dahili yönetici aracı veya bir ortak entegrasyon gibi farklı istemciler farklı davranır. Her biri güvenle nelerin saklanabileceğini, girişlerin nasıl yenilendiğini ve "çıkış"ın ne anlama gelmesi gerektiğini değiştirir.

Çoğu ekip için işe yarayan pratik sıra:

1. İstemcilerinizi listeleyin: web, iOS/Android, dahili araçlar, üçüncü taraf erişim.
2. Varsayılan bir tehdit modeli seçin: XSS, CSRF, çalınmış cihaz.
3. Çıkışın neyi garanti etmesi gerektiğine karar verin: sadece bu cihaz, tüm cihazlar, yönetici zorlaması.
4. Bir temel desen seçin: çerez tabanlı oturumlar (sunucu hatırlar) veya erişim belirteci + yenileme belirteci.
5. Zaman aşımı ve yanıt kurallarını belirleyin: boşta kalma vs mutlak sona erme ve şüpheli yeniden kullanım gördüğünüzde ne yapacağınız.

Sonra sisteminizin verdiği kesin sözleri belgeleyin. Örnek: "Web oturumları 30 dakika boşta kalma veya 7 gün mutlak süre sonra sona erer. Yönetici 60 saniye içinde zorunlu çıkış yaptırabilir. Kayıp telefon uzaktan devre dışı bırakılabilir." Bu cümleler kullandığınız kütüphaneden daha önemlidir.

Son olarak, deseninize uygun izleme ekleyin. Belirteç kurulumları için güçlü bir sinyal yenileme belirteci yeniden kullanımını tespit etmektir (aynı yenileme belirtecinin tekrar kullanılması). Bunu muhtemel hırsızlık olarak ele alın, oturum ailesini iptal edin ve kullanıcıyı bilgilendirin.

Hesap ele geçirmeye yol açan yaygın hatalar

Çoğu hesap ele geçirme "akıllı hack" değildir. Bunlar tahmin edilebilir oturum hatalarının açtığı basit zaferlerdir. İyi oturum yönetimi, saldırganlara kimlik bilgilerini çalmak veya yeniden oynamak için kolay bir yol vermemekle ilgilidir.

Yaygın tuzaklardan biri erişim belirteçlerini localStorage'a koymak ve hiç XSS olmayacağını ummaktır. Sayfanızda herhangi bir betik çalışırsa (kötü bağımlılık, enjekte edilmiş widget, saklı yorum), localStorage'ı okuyup belirteci dışarı gönderebilir. JavaScript'in okuyamadığı HttpOnly çerezler bu riski azaltır.

Başka bir tuzak, yenileme belirteçlerinden kaçınmak için JWT'leri uzun ömürlü yapmak. 7 günlük bir erişim belirteci, sızarsa 7 günlük yeniden kullanım penceresidir. Kısa erişim belirteci + iyi yönetilen yenileme belirteci, özellikle yenileme kesildiğinde kötüye kullanımı zorlaştırır.

Çerezlerin kendi tehlikesi: CSRF savunmalarını unutmak. Çerez oturumları kullanıp durum değiştiren istekleri CSRF koruması olmadan kabul ederseniz, kötü amaçlı bir site giriş yapmış tarayıcıyı geçerli istekler göndermeye kandırabilir.

Olay incelemelerinde sık görülen diğer hatalar:

• Yenileme belirteçleri hiç dönüştürülmüyor veya dönüştürülüyor ama yeniden kullanım tespiti yok.
• Birden fazla giriş yöntemi destekleniyor (çerez oturumu ve bearer token) ama sunucunun "hangisi geçerli" kuralı belirsiz.
• Belirteçler loglara giriyor (tarayıcı konsolu, analiz olayları, sunucu istek logları) ve oradan kopyalanıp saklanıyor.

Somut bir örnek: bir destek görevlisi "hata günlüğü"nü bir ticket'e yapıştırır. Günlük Authorization başlığını içeriyordur. Ticket erişimi olan herkes o belirteci tekrar kullanıp görevliymiş gibi işlem yapabilir. Belirteçleri parolalar gibi değerlendirin: yazdırmayın, saklamayın ve kısa ömürlü tutun.

Yayına almadan önce hızlı kontroller

Çoğu oturum hatası karmaşık kriptodan değil. Eksik bir bayrak, çok uzun yaşayan bir belirteç veya yeniden kimlik doğrulama gerektirmesi gereken bir endpoint gibi küçük şeyler yüzünden olur.

Yayın öncesinde, bir saldırganın çalınmış bir çerez veya belirteçle ne yapabileceğine odaklanan kısa bir kontrol yapın. Bu, tüm kimlik doğrulama düzeninizi yeniden yazmadan güvenliği hızlıca artırmanın en hızlı yollarından biridir.

Yayın öncesi kontrol listesi

Bu kontrolleri staging'de, sonra üretim ayarlarında tekrarlayın:

• Erişim belirteçlerini kısa tutun (dakikalar) ve API'nin gerçekten süresi dolduktan sonra reddettiğini doğrulayın.
• Yenileme belirteçlerini parolalar gibi ele alın: mümkünse JavaScript'in okuyamadığı yerde saklayın, yalnızca yenileme endpoint'ine gönderin ve her kullanımda rotasyon yapın.
• Kimlik doğrulama için çerez kullanıyorsanız bayrakları doğrulayın: HttpOnly açık, Secure açık ve SameSite kasıtlı ayarlanmış. Ayrıca çerez kapsamının (domain ve path) gereğinden geniş olmadığını doğrulayın.
• Eğer çerezler istekleri kimliklendiriyorsa CSRF savunmaları ekleyin ve durum değiştiren uç noktaların CSRF sinyali olmadan başarısız olduğunu doğrulayın.
• İptal gerçek olsun: şifre sıfırlama veya hesap devre dışı bırakmadan sonra mevcut oturumlar hızla çalışmamalıdır (sunucu tarafı oturum silme, yenileme belirteci iptal etme veya bir "oturum sürümü" kontrolü ile).

Bunlardan sonra çıkış vaatlerinizi test edin. "Çıkış yapmak" genellikle "yerel oturumu kaldırmak" demektir, ama kullanıcılar daha fazlasını bekler.

Pratik bir test: bir dizüstü ve bir telefonda oturum açın, sonra şifreyi değiştirin. Dizüstü bir sonraki istekte oturumdan atılmalı, saatler sonra değil. "Her yerden çıkış yap" özelliği ve cihaz listesi sunuyorsanız, her cihazın iptal edilebilen ayrı bir oturum veya yenileme belirteci kaydına denk geldiğini doğrulayın.

Örnek: personel hesapları ve zorunlu çıkış gerektiren bir müşteri portalı

Küçük bir işletmeyi hayal edin: web müşteri portalı (müşteriler faturaları kontrol eder, ticket açar) ve saha personeli için mobil uygulama (görevler, notlar, fotoğraflar). Personel bazen sinyalin olmadığı bodrumlarda çalışıyor, bu yüzden uygulamanın bir süre çevrimdışı da çalışması gerekir. Yöneticiler ayrıca büyük kırmızı bir buton istiyor: tablet kaybolursa veya bir taşeron ayrıldığında oturumu zorla kapatabilsinler.

Buna üç yaygın tehdidi ekleyin: vanlardaki ortak tabletler (biri çıkış yapmayı unutuyor), oltalama (personel kimlik bilgilerini sahte bir sayfaya yazıyor) ve portalda ara sıra bir XSS açığı (bir betik tarayıcıda çalışıp alabileceği her şeyi çalıyor).

Burada pratik bir kurulum, kısa ömürlü erişim belirteçleri artı rotasyonlu yenileme belirteçleri ve sunucu tarafı iptaldir. Bu size hızlı API çağrıları ve çevrimdışı tolerans verirken yöneticilerin oturumları kesmesine de olanak tanır.

Böyle görünebilir:

• Erişim belirteci süresi: 5 ila 15 dakika.
• Yenileme belirteci rotasyonu: her yenilemede yeni bir yenileme belirteci verilir ve eski geçersiz kılınır.
• Yenileme belirteçlerini güvenli saklayın: web'de yenileme belirtecini HttpOnly, Secure çerezde; mobilde işletim sistemi güvenli deposunda saklayın.
• Yenileme belirteçlerini sunucu tarafında izleyin: bir token kaydı tutun (kullanıcı, cihaz, veriliş zamanı, son kullanım, iptal bayrağı). Rotasyon sonrası bir token yeniden kullanılırsa hırsızlık olarak ele alın ve zinciri iptal edin.

Zorunlu çıkışı uygulanabilir kılarsınız: yönetici o cihazın (veya kullanıcının tüm cihazlarının) yenileme belirteci kaydını iptal eder. Çalınan cihaz mevcut erişim belirtecini süresi dolana kadar kullanmaya devam edebilir, ama yenisini alamaz. Böylece erişimi tamamen kesmenin maksimum zamanı erişim belirteci ömrünüzdür.

Kayıp cihaz için kuralı açıkça belirtin: "10 dakika içinde uygulama eşitlemeyi durduracak ve tekrar giriş isteyecektir." Çevrimdışı çalışma cihazda kalabilir, ama bir sonraki çevrimiçi eşitleme giriş gerektirene kadar başarısız olmalıdır.

Sonraki adımlar: uygulayın, test edin ve sürdürülebilir tutun

"Çıkış"ın ne anlama geldiğini ürün dilinde yazın. Örneğin: "Çıkış yapmak bu cihazın erişimini kaldırır," "Her yerden çıkış yapmak tüm cihazları 1 dakika içinde atar," veya "Şifre değiştirmek diğer oturumları kapatır." Bu vaatler, sunucu tarafı oturum durumuna, iptal listelerine veya kısa ömürlü belirteçlere ihtiyaç duyup duymadığınızı belirler.

Vaatleri küçük bir test planına çevirin. Belirteç ve oturum hataları genellikle düzgün senaryolarda görünmez, ama gerçek hayatta (uyku modu, dalgalı ağlar, birden fazla cihaz) başarısız olur.

Pratik test kontrol listesi

Dağınık durumları kapsayan testler çalıştırın:

• Süre dolma: erişim belirteci veya oturum süresi dolduğunda erişim kesiliyor mu, tarayıcı açık kalsa bile.
• İptal: "her yerden çıkış" sonrası eski kimlik bilgisi bir sonraki istekte başarısız oluyor mu.
• Rotasyon: yenileme belirteci rotasyonu yeni bir yenileme belirteci veriyor ve eskisini geçersiz kılıyor mu.
• Yeniden kullanım tespiti: eski bir yenileme belirtecinin tekrar oynatılması bir kilitlenme veya kapanış tetikliyor mu.
• Çoklu cihaz: "sadece bu cihaz" vs "tüm cihazlar" kuralları uygulamada ve kullanıcı arayüzünde eşleşiyor mu.

Testlerden sonra ekibinizle basit bir saldırı prova yapın. Üç senaryo seçin ve uçtan uca ilerleyin: token okuyabilen bir XSS açığı, çerez oturumlarına karşı bir CSRF denemesi ve aktif oturuma sahip çalınmış bir telefon. Tasarımınızın vaatlerle örtüşüp örtüşmediğini kontrol ediyorsunuz.

Hızlı hareket etmeniz gerekirse, özel yapıştırıcı kodu azaltın. AppMaster (appmaster.io) üretime hazır bir backend ile web ve native mobil uygulamalar üreten bir seçenek olduğunda kurallarınızı (süreler, rotasyon, zorunlu çıkış) istemciler arasında tutarlı tutabilirsiniz.

Lansmandan sonra bir takip incelemesi planlayın. Gerçek destek ticket'larını ve olayları kullanarak zaman aşımı, oturum limitleri ve "her yerden çıkış" davranışını ayarlayın, sonra aynı kontrol listesini yeniden çalıştırarak düzeltmelerin geri dönmediğinden emin olun.