JWT Depolama: LocalStorage mı HttpOnly Cookie mi?

JWT Depolama: LocalStorage mı HttpOnly Cookie mi?

Web uygulamalarında kullanıcı kimlik doğrulama ve yetkilendirme süreçlerinde JSON Web Token (JWT) kullanımı oldukça yaygın. Ancak bu token’ları istemci tarafında (tarayıcı) güvenli bir şekilde saklamak, göz ardı edilmemesi gereken kritik bir konu. Genellikle karşımıza çıkan iki temel seçenek var: tarayıcının localStorage’ı veya HTTP-only çerezler (HttpOnly cookie). Bu iki yöntemin avantajları, dezavantajları ve hangi senaryolarda hangisini tercih etmemiz gerektiği üzerine derinlemesine bir bakış atalım.

Bu karşılaştırmada, her iki depolama mekanizmasının da güvenlikten performansına, kullanım kolaylığından ölçeklenebilirliğine kadar pek çok yönünü ele alacağım. Amacım, kendi projelerinizde en doğru kararı vermenize yardımcı olmak. Unutmayın, bir teknoloji seçimi her zaman bir trade-off gerektirir ve en iyi çözüm, projenizin özel ihtiyaçlarına göre şekillenir.

LocalStorage’ın İncelikleri ve Riskleri

localStorage, tarayıcının sunduğu key-value (anahtar-değer) tabanlı bir depolama mekanizmasıdır. Veriler tarayıcı kapatılsa bile kalıcıdır ve JavaScript ile kolayca erişilebilir. Bu basitlik, özellikle JWT gibi token’ları saklamak için cazip görünebilir. Ancak bu kolaylığın beraberinde getirdiği ciddi güvenlik açıkları mevcut.

En büyük risk, localStorage’ın JavaScript tarafından okunabilir olmasıdır. Bu, web sayfanızda çalışan herhangi bir JavaScript kodu (kendi kodunuz, üçüncü parti kütüphaneler veya en kötüsü, bir Cross-Site Scripting (XSS) saldırısı sonucu enjekte edilen zararlı kod) token’larınıza erişebilir. Bir XSS açığı tespit edildiğinde, saldırganlar kullanıcının oturumunu çalabilir ve onun adına işlem yapabilir. Örneğin, bir blog sitesinde yorum yaparken veya bir forumda mesaj gönderirken farkında olmadan zararlı bir script çalıştırıldığında, localStorage’daki JWT’niz doğrudan tehlikeye girebilir.

Ayrıca, localStorage’ın depolama kapasitesi genellikle 5MB civarındadır ve bu, büyük token’lar veya ek veriler saklamak için yeterli olmayabilir. Performans açısından bakıldığında, her istekte localStorage’dan veri okuyup göndermek, tarayıcının JavaScript motoru üzerinde ek yük oluşturabilir. Bu nedenle, localStorage’ı JWT depolamak için kullanırken, potansiyel güvenlik risklerini ve performans etkilerini dikkatlice değerlendirmek gerekir.

XSS ve Token Hırsızlığı: Saldırı Zinciri

localStorage’ın en somut riski, bir XSS açığı ile token hırsızlığı arasındaki mesafenin neredeyse sıfır olmasıdır. Dinamik olarak oluşturulan bileşenlerde (örneğin kullanıcı girdisiyle beslenen grafik veya rapor bileşenleri) sanitize edilmemiş bir input alanı bulunduğunda, saldırgan sayfada çalışan JavaScript’i kontrol edebilir.

Bu noktadan sonrası tek satırlık bir iştir: enjekte edilen script localStorage.getItem('authToken') ile token’ı okur ve kullanıcının oturumu ele geçirilir. localStorage JavaScript’e açık olduğu için, açığın bulunduğu yer ile token’ın saklandığı yer arasında hiçbir güvenlik sınırı yoktur. Pratikte bu tür bir zafiyet ortaya çıktığında tek kalıcı çözüm, depolama stratejisini HttpOnly çerezlere taşıyıp etkilenen token’ları geçersiz kılmaktır — bu da localStorage’ın XSS karşısında neden temelde savunmasız olduğunu özetler.

HttpOnly Cookie’lerin Güvenlik Avantajları

HttpOnly bayrağına sahip çerezler, tarayıcı tarafından otomatik olarak sunucuya gönderilir ve JavaScript tarafından erişilemezler. Bu, localStorage’ın aksine, XSS saldırılarının token’ları çalmasını önemli ölçüde engeller. Çünkü zararlı script’ler, document.cookie aracılığıyla HttpOnly çerezlere ulaşamazlar. Bu özellik, JWT gibi hassas bilgilerin depolanması için HttpOnly çerezleri daha güvenli bir seçenek haline getirir.

Bir HttpOnly çerezi, bir Set-Cookie HTTP başlığı ile tarayıcıya gönderilir. Örneğin, sunucu tarafı bir uygulamanız (örneğin, Node.js ile Express kullanarak) bir JWT ürettiğinde, bu token’ı aşağıdaki gibi bir başlıkla tarayıcıya gönderebilir:

Set-Cookie: authToken=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...; HttpOnly; Secure; SameSite=Strict; Path=/

Buradaki HttpOnly bayrağı, JavaScript’in bu çereze erişimini engeller. Secure bayrağı ise çerezin yalnızca HTTPS üzerinden gönderilmesini sağlar, bu da man-in-the-middle (MITM) saldırılarına karşı ek bir koruma katmanı sunar. SameSite=Strict ise, çerezin yalnızca aynı site isteğiyle gönderilmesini sağlayarak CSRF (Cross-Site Request Forgery) saldırılarının etkisini azaltır.

Ancak HttpOnly çerezlerin de kendi zorlukları vardır. Tarayıcılar bu çerezleri otomatik olarak gönderdiği için, istemci tarafında token’ı okuyup üzerinde işlem yapmak istediğinizde (örneğin, bir API isteği hazırlarken token’ı başlığa eklemek yerine çerezden alıp tekrar başlığa eklemek gibi) doğrudan erişiminiz olmaz. Bu durum, özellikle SPA (Single Page Application) geliştirirken bazı mimari kararlar almanızı gerektirebilir.

HttpOnly Cookie’ler ile CSRF Koruması

HttpOnly çerezlerin bir diğer önemli güvenlik özelliği ise, SameSite özniteliği ile birlikte kullanıldığında Cross-Site Request Forgery (CSRF) saldırılarına karşı sunduğu korumadır. CSRF saldırıları, kullanıcının oturumunu ele geçirmek yerine, kullanıcının tarayıcısını kullanarak, kullanıcının bilmediği veya onaylamadığı eylemleri gerçekleştirmeyi hedefler.

Örneğin, bir kullanıcı bankacılık sitesinde oturum açmışken, kötü niyetli bir web sitesi, kullanıcının bilgisi olmadan gizlice bankacılık sitesine bir ödeme emri gönderebilir. Eğer oturum bilgisi HttpOnly çerezlerde saklanıyorsa ve bu çerezler SameSite=Strict olarak ayarlanmışsa, tarayıcı bu isteği farklı bir siteden geldiği için çerezi göndermeyecektir. Bu da CSRF saldırısının başarısız olmasına yol açar.

Set-Cookie: sessionId=abc123xyz; HttpOnly; Secure; SameSite=Strict

Yukarıdaki örnekte, SameSite=Strict ayarı, çerezin yalnızca aynı siteye (yani, bank.com’dan gelen isteklere) gönderilmesini zorunlu kılar. Eğer kullanıcı malicious.com sitesindeyken bank.com’a bir POST isteği gönderilirse, tarayıcı sessionId çerezini bu isteğe eklemeyecektir. Bu, CSRF saldırılarına karşı güçlü bir savunma mekanizmasıdır.

Ancak SameSite=Strict ayarı, bazı durumlarda kullanıcı deneyimini olumsuz etkileyebilir. Örneğin, bir kullanıcı bir siteden (örneğin, siteA.com) başka bir siteye (siteB.com) bir linke tıkladığında ve siteB.com’da oturum açması gerekiyorsa, Strict modu bu isteği engelleyebilir çünkü istek farklı bir “site”den gelmektedir. Bu tür senaryolarda SameSite=Lax daha uygun bir seçenek olabilir.

JWT’leri Yönetmek: Mimari Yaklaşımlar

HttpOnly çerezleri kullanırken, JWT’yi sunucuya nasıl göndereceğimiz önemli bir mimari konudur. Geleneksel olarak, kimlik doğrulama token’ları Authorization: Bearer <token> başlığı ile gönderilir. Ancak HttpOnly çerezler JavaScript tarafından erişilemediği için, bu yaklaşımı doğrudan uygulayamayız.

Bu durumda, iki yaygın strateji izlenebilir:

1. Sunucu Tarafı Rendering (SSR) veya Hybrid Yaklaşımlar: Eğer uygulamanız sunucu tarafında render ediliyorsa (örneğin, Astro, Next.js, Nuxt.js gibi framework’ler ile), sunucu isteği aldığında HttpOnly çerezlerden token’ı okuyabilir ve doğrudan API isteklerinde kullanabilir. Bu durumda istemci tarafı JavaScript’in token’a erişmesi gerekmez.

2. API Gateway veya Backend for Frontend (BFF): Ayrı bir BFF katmanı kullanarak, istemci isteklerini alır, HttpOnly çerezlerden token’ı okur, bu token ile asıl servis API’lerine istek yapar ve sonuçları istemciye döner. Bu, istemci tarafında token yönetimi karmaşıklığını ortadan kaldırır.

Eğer uygulamanız tamamen istemci tarafında çalışıyorsa ve HttpOnly çerez kullanıyorsanız, token’ı bir header’a eklemek için sunucu tarafında bir ara katman (örneğin, Nginx ile bir proxy_set_header direktifi veya bir Node.js sunucusu) kullanmanız gerekebilir. Bu ara katman, gelen istekteki HttpOnly çerezden token’ı alıp, hedef API’ye gönderilecek istekteki Authorization başlığına ekleyecektir. Bu yaklaşım, istemci tarafı kodunu basitleştirir ve güvenlik risklerini azaltır.

Depolama Seçeneklerinin Karşılaştırılması

Aşağıdaki tablo, localStorage ve HttpOnly çerezlerin temel özelliklerini özetlemektedir:

Bu tabloya bakarak, JWT gibi hassas bilgilerin depolanması için HttpOnly çerezlerin, localStorage’a göre bariz bir şekilde daha güvenli olduğunu söyleyebiliriz. localStorage’ın kolaylığı, güvenlik açısından ciddi ödünler vermeyi gerektirir.

Performans ve Kapsam Analizi

Performans açısından bakıldığında, localStorage’dan veri okuma ve yazma işlemleri, JavaScript motoru üzerinde CPU döngüleri tüketir. Her istekte token’ı almak ve HTTP başlığına eklemek, özellikle sık API çağrısı yapan uygulamalarda küçük de olsa bir performans maliyeti yaratır. Öte yandan, HttpOnly çerezler tarayıcı tarafından otomatik olarak yönetilir ve HTTP isteğinin bir parçası olarak gönderilir. Bu, istemci tarafı JavaScript’in iş yükünü azaltır.

Ancak HttpOnly çerezlerin de bazı potansiyel performans etkileri olabilir. Özellikle büyük token’lar veya çok sayıda çerez varsa, her istekte gönderilen veri miktarı artar. Bu durum, ağ bant genişliğini ve sunucu tarafındaki işleme süresini etkileyebilir. Yine de, bu etkiler genellikle XSS saldırılarının potansiyel maliyetiyle karşılaştırıldığında ihmal edilebilir düzeydedir.

Kapsam açısından, localStorage tarayıcı bazında çalışır ve çerezler de aynı şekilde tarayıcı ve alan adına bağlıdır. Ancak HttpOnly çerezlerin Secure ve SameSite gibi ek öznitelikleri sayesinde daha granüler kontrol ve daha gelişmiş güvenlik politikaları uygulamak mümkündür. Bu da HttpOnly çerezleri daha kapsamlı bir güvenlik çözümü haline getirir.

Devam Eden Sorunlar ve Çözüm Önerileri

Her ne kadar HttpOnly çerezler localStorage’a göre daha güvenli bir seçenek olsa da, mükemmel değillerdir. Özellikle HttpOnly çerezlerin yönetimi, geliştiriciler için bazı ek karmaşıklıklar getirebilir. Örneğin, istemci tarafı JavaScript’in token’a erişememesi, bazı modern frontend mimarilerinde zorluklar yaratabilir.

Bir çözüm olarak, BFF (Backend for Frontend) deseni oldukça etkilidir. BFF katmanı, istemci isteklerini alır, HttpOnly çerezlerden token’ı alır, gerekli servis çağrılarını yapar ve sonuçları istemciye döner. Bu sayede istemci tarafı sadece BFF ile iletişim kurar ve token yönetimi tamamen sunucu tarafında halledilir. Bu yaklaşım, özellikle karmaşık mikroservis mimarilerinde istemci tarafını basitleştirmek için harika bir yoldur.

Bir diğer potansiyel sorun, çerezlerin tarayıcılar arası senkronizasyonu veya farklı cihazlardaki oturumların yönetimidir. Eğer kullanıcı farklı cihazlardan uygulamaya erişiyorsa ve oturumlarının senkronize olmasını istiyorsanız, sadece HttpOnly çerezler yeterli olmayabilir. Bu gibi durumlarda, sunucu tarafında merkezi bir oturum yönetimi mekanizması ile birlikte HttpOnly çerezleri kullanmak daha mantıklı olabilir.

Ayrıca, tarayıcıların çerez politikaları zamanla değişebilir ve bu da beklenmedik davranışlara yol açabilir. Bu nedenle, güncel tarayıcı belgelerini takip etmek ve HttpOnly, Secure, SameSite gibi özniteliklerin doğru bir şekilde uygulandığından emin olmak önemlidir.

Sonuç: Güvenlik Öncelikli Yaklaşım

Peki, localStorage mı, HttpOnly cookie mi? Bu analizin gösterdiği gibi, JWT gibi hassas kimlik doğrulama token’ları için kesinlikle HttpOnly çerezler tercih edilmelidir. localStorage’ın JavaScript ile kolay erişilebilir olması, onu XSS saldırılarına karşı aşırı derecede savunmasız hale getirir. Bir XSS zafiyeti, localStorage’daki token’ın çalınmasıyla doğrudan oturum ele geçirmeye yol açabilir.

HttpOnly çerezler, tarayıcı tarafından otomatik olarak yönetilmeleri ve JavaScript’ten gizlenmeleri sayesinde bu riski ortadan kaldırır. SameSite özniteliği ile birleştirildiğinde ise CSRF saldırılarına karşı da güçlü bir koruma sağlarlar. Geliştirme sürecinde getirdiği küçük ek karmaşıklıklar, sunduğu güvenlik avantajları yanında oldukça azdır.

Eğer modern bir SPA geliştiriyorsanız ve HttpOnly çerezlerle çalışmakta zorlanıyorsanız, bir BFF katmanı veya sunucu tarafı rendering (SSR) gibi yaklaşımları benimseyerek bu zorlukların üstesinden gelebilirsiniz. Unutmayın ki, web güvenliği sürekli bir mücadeledir ve aldığımız her doğru mimari karar, kullanıcılarımızın verilerini korumada büyük fark yaratır.

Bir sonraki adım, JWT’lerinizi güvenli bir şekilde saklamak için HttpOnly çerezleri uygulamanıza entegre etmektir. Bu, hem sizin hem de kullanıcılarınızın daha güvende olmasını sağlayacaktır.