14 — Güvenlik Kuralları ("Asla Yapmayın" Listesi)
Kimin için: Tüm yazılım mimarları, kıdemli geliştiriciler ve güvenlik denetçileri.
Ön koşul: Temel web ve OAuth 2.0 güvenlik prensipleri.
Tahmini süre: 10 dakika.
Ne Öğreneceksiniz
- TALOST ID entegrasyonlarında en sık yapılan kritik güvenlik hatalarını,
- Her hatanın neden bir güvenlik açığı oluşturduğunu (Neden?),
- Standartlara uygun güvenli çözümü (Doğrusu).
🚫 "Asla Yapmayın" Tablosu
| # | Hatalı Uygulama (Asla Yapmayın) | Neden Tehlikeli? | Doğrusu (Standart Çözüm) |
|---|---|---|---|
| 1 | client_secret veya AppApiKey'i frontend JavaScript koduna veya mobil uygulamaya koymak |
Tarayıcıda veya APK/IPA paketlerinde gizli anahtarlar anında sızdırılabilir; saldırgan uygulamanız adına token üretebilir. | İstemci tarafında yalnızca Public Client (PKCE) kullanın; gizli anahtarları sadece güvenli arka uç (Back-end) sunucunuzda tutun. |
| 2 | PKCE'yi atlamak veya plain method kullanmak |
Yetkilendirme kodu çalınırsa (code interception) saldırgan kullanıcı oturumunu ele geçirebilir. | Her zaman code_challenge_method=S256 ile SHA-256 tabanlı PKCE uygulayın. |
| 3 | Token'ları tarayıcıda localStorage içinde saklamak |
Sitenizde oluşabilecek en ufak bir XSS açığı ile tüm kullanıcı tokenları tek bir JS satırıyla çalınabilir. | Token'ları tarayıcıya göndermeyin; HttpOnly, Secure ve SameSite=Lax korumalı oturum çerezleri kullanın. |
| 4 | Token'ları (access_token, refresh_token, AppApiKey) loglara veya konsola yazdırmak |
Log analiz araçları (Datadog, Cloudwatch vb.) veya hata izleme servisleri üzerinden sızıntı yaşanır. | Loglama kütüphanelerinizde token alanlarını maskeleyin (***); asla düz metin loglamayın. |
| 5 | Giriş akışında state parametresini doğrulamamak |
Saldırgan kurbanı kendi hesabına yönlendirebilir (OAuth CSRF Saldırısı). | state parametresini kriptografik rastgele üretin, çereze kaydedin ve geri dönüşte eşitliğini kesin olarak doğrulayın. |
| 6 | Veritabanında kullanıcıları email alanıyla ilişkilendirmek |
Kullanıcı e-posta adresini değiştirdiğinde tüm geçmişi ve lisansı kopar. | Kalıcı birincil anahtar olarak her zaman OIDC sub (Subject UUID) alanını kullanın. |
| 7 | Webhook imzasını (X-Talost-Signature) doğrulamamak |
Saldırgan uygulamanıza sahte subscription.activated isteği atarak ücretsiz lisans açabilir. |
Her gelen webhook'ta t zaman damgasını ve HMAC-SHA256 imzasını timingSafeEqual ile doğrulayın. |
| 8 | Lisans ve özellik kontrollerini yalnızca istemci tarafında yapmak | Kullanıcı tarayıcıda JS kodunu veya ağ yanıtını değiştirerek kısıtlı özellikleri açabilir. | Kritik API işlemlerinde her zaman arka uçta features ve limits denetimi yapın. |
| 9 | id_token'ı API çağrılarında Bearer token gibi göndermek |
ID token bir erişim bileti değildir; API'ler yetki kontrolü yapamaz. | Arka uç API'lerine istek atarken yalnızca access_token kullanın. |
| 10 | Webhook gövdesini parse ettikten sonra imzalamak | JSON anahtarlarının sırası veya boşluklar değiştiği için imza tutmaz ve sahte hata oluşur. | İmzayı hesaplarken istek gövdesinin ham metin/bayt halini (Raw Body) kullanın. |
Güvenlik Denetim Özeti (Checklist)
-
.envdosyam.gitignoreiçinde yer alıyor ve repoya push edilmiyor. - Geliştirme (
DEVELOPMENT) anahtarlarım canlı sunucuda kullanılmıyor. - Çerezlerimde
HttpOnly,SecureveSameSitebayrakları aktif. - Webhook uç noktamda zaman damgası 300 saniyeden eski istekleri reddediyor.
- Log çıktılarımda hiçbir token görünmüyor.
İlgili Sayfalar
Son doğrulama: 2026-10-04 · Kaynak: _envanter.md, src/lib/webhooks/ssrf.ts, src/lib/apps/api-key.ts
Son doğrulama: 2026-10-04 · Kaynak: `_envanter.md`, `src/lib/webhooks/ssrf.ts`, `src/lib/apps/api-key.ts`