Menjawab Tantangan Session Fixation dan Token Reuse di API Stateless

API stateless tidak menyimpan session server-side sehingga rentan pada token yang disalahgunakan lewat session fixation atau reuse. Untuk menanggulanginya, API harus mampu memverifikasi asal permintaan dan melakukan binding token pada metadata yang dinamis. Dengan pendekatan ini, API dapat mendeteksi mana token yang diambil alih atau digunakan ulang dari konteks yang tidak cocok.

Artikel ini menjelaskan langkah-langkah teknis: validasi header/origin, binding token dengan metadata seperti perangkat dan IP, rotasi secret minimal sekali, mekanisme refresh token dengan daftar revokasi, serta pengawasan anomali untuk indikator penyalahgunaan.

1. Deteksi Awal melalui Validasi Header/Origin

API stateless harus memastikan header seperti Origin atau Referer konsisten dengan sumber yang terdaftar. Dalam praktiknya, server mencocokkan nilai header tersebut terhadap daftar domain/proxy yang sah sebelum memproses token. Penolakan jika header hilang atau tidak cocok mencegah token yang dicuri dari situs lain digunakan.

Pengecekan header harus mempertimbangkan arsitektur jaringan (misalnya proxy internal atau CDN) dan memperkuat dengan penambahan header proprietari (seperti X-Client-ID) untuk membedakan sumber permintaan.

2. Binding Token dengan Metadata yang Dinamis

Untuk mencegah reuse token di luar konteks, sertakan metadata yang terikat pada token saat membuat JWT atau access token pu. Binding metadata ini bisa berupa ID perangkat, rentang IP, dan fingerprint user-agent. Ketika token diterima kembali, middleware memverifikasi bahwa metadata dikirimkan ulang dan sesuai dengan yang tersimpan pada claim token atau basis data.

Jika metadata tidak valid atau tidak cocok, token ditolak tanpa perlu menyimpan session server-side.

Contoh Pseudocode Middleware

function validateRequest(request) {
  const token = extractBearerToken(request.headers.Authorization);
  if (!token || !validateSignature(token)) {
    return errorResponse(401, "Token tidak valid");
  }

  const claims = decodeToken(token);
  if (!validateOrigin(request.headers, claims.allowedOrigins)) {
    return errorResponse(403, "Origin tidak sah");
  }

  if (!matchMetadata(request.device, claims.deviceId, request.ip, claims.ipRange)) {
    return errorResponse(403, "Context metadata tidak sesuai");
  }

  if (isTokenRevoked(claims.tokenId)) {
    return errorResponse(401, "Token sudah dicabut");
  }

  return proceed(claims.userId);
}

Pseudocode di atas menekankan validasi berlapis di middleware. Validasi metadata memastikan token yang valid tetap tidak bisa digunakan apabila dipindahkan ke perangkat lain.

3. Rotasi Secret Minimum Sekali

Token JWT atau HMAC tetapi menggunakan secret statis rentan jika terjadi kebocoran. Rotasi secret setidaknya sekali (misalnya mingguan) dan dukungan untuk header kid memudahkan server menerima token yang ditandatangani oleh secret lama sementara sedang berganti.

Selalu simpan secret terdahulu dalam daftar terverifikasi hingga semua token cadangan kedaluwarsa. Ini meminimalkan ruang serangan sekaligus tidak memblokir pengguna selama periode rotasi.

4. Refresh Token dengan Daftar Revokasi

Karena refresh token sering panjang masa berlakunya, rawan reuse bila dicuri. Terapkan daftar revokasi untuk refresh token yang sudah dipakai atau dilaporkan hilang. Ketika refresh request terjadi, server harus:

  • Verifikasi bahwa refresh token belum dicabut.
  • Catat hash refresh token dan tandai sebagai digunakan untuk mencegah replay.
  • Hasilkan access token baru dan keluarkan refresh token baru (rotasi refresh token).

Teknik ini membatasi durasi hidup refresh token dan mencegah reuse setelah logout atau komplain.

5. Monitoring dan Deteksi Anomali

Deteksi manual tidak cukup. Awasi metrik seperti banyaknya permintaan token dari satu kredensial dalam waktu singkat, geografis berbeda, atau perubahan metadata tak wajar. Buat rule yang memicu pemblokiran atau wajib MFA ketika pola anomali terdeteksi.

Integrasikan log ke sistem SIEM atau observability untuk analisa lanjutan. Peninjauan rutin terhadap kasus false positive membantu menyempurnakan aturan.

6. Template Response Error Aman

Saat token ditolak, respons harus informatif tapi tidak mengungkap detail internal.

{
  "status": "error",
  "code": 401,
  "message": "Autentikasi gagal. Periksa token dan metadata.",
  "requestId": "uuid-1234",
  "timestamp": "2024-04-25T12:00:00Z"
}

Gunakan requestId untuk menyambungkan ke log internal tanpa memberikan rincian teknis kepada pengguna.

Kesimpulan

API stateless bisa mengenali dan menolak session fixation serta token reuse lewat kombinasi validasi header/origin, binding metadata, rotasi secret, pengelolaan refresh token dengan revocation, dan monitoring. Pseudocode middleware menunjukkan alur validasi yang diperlukan, dan template error menjaga respons tetap aman. Pendekatan ini memastikan token hanya digunakan pada konteks yang sesuai dan memudahkan deteksi penyalahgunaan.