Untuk menjaga API publik tetap dapat diakses tanpa membuka celah keamanan, Anda perlu menggabungkan rotasi kredensial, proteksi session, validasi input, dan mekanisme pembatasan permintaan. Artikel ini menjelaskan setiap langkah secara praktis agar tim backend dapat menutup titik serang yang umum dan tetap melayani pengguna dengan andal.

Di bagian berikut, kami membahas pola arsitektur, ancaman utama, dan checklist operasional sehingga praktek terbaik mudah dipahami dan diimplementasikan.

1. Pola Arsitektur untuk Rotasi Token dan Session

Rotasi token adalah pengiriman kredensial jangka pendek sekaligus memperbarui status session tanpa mengandalkan token statis. Struktur arsitekturnya melibatkan pengelola otentikasi (authentication service) yang menghasilkan pasangan token akses jangka pendek dan refresh token yang lebih tahan lama.

Contoh pola:

  • API Gateway memverifikasi token akses setiap permintaan dan meneruskan header ke microservice.
  • Authentication Service menyimpan metadata token pada storage terpisah (misalnya database atau cache tersegel) untuk memudahkan pencabutan.
  • Token Rotation Worker melakukan perpanjangan dengan memvalidasi refresh token, mencatat session baru, dan mencabut token lama.

Keuntungan pendekatan ini adalah pencabutan bisa dipicu dari satu tempat, dan token akses bisa sangat singkat sehingga pencurian cepat kedaluwarsa.

Implementasi rotasi token

Gunakan pola berikut secara umum:

  1. Token akses (misalnya JWT) berumur pendek (10–15 menit) dan ditandatangani server.
  2. Refresh token tersimpan di storage terenkripsi, direferensikan oleh session ID.
  3. Setiap permintaan refresh memicu invalidasi token sebelumnya.

Contoh pseudocode untuk proses refresh:

if refreshToken.isValid() and refreshToken.sessionId == sessionId:
    revokeToken(refreshToken.activeAccessToken)
    newAccessToken = createJwt(sessionData)
    updateSession(sessionId, newAccessToken)
    return newAccessToken
else:
    raise AuthenticationError

Catatan: Jangan simpan refresh token di database sebagai teks terbuka; gunakan hashing atau enkripsi dengan KMS.

2. Menyimpan Secret dan Proteksi Session State

Rahasia seperti kunci JWT, secret refresh token, dan credential OAuth harus dikelola oleh sistem manajemen secret (contohnya HashiCorp Vault, AWS KMS, atau Azure Key Vault). Gunakan rotasi otomatis secret dan hanya izinkan komponen yang memerlukannya.

Untuk session state, pisahkan data session dari data bisnis utama:

  • Simpan metadata session (waktu login, IP rafik) di cache yang bisa dihapus (Redis dengan TTL pendek).
  • Gunakan signed cookie atau token tanpa menaruh data sensitif pada client.
  • Panggil revoke melalui endpoint internal saat anomali terdeteksi.

Proteksi session state

Jaga hubungan antara session dan user dengan menerapkan gating:

  • Validasi IP/perangkat setelah login awal.
  • Beri mekanisme force logout melalui update flag di session store.
  • Pastikan cache session seperti Redis memerlukan TLS dan autentikasi.

3. Validasi Input dan Upload untuk API Publik

Input yang tidak tervalidasi menjadi pintu masuk serangan seperti SQL injection atau deserialization. Terapkan pendekatan berikut:

  • Gunakan JSON Schema atau library validator untuk memeriksa tipe, panjang, dan pattern field.
  • Batasi ukuran payload JSON dan file upload di layer gateway.
  • Normalisasi data (trimming, canonicalization) sebelum diproses.

Untuk upload file, lakukan:

  • Validasi MIME type dan ekstensi.
  • Scan file dengan antivirus/cloud scanner dan tempatkan di storage yang tidak dapat dieksekusi.
  • Susun penanganan upload asynchronous melalui queue untuk menghindari blocking.

Jika API menerima binary data, pastikan pemeriksaan length dan signature dilakukan sebelum parsing ke modul lain.

4. Rate Limit dan Pelacakan Abuse

Menerapkan rate limit akan menahan eksploitasi brute force dan DDoS tingkat ringan. Terapkan beberapa lapis:

  • Rate limit berdasarkan API key/token di API Gateway (contoh: 100 request/mnt per key).
  • Threshold per IP untuk mencegah kluster IP palsu.
  • Behavioral monitoring untuk mendeteksi pola abuse (spike request, mencoba semua endpoint).

Pertimbangkan sistem seperti API gateway (Kong, Apigee) yang mendukung policy rate limit berbasis bucket.

Untuk pelacakan abuse, catat metrik berikut:

  • Jumlah batasan yang tercapai.
  • Retry header yang dikirim ke client.
  • Penggunaan token baru vs lama.

Perlu juga menyertakan endpoint pembatasan manual (misalnya /admin/blacklist) untuk memblokir token yang disalahgunakan.

5. Skenario Ancaman Umum dan Respon

Scenario: penyerang mencuri refresh token lewat XSS di dashboard pengguna. Tanpa validasi sesi dan rotasi, token ini bisa digunakan selama minggu.

Respon terbaik: ketika backend mendeteksi login dari lokasi berbeda atau permintaan refresh berulang, segera panggil revoke dan kirim notifikasi. Tambahkan mekanisme threshold refresh token per-jam.

Catatan: Jangan hanya mengandalkan expiration; implementasikan prosedur revocation dan audit untuk setiap rotasi.

6. Checklist Operasional Backend

Gunakan checklist ini sebelum meluncurkan API publik atau saat peninjauan keamanan berkala:

  1. Token akses memiliki TTL pendek, dan refresh token disimpan terenkripsi.
  2. Rotasi token tercatat dalam log audit dengan metadata session.
  3. Session store (cache/database) menggunakan TLS, autentikasi, dan TTL agresif.
  4. Input request divalidasi dengan schema/kode kuat, termasuk upload file.
  5. Rate limit dikonfigurasi di gateway serta dipantau metrik failure.
  6. Pendeteksian abuse otomatis (log anomalous traffic) dan cara revoke dijelaskan.
  7. Tim DevOps memiliki runbook untuk revocation token massal dan pemantauan rate limit.

Penutup

Mengamankan API publik membutuhkan pendekatan berlapis: rotasi token dan session state memastikan kredensial tidak bertahan terlalu lama; validasi input dan upload menutup permukaan serangan; rate limit dan pelacakan abuse menjaga keandalan layanan. Dengan checklist operasional dan threat scenario yang jelas, tim backend bisa mempertahankan keamanan tanpa mengorbankan ketersediaan.