JWT Token Güvenliği: İmza Doğrulama ve XSS Koruması

JWT (JSON Web Token), sunucuları yormayan harika bir teknoloji olsa da, güvenlik tarafında yazılımcılara büyük sorumluluklar yükler. Çünkü eski Session (Oturum) sistemlerinde veri sunucudaydı, JWT'de ise veri (Token) tamamen Kullanıcının Elindedir (Client-side).

Eğer kullanıcıdaki bu Token çalınırsa veya değiştirilirse ne olur?

---

1. İmza (Signature) Doğrulaması

JWT'nin ortasındaki parça (Payload) sadece Base64 ile kodlanmıştır, ŞİFRELENMEMİŞTİR. Bu, o token'ı eline geçiren herkesin (Kullanıcının kendisi dahil) içindeki veriyi ("role": "user") okuyabileceği anlamına gelir.

Kullanıcı kurnazlık yapıp o veriyi "role": "admin" olarak değiştirip sunucuya geri gönderirse, sunucu onu Admin olarak mı tanıyacaktır?

Hayır. Çünkü JWT'nin sonunda 3. bir parça olan İmza (Signature) bulunur. Sunucu o imzayı oluştururken kendine ait çok gizli bir şifre (Secret Key) kullanmıştır. Kullanıcı ortadaki veriyi değiştirdiği an, sondaki eski İmza GEÇERSİZ kalır. Kullanıcı yeni bir imza üretemez (Çünkü sunucunun Secret Key'ini bilmiyordur). Sunucu gelen token'ın mühürünün bozulduğunu anlar ve 401 Unauthorized (Yetkisiz) hatası fırlatır.

Bu yüzden JWT içerisine ASLA kullanıcı şifresi veya kredi kartı numarası konulmamalıdır (Çünkü okunabilir). Sadece kullanıcı ID'si ve yetkileri konulmalıdır (Çünkü değiştirilemez).

2. En Ölümcül Hata: LocalStorage Kullanımı

React, Vue veya Angular geliştiricilerinin %90'ı, API'den gelen JWT Token'ını tarayıcının LocalStorage belleğine kaydeder. Bu siber güvenlik açısından yapılabilecek en ölümcül hatadır.

Sitenize dışarıdan zararlı bir JavaScript kodu sızdığını (XSS - Cross Site Scripting) düşünün. Bu zararlı kod tarayıcıda çalıştığı an, localStorage.getItem("token") komutuyla kullanıcının JWT'sini kopyalar ve saniyeler içinde Rusya'daki bir hacker sunucusuna gönderir.

Hacker artık o kullanıcıdır. Şifre bilmesine gerek yoktur, elindeki geçerli JWT ile sisteme direkt girer (Session Hijacking).

3. Güvenli Çözüm: HttpOnly Cookies

JWT'nin çalınmasını engellemenin tek yolu, onu JavaScript'in ELLERİNDEN UZAK TUTMAKTIR.

Backend (Sunucu), login işlemi başarılı olduğunda token'ı bir JSON formatında döndürmemeli, bunu doğrudan bir Cookie (Çerez) olarak set etmelidir. Ancak bu çereze iki adet bayrak (Flag) eklemelidir:

1. HttpOnly: Bu bayrak, çerezin (Token'ın) JAVASCRIPT TARAFINDAN OKUNMASINI tamamen yasaklar. XSS saldırısı olsa bile hacker token'a ulaşamaz.
2. Secure: Çerezin sadece HTTPS üzerinden (Şifreli Ağ) gönderilmesini sağlar. Ortadaki Adam (Man-in-the-Middle) saldırılarını engeller.

Sisteminizdeki veya test ortamınızdaki JWT'lerin payload (Yük) kısmını güvenli bir şekilde analiz etmek için sunucuyla iletişim kurmayan, %100 çevrimdışı (Offline) çalışan JWT Decoder aracımızı kullanabilirsiniz. Token mimarisinin temelleri için JWT ve Kimlik Doğrulama Rehberimize göz atın.

---

🕸️ Knowledge Graph & Semantik Bağlantılar

Bu içerik, Intent.com.tr'nin Siber Güvenlik topikal kümesinin (Topic Cluster) bir parçasıdır. Konuyu daha derinlemesine anlamak için aşağıdaki varlıkları (Entities) ve ilişkili içerikleri inceleyebilirsiniz:

📖 İlgili Rehberler ve İçerikler

• XSS (Cross-Site Scripting) Saldırılarını HTML Encode İle Engellemek
• MD5 Neden Artık Kullanılmamalı? Güvenlik Zafiyetleri ve Collision
• Htaccess ile Resim Hotlink Koruması ve Güvenlik Ayarları

🧠 Semantic Entities (Terimler & Senaryolar)

• Kavram: GEO (Generative Engine Optimization)
• Kavram: AEO (Answer Engine Optimization)
• Uygulama: Yeni Bir Web Sitesi Yayına Alırken Kusursuz Check-List

Semantic Yönerge: Bu sayfa JWT Token Güvenliği: İmza Doğrulama ve XSS Koruması konusundaki kullanıcı niyetini (Search Intent) karşılamak üzere yapılandırılmıştır.