Go Fiber Hardening Auth fokus pada memperkuat lapisan autentikasi publik dengan validasi request yang ketat dan middleware guard yang cocok. Penjelasan berikut langsung memberikan tindakan teknis: bagaimana threat model memengaruhi pilihan middleware, rotasi secret yang bisa dijalankan tanpa downtime, serta pemeriksaan upload dan rate limit agar sistem tetap resilient.

Threat Model dan Pemilihan Middleware

Dalam lingkungan publik, pelaku ancaman utama adalah credential stuffing, injection via request yang tidak tervalidasi, serta payload upload yang berbahaya. Anda harus menganggap setiap permintaan datang dari jaringan tidak dipercaya, sehingga lapisan autentikasi harus memvalidasi header, body, dan token secara eksplisit sebelum mencapai handler bisnis.

Pilih middleware Fiber yang mendukung validasi awal: fiber/middleware/enforce untuk memastikan header khusus ada, fiber/middleware/logger untuk mencatat anomali awal, serta fiber/middleware/csrf jika menyertakan cookie-based session. Jangan bergantung pada satu middleware; kombinasikan guard token (JWT/opaque) dan session guard (misalnya, middleware tersendiri yang mengevaluasi session ID yang ditandatangani dan disimpan di Redis).

Tambahkan guard khusus yang membaca context request untuk memastikan hanya metode HTTP yang diizinkan, origin yang sah, dan rate limit awal masih belum terlampaui. Ini membantu menahan bot sebelum mencapai layer autentikasi yang lebih berat.

Polapola Validasi Request dan Session/Auth Guard

Gunakan middleware custom untuk memeriksa struktur request standar: Content-Type harus sesuai, body JSON tervalidasi dengan schema sederhana, dan header khusus (seperti X-Request-ID atau X-App-Version) wajib ada jika digunakan untuk tracing. Validasi ini membuat logika autentikasi tidak perlu menangani request malformed.

Session guard berbasis Redis dapat terlihat seperti berikut: middleware membaca cookie session, melakukan lookup pada storage terpercaya (Redis dengan TTL singkat), kemudian memasang data user ke ctx.Locals. Dalam kasus token bearer, pastikan token diverifikasi terhadap secret aktif.

Lapisan guard harus modular agar bisa digunakan ulang di endpoint publik dan internal. Misalnya, buat fungsi helper RequireAuthenticatedUser dan RequireAdminScope yang dipanggil dari app.Use atau route group. Ini memudahkan pengujian satuan dan integrasi.

Rotasi Secret dan Key Store

Rotasi secret menjadi penting ketika secret digunakan untuk menandatangani JWT, HMAC header, atau token lainnya. Strategi yang aman adalah menyimpan sekelompok key di key store internal (misalnya, konfigurasi yang dibaca dari Vault atau file terenkripsi) dengan atribut current dan fallback. Dengan cara ini, validasi dapat menggunakan lebih dari satu secret sekaligus.

type SecretKey struct {
    Name      string
    Value     []byte
    CreatedAt time.Time
}

type RotatingKeyStore struct {
    sync.RWMutex
    Active  SecretKey
    Legacy  []SecretKey
}

func (ks *RotatingKeyStore) Rotate(newKey SecretKey) {
    ks.Lock()
    defer ks.Unlock()
    ks.Legacy = append([]SecretKey{ks.Active}, ks.Legacy...)
    ks.Active = newKey
    if len(ks.Legacy) > 3 {
        ks.Legacy = ks.Legacy[:3]
    }
}

func (ks *RotatingKeyStore) GetCandidates() []SecretKey {
    ks.RLock()
    defer ks.RUnlock()
    return append([]SecretKey{ks.Active}, ks.Legacy...)
}

Middleware autentikasi mengecek token terhadap GetCandidates(), sehingga rotasi tidak menyebabkan gangguan. Rotasi dapat dilakukan via cron job internal yang mengambil key baru dari Vault/Secret Manager dan memanggil Rotate. Pastikan key lama tetap tersedia selama periode grace (misalnya 5-10 menit) untuk menghindari invalidasi tiba-tiba pada token aktif.

Kontrol Upload dan Pemeriksaan Tambahan

Upload file rentan terhadap malware, file besar, dan mime-type spoofing. Terapkan middleware yang mengecek:

  • Size dengan ctx.Request().Header.Content-Length dan batas buffer yang aman.
  • Mime-type valid dengan membatasi ke daftar yang diperbolehkan dan cek byte signature (misalnya 4 byte pertama).
  • Antivirus dengan pipeline yang mengirimkan file ke proses eksternal (ClamAV melalui socket atau scanning service) sebelum menyimpannya.

Contoh pendek: 

func validateUpload(ctx *fiber.Ctx) error {
    if ctx.Request().Header.ContentLength() > maxUploadSize {
        return ctx.Status(fiber.StatusRequestEntityTooLarge).SendString("ukuran file terlalu besar")
    }
    file := ctx.Request().Body()
    mime := http.DetectContentType(file[:512])
    if !allowedMime[mime] {
        return ctx.Status(fiber.StatusUnsupportedMediaType).SendString("mime-type tidak diperbolehkan")
    }
    if err := scanWithClamAV(file); err != nil {
        return ctx.Status(fiber.StatusBadRequest).SendString("file terindikasi berbahaya")
    }
    return nil
}

Setelah pemeriksaan awal, file dapat disimpan ke storage dengan metadata yang mencatat hasil scan agar bisa diaudit. Pastikan response tidak membeberkan informasi sensitif tentang alasan kegagalan (misalnya hanya mengirim status 400 umum).

Rate Limit, Abuse Guard, dan Monitoring Fallback

Credential stuffing menargetkan endpoint login atau token refresh. Terapkan middleware rate limiter seperti fiber/middleware/limiter berdasarkan kombinasi IP+username, bukan hanya IP. Tambahkan guard tambahan seperti progressive delay atau lockout setelah percobaan berulang.

Lapisan ini harus dikombinasikan dengan monitoring: setiap penolakan rate limit mencatat ke sistem observasi (Prometheus, Grafana, atau Sentry) agar pattern dapat dilihat. Jika limiter gagal (misalnya sudah over limit), fallback bisa mengalihkan ke queue event semacam Kafka untuk analitik tanpa memengaruhi pengalaman user.

Gunakan metrik untuk memantau false positive dan false negative (misalnya login yang sebenarnya valid tapi terbatas), kemudian sesuaikan threshold. Untuk monitoring tambahan, buat alert jika pelanggaran rate limit melonjak drastis dalam waktu singkat.

Kesimpulan

Go Fiber memungkinkan hardening otentikasi publik dengan kombinasi validasi request awal, middleware guard, rotasi secret yang terkontrol, pemeriksaan upload, serta rate limit/monitoring yang proaktif. Fokus pada threat model nyata—credential stuffing, spoofing upload, dan secret compromise—memungkinkan lapisan keamanan yang tahan uji tanpa memperlambat pengembangan fitur.