## Go Backend API Güvenlik Raporu

### 1. Genel Değerlendirme

- **Kapsam**: Kod tabanı üzerinden statik güvenlik analizi ve `go vet ./...` ile temel statik araç kontrolü.
- **Genel Sonuç**: Mimari olarak sağlam bir temel var (JWT, rol tabanlı yetki, rate limit, CORS). En önemli eksik, **refresh token güvenliğinin state-less olması (rotation/revoke yok)** ve **API tarafında token invalidation / logout akışının olmaması**.

### 2. Güçlü Yönler

- **JWT ve Kimlik Doğrulama**
  - HS256 ile imzalama yapılıyor ve `SigningMethodHMAC` kontrolü var → `alg: none` benzeri saldırılara karşı temel koruma mevcut.
  - Access / refresh token ayrımı `TokenType` alanı ile net; `RequireAuth` yalnızca access token kabul ediyor.
  - Email doğrulaması yapılmadan login’e izin verilmiyor.

- **Rol ve Yetkilendirme**
  - Public API tarafında admin işlemleri `RequireAuth` + `RequireAdmin` middleware’leri ile korunuyor.
  - Admin panel altındaki `"/admin"` rotaları global olarak `RequireAuth` + `RequireAdmin` ile kapalı.

- **CORS**
  - DB + Redis destekli whitelist/blacklist ile **default deny** yaklaşımı kullanılıyor.
  - Same-origin istekler her zaman izinli, wildcard `*` yok → klasik açık CORS yanlış konfigürasyonları görülmedi.

- **Rate Limiting**
  - `/api/v1` için global; `/auth/login` ve `/auth/refresh` için isimlendirilmiş rate limit profilleri tanımlı.
  - Redis tabanlı sayaçlar ile limit aşıldığında `429` ve `Retry-After` header’ı dönüyor.

- **Admin Oturumu (Browser)**
  - `admin_session` cookie: `HttpOnly`, `Secure`, `SameSite=Strict` → XSS sonrası cookie çalınması ve CSRF riskleri azaltılmış.
  - Admin login’de parolalar `bcrypt` ile doğrulanıyor.

### 3. Tespit Edilen Riskler ve Öneriler

#### 3.1 Refresh Token Rotation & Revoke Eksikliği (Kritik / Yüksek Öncelik)

- **Durum**:
  - `/api/v1/auth/refresh` endpoint’i yalnızca:
    - JWT imzasını,
    - `TokenType == refresh` olmasını
    kontrol ediyor.
  - Refresh token’lar için DB/Redis tabanlı bir “token store”, revoke listesi veya rotation takibi yok.
- **Risk**:
  - Bir refresh token ele geçirilirse, süresi dolana kadar sınırsız sayıda yeni access token üretmek için yeniden kullanılabilir.
  - Token reuse (aynı refresh token’ın birden fazla kez kullanılması) tespit edilemiyor.
- **Öneri**:
  - Refresh token’lar için tablo veya Redis store tasarla:
    - Her refresh isteğinde:
      - Eski refresh token’ı **geçersiz** kıl (rotation),
      - Yeni bir refresh token üret ve store’a kaydet.
    - Aynı refresh token ikinci kez kullanılırsa:
      - İlgili hesabı veya oturumu geçici olarak kilitle,
      - Gerekirse tüm tokenlarını revoke et (global logout).
  - Mümkünse refresh token’ları **HTTP-only cookie** ile taşı (XSS’e karşı daha dirençli).

#### 3.2 API Logout / Token İptali Eksikliği (Orta–Yüksek)

- **Durum**:
  - Public API’de `/api/v1/auth/logout` benzeri bir endpoint yok.
  - Client tarafında yalnızca local storage / memory’den token silinerek logout yapılıyor; backend tarafında “session state” yok.
- **Risk**:
  - Bir access veya refresh token sızdığında, expire olana kadar backend tarafında bunu geçersiz kılma imkânı yok.
  - Özellikle refresh token için kritik: saldırgan elinde refresh token olduğu sürece yeni access token üretebilir.
- **Öneri**:
  - `/api/v1/auth/logout` endpoint’i ekle:
    - İlgili kullanıcının aktif refresh token kaydını (veya kayıtlardan birini) revoke listesine ekle ya da store’dan sil.
    - İsteğe bağlı olarak access token için kısa süreli bir blacklist kullan (jti/subject bazlı).
  - Admin panel logout şu an cookie temizliyor; bunu backend tarafında da bir “session invalidation” akışı ile desteklemek düşünülebilir.

#### 3.3 Token İçeriğinin Loglanması (Düşük–Orta)

- **Durum**:
  - `GenerateTokenPair` içinde development ortamında hem access hem refresh token string’leri loglanıyor.
  - Refresh akışında `fmt.Println(accessToken, "Access Token Yenilendi !!!")` ile access token stdout’a yazılıyor.
- **Risk**:
  - Production konfigürasyonu yanlış yapılırsa, log dosyalarında tam token değerleri yer alabilir.
- **Öneri**:
  - Production ortamında:
    - Token gövdesini **asla** loglama; yalnızca `userID`, `exp`, `tokenType` gibi meta verileri logla.
  - Development ortamında bile mümkünse:
    - Token’ı maskeleyerek veya kısmi göstererek logla (örneğin sadece ilk 6 + son 4 karakter).

#### 3.4 Admin Login – Captcha / Turnstile Doğrulaması Tamamlanmamış (Orta)

- **Durum**:
  - Admin login formu `cf-turnstile-response` alanını okuyor ancak gerçek Cloudflare Turnstile doğrulaması yapılmıyor.
  - Rate limiting mevcut olsa da insan/makine ayrımı yok.
- **Risk**:
  - Admin hesabı için brute force ve credential stuffing saldırılarına karşı savunma zayıf kalıyor.
- **Öneri**:
  - Cloudflare Turnstile veya benzeri servis için gerçek HTTP doğrulamasını ekle:
    - Turnstile token’ı backend’de doğrulanmadan login’e izin verme.
  - Başarısız giriş denemelerine göre:
    - IP ve hesap bazlı ek limitler veya geçici hesap kilitleme mekanizması eklemeyi değerlendir.

#### 3.5 Redis Yoksa Rate Limit & CORS Enforcement’ın Devre Dışı Kalması (Düşük–Orta)

- **Durum**:
  - Redis bağlantısı yoksa, rate limit ve CORS cache tarafı graceful fail yapıyor ve bazı kontroller uygulanmayabiliyor.
- **Risk**:
  - Production’da Redis yanlış konfigüre edilirse, rate limit fiilen devre dışı kalabilir; CORS kontrolleri de zayıflayabilir.
- **Öneri**:
  - Production ortamında Redis’i **zorunlu bağımlılık** haline getir:
    - Redis’e bağlanılamıyorsa servisi başlatma (fail-fast).
  - Redis bağlantı hatalarını loglarda daha yüksek seviye (error) olarak işaretle.

### 4. `go vet` Çıktısı Özeti

- `go vet ./...` komutu çalıştırıldığında:
  - `scripts/seed.go` içinde aynı pakette birden fazla `main` fonksiyonu olduğu için “main redeclared” uyarısı veriliyor.
- **Not**:
  - Bu, güvenlikten ziyade script yapısına dair yapısal bir uyarı; istenirse ilgili script ayrı bir pakete veya dosya yapısına taşınarak temizlenebilir.

### 5. Önerilen İyileştirme Planı (Önceliklendirilmiş)

1. **Kritik (kısa vadede)**:
   - Refresh token için rotation + revoke mekanizması tasarlayıp uygulamak.
   - Public API için `/api/v1/auth/logout` endpoint’i ekleyip refresh (ve gerekiyorsa access) token’larını server-side olarak da geçersiz kılmak.
   - Production’da token içeriğini loglamayı tamamen kapatmak; development’ta da maskelemek.

2. **Orta vadede**:
   - Admin login için gerçek Turnstile (veya eşdeğer captcha) doğrulamasını devreye almak.
   - Redis’i production ortamında zorunlu hale getirip rate limit/CORS’un Redis olmadan çalışmamasını sağlamak (fail-fast yaklaşımı).

3. **Uzun vadede**:
   - Bu rapora göre hazırlanmış, dış pentest’e verilebilecek detaylı bir test senaryoları dokümanı oluşturmak (mevcut `guvenlik.md` şablonunu projeye özgü endpoint/roller ile doldurmak).