Tehdit modeli
GuildGate, Discord dashboard sunucusunda kimliği doğrulanmış bir kullanıcının yetkili olduğu kaynağa kontrollü yazma yapmasını hedefler. Tarayıcı, istemci JavaScript'i ve gelen tüm istek alanları güvenilmez kabul edilir.
Ele alınan tehditler
| Tehdit | Uygulanan kontrol |
|---|---|
| Sahte origin veya CSRF | Exact-origin allowlist ve oturuma bağlı CSRF doğrulaması |
| Çalınmış/eskimiş oturum | Hashlenmiş opak token, idle/absolute expiry, rotation, revocation ve cookie temizleme |
| OAuth state tekrar kullanımı | Atomik tek kullanımlık consume() |
| Token verisi sızıntısı | Uygulama anahtar halkasıyla şifreli credential kaydı ve audit redaction |
| Yetki kaybından sonra yazma | Action anında yeniden yetkilendirme |
| Tekrarlanan istek | Idempotency reservation, request hash ve replay |
| Eşzamanlı güncelleme | Optimistic revision, lease ve fencing token |
| Eski worker'ın yeni sonucu bozması | Reservation owner compare-and-set |
| Rate limit yarış koşulu | Atomik store işlemi; PostgreSQL'de advisory lock |
| Commit sonrası sahte rollback | Commit kesinliği ve ayrılmış afterCommit hata yolu |
| Realtime kanal sızıntısı | Oturum ve kanal yetkisi, periyodik yeniden doğrulama, revocation |
| Yavaş istemci/kuyruk büyümesi | Payload, queue, buffered byte, abonelik ve bağlantı ömrü sınırları |
| Outbox olayının iki kez teslimi | At-least-once sözleşmesi ve event ID ile consumer deduplication |
| Üretimde yerel adres kullanımı | HTTPS ve loopback/unspecified adres reddi |
Güven sınırları
GuildGate aşağıdaki bileşenlerin doğru yapılandırıldığını varsayar:
- TLS sonlandırma ve doğru proxy header politikası
- güvenli secret yönetimi ve anahtar rotasyonu
- PostgreSQL/Redis erişim kontrolü
- Discord OAuth uygulama ayarları
- route seviyesinde doğru action eşlemesi
- domain yazımlarında fencing ve unique constraint kullanımı
- log, trace ve hata izleme altyapısı
Bilerek kapsam dışında kalanlar
Paket şunları otomatik çözmez:
- dashboard HTML/React arayüzündeki XSS açıkları
- Discord bot token'ının işletim sistemi seviyesinde korunması
- veritabanı yedekleme ve felaket kurtarma
- üçüncü taraf API'nin erişilebilirliği
- uygulamaya özel rol hiyerarşisi ve iş kuralları
- kötü amaçlı dependency veya CI hesabı ele geçirilmesi
Fail-open ve fail-closed kararları
Her bağımlılık aynı hata politikasını kullanmaz. Örnekler:
- Yetkilendirme çözülemiyorsa yazma reddedilir.
- Fail-closed listesinde olan action için audit yazılamıyorsa transaction commit edilmez.
- Commit sonrasında cache veya realtime yayınlanamazsa domain yazımı başarılı kalır; sorun tekrar kuyruğuna ve telemetriye gider.
- Harici Discord okuması için retry, timeout ve circuit breaker sınırları action'a göre seçilir.
İnceleme kontrolü
Bir action eklerken şu soruları cevapla:
- Kaynak kimliği kullanıcı girdisinden nasıl ayrıştırılıyor?
- Yetki hangi anda ve hangi Discord verisiyle doğrulanıyor?
- İstek tekrar edilirse aynı sonuç güvenli biçimde dönebiliyor mu?
- İki worker aynı kaynağı yazarsa hangisi kazanıyor?
- Commit sonrası yan etki başarısız olursa nasıl tekrar deneniyor?
- Audit kaydı secret veya gereksiz kişisel veri içeriyor mu?
- Realtime aboneliği yetki kaybında kapanıyor mu?
Bu cevapları action tanımında, store sözleşmesinde ve testlerde görünür tut.