HTTP'nin "Stateless" Doğası ve Durum Yönetimi Sorunu

Web geliştirmede karşılaşılan en temel mimari zorluk, kullanıcı etkileşimlerinde sürekliliği (persistence) sağlamaktır. Kullanıcı bir kez kimlik doğrulaması yapar, onlarca farklı sayfada gezinir ve her adımda sunucu tarafından tanınmayı bekler. Ancak web'in temelini oluşturan HTTP (Hypertext Transfer Protocol), doğası gereği "stateless" (durum bilgisiz) bir protokoldür.

Stateless protokol yapısında, sunucu ile istemci (client) arasındaki her bir İstek-Yanıt (Request-Response) döngüsü, bir öncekinden tamamen bağımsızdır. Sunucu, kendisine gelen bir isteğin daha önce kimlik doğrulaması yapmış bir kullanıcıdan mı, yoksa sisteme ilk kez erişen anonim bir cihazdan mı geldiğini kendi başına ayırt edemez. Teknik olarak, her yeni TCP bağlantısı veya HTTP isteği, sunucu için "yeni bir başlangıç" anlamını taşır.

Bu mimari yapı, sunucunun kaynak yönetimini kolaylaştırsa da (çünkü sunucu milyonlarca aktif bağlantının durumunu protokol seviyesinde takip etmek zorunda kalmaz), uygulama seviyesinde ciddi sorunlara yol açar:

• Kimlik Doğrulama Kaybı: Kullanıcı /login rotasında başarılı olsa bile, /dashboard rotasına geçtiği an sunucu bu başarıyı "unutur".

• Veri Tutarsızlığı: Sepete ürün ekleme veya form doldurma gibi çok adımlı işlemler, istekler arası veri aktarımı yapılamadığı için kesintiye uğrar.

İşte bu protokol seviyesindeki "hafıza yoksunluğunu" aşmak ve uygulama seviyesinde "stateful" (durum bilgisi olan) bir yapı kurmak için iki temel mekanizma geliştirilmiştir: Cookies (Çerezler) ve Sessions (Oturumlar). Çerezler bu durum bilgisini istemci tarafında (browser) muhafaza ederken, oturumlar bu veriyi sunucu tarafındaki güvenli bir depolama alanında tutarak her isteğin bir "kimlik kartı" ile gelmesini sağlar.

Cookies (Çerezler)

Çerezler, sunucu tarafından oluşturulan ve HTTP yanıt başlıkları (Response Headers) içindeki Set-Cookie komutuyla tarayıcıya emanet edilen küçük veri paketleridir. Tarayıcı bu paketleri belleğine veya diskine kaydeder; ilgili domain’e yapılan her yeni istekte, bu verileri Cookie başlığıyla sunucuya otomatik olarak geri gönderir.

Çerezlerin Güvenlik Parametreleri (Flags)

Bir çerezi sadece "isim=değer" çifti olarak görmek büyük bir yanılgıdır. Çerezlerin davranışını ve güvenliğini asıl belirleyen unsurlar, yanlarına eklenen "flag" adı verilen parametrelerdir:

• HttpOnly (XSS Savunması): Bu flag, çerezin tarayıcı tarafındaki JavaScript kodları (örneğin document.cookie) tarafından okunmasını engeller. Bu, en yaygın saldırı türlerinden biri olan XSS (Cross-Site Scripting) ile oturum anahtarınızın çalınmasına karşı en güçlü bariyerdir. Sadece HTTP(S) protokolü ile iletilirler.

• Secure: Bu parametre işaretlendiğinde çerez, sadece HTTPS üzerinden şifrelenmiş bağlantılarda iletilir. Açık Wi-Fi ağlarında yapılan "Man-in-the-Middle" (aradaki adam) saldırılarını zorlaştırır.

  • Strict: Çerez sadece çerezin oluşturulduğu site üzerindeyken gönderilir.

  • Lax: Modern tarayıcılarda varsayılan budur. Dış bir siteden bağlantıya tıklandığında gönderilir ama arka plandaki "gizli" isteklerde gönderilmez.

  • None: Çerez her türlü durumda gönderilir.

• Domain ve Path: Çerezin etki alanını belirler. Örneğin, blog.site.com için oluşturulan bir çerez, shop.site.com adresine gönderilmez. Path=/admin olarak ayarlanmışsa, ana sayfada bu çerez görünmez.

Çerezlerin Manipülasyon Riski ve SınırlarıQ

Çerezler istemci tarafında barındığı için kullanıcı tarafından her zaman görüntülenebilir ve değiştirilebilir. Geliştirici araçlarını açan her kullanıcı, çerez değerlerini manuel olarak güncelleyebilir. Bu nedenle:

• Asla hassas veri saklanmaz: Şifreler, kullanıcı rolleri veya kredi kartı bilgileri çerezde durmaz.

• Kapasite kısıtlıdır: Her çerez yaklaşık 4KB ile sınırlıdır. Bu yüzden çerezler büyük veriler için değil, sadece "anahtarlar" için tasarlanmıştır.

Geliştirici Notu: Çerezler, sunucuya her istekte otomatik olarak gönderildiği için, gereksiz büyük çerezler ağ trafiğini artırır (Overhead) ve performansı olumsuz etkiler.

Sessions (Oturumlar): Sunucu Tarafındaki Güvenli Hafıza

Çerezlerin kısıtlamalarını ve güvenlik risklerini aşmak için geliştirilen mekanizma Session yapısıdır. Session, veriyi istemcinin tarayıcısında değil, sunucu tarafındaki güvenli bir depolama alanında tutar.

1. "Anahtar-Kasa" İlişkisi

Session mekanizmasını bir bankadaki kiralık kasa dairesine benzetebiliriz:

• Session ID (Anahtar): Kullanıcı giriş yaptığında sunucu benzersiz, tahmin edilemez ve imzalanmış bir "Session ID" üretir. Bu ID, bir çerez (örneğin connect.sid) aracılığıyla tarayıcıya gönderilir. Tarayıcıda saklanan tek şey bu anlamsız dizedir.

• Session Data (Kasa): Kullanıcının rolü, sepeti ve ID'si gibi hassas veriler sunucuda bu ID ile eşleşen bir "kasada" saklanır. Kullanıcı anahtarı (çerezi) her gönderdiğinde, sunucu kendi tarafındaki kasayı açarak verileri okur.

2. Session Depolama Stratejileri (Session Store)

Oturum verilerinin sunucuda nerede tutulacağı uygulamanın performansı ve ölçeklenebilirliği için kritiktir:

• Memory Store (Bellek): Veriler sunucunun RAM'inde tutulur. Hızlıdır ancak sunucu her yeniden başladığında (nodemon restart gibi) tüm oturumlar silinir. Ayrıca çok sayıda kullanıcı olduğunda RAM yetersiz kalabilir.

• Database Store (MongoDB/SQL): connect-mongodb-session gibi araçlarla veriler veritabanına yazılır. Sunucu kapansa bile oturumlar hayatta kalır. Üretim (production) ortamları için standart budur.

Sonuç: Web'in Hafızasını Yönetmek

Özetle; Cookies ve Sessions, web'in doğuştan gelen "unutkanlık" sorununa karşı geliştirilmiş, birbirini tamamlayan iki güçlü stratejidir. Çerezler, kullanıcıyı tarayıcı seviyesinde tanımamızı sağlayan hafif ve pratik "kimlik kartları" iken; oturumlar, bu kimliklerin arkasındaki hassas verileri sunucu tarafındaki "güvenli kasalarda" muhafaza eder. Modern bir web geliştirici için bu iki mekanizma arasındaki dengeyi kurmak, sadece kullanıcıyı hatırlamak değil; aynı zamanda performans ve güvenlik arasındaki o ince çizgiyi yönetmek anlamına gelir. Hangi veriyi kullanıcının cebine (Cookie), hangi veriyi sunucunun hafızasına (Session) emanet edeceğinizi bilmek, hem daha güvenli hem de daha akıcı bir kullanıcı deneyimi inşa etmenin anahtarıdır.