API berbasis Go Fiber sering menggunakan sesi untuk otentikasi pengguna. Untuk mencegah sesi dibajak atau diedarkan secara berlebihan, perlu dilakukan validasi input session, rotasi secret/token, penyimpanan rahasia yang aman, serta pembatasan permintaan. Artikel ini langsung menjelaskan implementasi teknis pada tiap tahap agar sesi tetap terkendali.
1. Validasi Input Session sebelum diproses
Sebelum menyimpan atau memulihkan session dari header/cookie, verifikasi dulu format dan ukuran data yang diterima. Validasi mencegah serangan pemalsuan, injection, atau parameter berbahaya yang hanya terlihat setelah sesi di-kompromikan.
Middleware validasi payload session
Gunakan middleware Fiber untuk memastikan payload memiliki struktur yang diharapkan. Contoh berikut memeriksa header Authorization dan membatasi panjangnya.
func ValidateSessionHeader() fiber.Handler {
return func(c *fiber.Ctx) error {
auth := c.Get("Authorization")
if len(auth) == 0 || len(auth) > 256 {
return fiber.NewError(fiber.StatusBadRequest, "Authorization header tidak valid")
}
if !strings.HasPrefix(auth, "Bearer ") {
return fiber.NewError(fiber.StatusUnauthorized, "Token harus diawali Bearer")
}
token := strings.TrimPrefix(auth, "Bearer ")
if len(token) < 32 {
return fiber.NewError(fiber.StatusUnauthorized, "Token terlalu pendek")
}
c.Locals("session_token", token)
return c.Next()
}
}
Middleware ini mencegah header kosong, terlalu panjang, atau bukan bearer token. Gunakan c.Locals untuk meneruskan token ke handler berikutnya tanpa mengakses kembali header mentah.
2. Rotasi Secret/Token Session
Rotasi secret secara berkala mengurangi dampak jika secret lama bocor. Pendekatan yang aman adalah menyimpan secret versi terbaru dan sebelumnya di sistem penyimpanan rahasia (Vault, AWS Secrets Manager, dll) dan mengecek terhadap dua versi saat memvalidasi.
Strategi rotasi
- Simpan secret dalam bentuk versioned dan gunakan metadata timestamp.
- Kombinasikan rotasi dengan expiring token: setelah rotasi, secret lama tetap diterima selama periode grace (misalnya 5 menit) untuk menghindari gangguan client.
- Gunakan hook rotasi otomatis (cron job, scheduler) untuk memperbarui secret di environment, lalu restart service minimal atau gunakan hot-reload jika Fiber dijalankan dalam container.
Mengambil secret dari environment/Vault
Ambil konfigurasi secret dari environment yang bisa diisi melalui secret manager. Hindari menulis secret di kode.
func LoadSessionSecret() string {
secret := os.Getenv("SESSION_SECRET")
if secret == "" {
log.Fatal("SESSION_SECRET harus di-set")
}
return secret
}
// Jika menggunakan Vault-compatible tool, lakukan HTTP GET ke endpoint yang sudah tersegel
// dan letakkan hasilnya di env variable sebelum aplikasi dijalankan.
Cara ini memastikan secret tidak ada di repo dan bisa dirotasi dengan mengganti nilai SESSION_SECRET di pipeline deployment tanpa mengubah kode.
3. Rate Limit dan Pencegahan Penyalahgunaan Session
Rate limit penting untuk membatasi percobaan brute force atau flood token validation. Go Fiber menyediakan middleware bawaan, tetapi integrasikan dengan storage eksternal seperti Redis saat running di banyak instance.
Rate limit berbasis Redis
func SessionRateLimiter(redisClient *redis.Client) fiber.Handler {
store := limiter.NewStoreWithOptions(redisClient, limiter.StoreOptions{Prefix: "session_rate"})
middleware := limiter.New(limiter.Config{Max: 20, Expiration: 1 * time.Minute, Store: store})
return middleware
}
Pada konfigurasi di atas, satu session/token hanya boleh memanggil endpoint sensitif 20 kali per menit. Redis memastikan limit global untuk seluruh cluster Fiber.
Alternatif memory cache
Untuk environment single-node, memory.NewStore() Fiber sudah cukup, tetapi jangan gunakan saat ada banyak instance karena limit tidak disinkronkan.
4. Menangani Upload dan Parameter Berisiko
Upload file dan parameter besar berpotensi menyebabkan DoS atau memaksa parsing session berbahaya. Terapkan validasi berikut sebelum sesi diproses:
- Batasi ukuran maksimum body (
app.Use(bodyparser.Config{BodyLimit: 10 * 1024 * 1024})untuk 10MB). - Validasi tipe konten dan hanya terima
application/jsonuntuk payload session. - Gunakan middleware yang menolak multipart jika tidak diperlukan untuk endpoint sesi.
Jika aplikasi juga menerima file user, letakkan upload di endpoint terpisah dan jangan gunakan sesi untuk transport file langsung. Validasi nama file, MIME type, dan scan virus jika perlu.
5. Debugging dan Pemantauan
Tambahkan logging terstruktur saat session ditolak atau rate limit tercapai. Catat metadata seperti IP, user-agent, dan timestamp. Gunakan alert untuk anomali—misalnya, peningkatan signifikan error 401/429.
Checklist Operasional untuk Audit Keamanan Session
- ✅ Middleware validasi session diterapkan pada semua endpoint sensitif.
- ✅ Secret/ token disimpan di environment yang dapat dirotasi (Vault atau secret manager) dan tidak di-hardcode.
- ✅ Proses rotasi secret terdokumentasi dan memiliki grace period untuk backwards compatibility.
- ✅ Rate limit terdistribusi (Redis) diberlakukan pada semua operasi session untuk mencegah brute force.
- ✅ Upload/parameter besar tidak mengubah jalur validasi session; ada batas ukuran dan tipe konten.
- ✅ Logging/metrics mencatat percobaan gagal dan rate limit trigger untuk investigasi.
Komentar
0 komentar
Masuk ke akun kamu untuk ikut berkomentar.
Belum ada komentar
Jadilah yang pertama ikut berdiskusi!