Merhaba Turkhacks okurları ve yazılım sektörüne gönül vermiş geliştiriciler. REST API geliştirmeye başlayan çoğu geliştirici için ilk büyük adımlardan biri kullanıcı doğrulama sistemini kurmaktır.
Başlangıçta işler oldukça basit görünür.
Kullanıcı giriş yapar, sistem bir JWT üretir ve sonraki isteklerde bu token kullanılır.
Her şey çalışıyordur.
Fakat bir süre sonra şu sorular ortaya çıkmaya başlar:
- Token süresi ne kadar olmalı?
- JWT içerisine hangi bilgiler yazılmalı?
- Refresh Token gerekli mi?
- Secret Key nasıl saklanmalı?
- JWT çalınırsa ne olur?
Çünkü güvenlik çoğu zaman bir teknolojiyi kullanmakla değil, onu doğru kullanmakla ilgilidir.
JWT Güvenliği Neden Bu Kadar Önemli?
JWT'nin en büyük avantajı stateless olmasıdır.Sunucu tarafında oturum tutulmaz.
Bu sayede:
- Performans artar
- Ölçekleme kolaylaşır
- Mikroservis yapıları daha rahat yönetilir
Çünkü geçerli bir token ele geçirildiğinde sistem onu gerçek kullanıcı gibi görebilir.
Bu yüzden JWT sistemleri tasarlanırken bazı temel kurallara dikkat etmek gerekir.
JWT İçerisinde Hassas Veri Tutmayın
Yeni başlayan geliştiricilerin yaptığı en yaygın hatalardan biri JWT içerisine gereğinden fazla bilgi koymaktır.Örneğin:
Kod:
{
"username":"admin",
"password":"123456"
}Böyle bir kullanım kesinlikle doğru değildir.
JWT şifrelenmiş değildir.
Sadece imzalanmıştır.
Bu nedenle token içeriği okunabilir.
JWT içerisinde yalnızca gerçekten gerekli bilgiler bulunmalıdır.
Örneğin:
Kod:
{
"userId":15,
"role":"ADMIN"
}Bu yaklaşım çok daha güvenlidir.
Token Sürelerini Gereğinden Fazla Uzatmayın
Bazı projelerde token sürelerinin aylarca hatta yıllarca geçerli bırakıldığı görülebiliyor.
Bu ciddi bir güvenlik riskidir.
Aşağıdaki tablo genel bir fikir verebilir:
| Kullanım Türü | Önerilen Süre |
|---|---|
| Access Token | 15-60 dakika |
| Refresh Token | 7-30 gün |
| Mobil uygulama | İhtiyaca göre değişebilir |
Refresh Token Kullanmayı Düşünün
JWT kullanan projelerde sık karşılaşılan problemlerden biri kullanıcı deneyimidir.Örneğin Access Token süresini 15 dakika yaptınız.
Kullanıcı her 15 dakikada bir tekrar giriş yapmak istemeyecektir.
Bu noktada Refresh Token devreye girer.
Mantık oldukça basittir:
Access Token Süresi Doldu
↓
Refresh Token Kontrol Edildi
↓
Yeni Access Token Üretildi
Bu yapı hem güvenliği hem de kullanıcı deneyimini dengeler.
Secret Key'i Kodun İçine Yazmayın
JWT sistemlerinin güvenliği büyük ölçüde kullanılan secret key'e bağlıdır.Ancak birçok projede şu tarz kullanım görmek mümkündür:
Kod:
String secret =
"123456789";Bu yaklaşım geliştirme ortamında çalışabilir.
Fakat gerçek sistemlerde ciddi risk oluşturur.
Daha doğru yöntemler:
- Environment Variables
- Vault sistemleri
- Secret Manager servisleri
HTTPS Kullanmadan JWT Kullanmayın
Bu madde bazen gözden kaçabiliyor.JWT ne kadar güvenli olursa olsun, HTTP üzerinden taşınıyorsa ciddi risk altındadır.
Çünkü ağ trafiğini dinleyen biri token'ı ele geçirebilir.
Bu nedenle:
| Protokol | Güvenlik |
| HTTP | Riskli |
| HTTPS | Güvenli |
Logout Mekanizmasını Planlayın
JWT kullanan sistemlerde logout işlemi klasik session sistemlerinden biraz farklıdır.Çünkü sunucu tarafında aktif bir oturum bulunmaz.
Bu nedenle:
- Token blacklist
- Refresh token iptali
- Token versiyonlama
Aksi halde kullanıcı çıkış yapmış olsa bile token süresi dolana kadar kullanılmaya devam edebilir.
Yetkilendirmeyi Sadece Frontend'e Bırakmayın
Bazen geliştiriciler yalnızca arayüz tarafında kontrol yapmanın yeterli olduğunu düşünebiliyor.Örneğin:
Admin Butonu Gizlendi
Bu güvenlik değildir.
Sadece kullanıcı deneyimidir.
Gerçek kontrol mutlaka backend tarafında yapılmalıdır.
Örneğin:
ROLE_ADMIN
yetkisi olmayan kullanıcı ilgili endpoint'e erişememelidir.
Gereksiz Bilgileri Loglamayın
Log sistemleri hata ayıklamak için çok değerlidir.
Ancak bazı bilgiler loglara yazılmamalıdır.
Özellikle:
- JWT tokenları
- Şifreler
- Refresh tokenlar
- Güvenlik anahtarları
Aksi halde log sistemi yeni bir güvenlik açığına dönüşebilir.
Rate Limiting Kullanın
JWT kullanıyor olmanız saldırı riskini tamamen ortadan kaldırmaz.Özellikle login endpoint'leri hedef alınabilir.
Bu nedenle belirli bir süre içerisinde yapılabilecek istek sayısını sınırlamak mantıklıdır.
Örneğin:
| İşlem | Limit |
| Login | Dakikada 5 |
| Şifre sıfırlama | Dakikada 3 |
| Kayıt işlemi | Dakikada 10 |
Bu yaklaşım brute force saldırılarına karşı önemli koruma sağlar.
Algoritma Seçimine Dikkat Edin
JWT oluşturulurken kullanılan imzalama algoritması da önemlidir.En sık kullanılan seçenekler:
| Algoritma | Kullanım |
| HS256 | Yaygın |
| RS256 | Kurumsal sistemler |
| ES256 | Daha gelişmiş senaryolar |
Kurumsal sistemlerde ise RS256 daha sık tercih edilir.
En Sık Yapılan JWT Hataları
Gerçek projelerde tekrar tekrar karşılaşılan bazı hatalar vardır.- Süresiz token oluşturmak
- Secret key'i GitHub'a yüklemek
- HTTP kullanmak
- WT içine hassas veri koymak
- Logout sürecini düşünmemek
- Refresh Token kullanmamak
Bu hataların çoğu sistem çalışırken fark edilmez.
Genellikle güvenlik testi veya saldırı sonrasında ortaya çıkar.
Sevgili Dostlar JWT, REST API güvenliği için günümüzde en yaygın kullanılan yöntemlerden biri haline gelmiş durumda. Ancak JWT kullanıyor olmak tek başına sistemi güvenli hale getirmez. Turkhacks yazılım ekibimizide sıklıkla kullandığı Gerçek güvenlik; doğru token süreleri belirlemekten, secret key yönetimine, HTTPS kullanımından yetkilendirme kontrollerine kadar birçok detayın birlikte düşünülmesiyle sağlanır.Başarılı projelerde JWT yalnızca bir kimlik doğrulama mekanizması değildir. Aynı zamanda sistemin genel güvenlik stratejisinin önemli bir parçasıdır. Bu nedenle JWT'yi öğrenirken sadece nasıl üretildiğine değil, nasıl korunacağına da odaklanmak uzun vadede çok daha değerli olacaktır. Bir dahaki makalemizde görüşüne kadar mavi ekraansız ve sorunsuz sistemlerde çalışmanız dileği ile hoşçakalın
