Wawancara Backend: Bagaimana Cara Merancang Manajemen Sesi Web yang Aman?

Perintah dan Konteks yang Berlaku

Rancang manajemen sesi untuk aplikasi web B2B dua wilayah. Browser menggunakan sesi sisi server untuk akses normal dan administrator. Produk membutuhkan logout pada perangkat saat ini, logout di semua perangkat, dan pencabutan setelah perubahan kata sandi. Logout global harus menolak permintaan terproteksi di kedua wilayah dalam waktu lima detik.

Untuk latihan ini, pilih pengidentifikasi buram (opaque identifier) 256-bit, batas waktu idle 30 menit, dan batas waktu absolut 12 jam. Ini adalah keputusan skenario, bukan konstanta keamanan universal. Jelaskan apa yang berubah saat login, peningkatan hak administrator, kedaluwarsa, logout, dan peristiwa dugaan pencurian. Sertakan penanganan permintaan bersamaan (concurrent requests) dan propagasi lintas wilayah daripada hanya mendeskripsikan atribut cookie.

Ini adalah pertanyaan siklus hidup backend. Desain yang kuat membuat token browser tidak memiliki arti (meaningless), menjadikan server sebagai otoritas tunggal untuk status autentikasi, merotasi identitas saat melintasi batas kepercayaan (trust-boundary), dan dapat membuktikan bahwa kredensial lama berhenti berfungsi. Secure, HttpOnly, dan SameSite penting, tetapi tidak satu pun dari mereka yang sendirian menyediakan kedaluwarsa sisi server, otorisasi, atau pencabutan.

Hal yang Dievaluasi Pewawancara

Sinyal pertama adalah apakah kandidat memperlakukan pengidentifikasi sesi sebagai kredensial pembawa (bearer credential) sementara. Pengidentifikasi tersebut harus tidak dapat ditebak, diterima melalui satu mekanisme yang dituju, dilindungi saat transit dan saat istirahat (at rest), serta tidak ada di URL dan log. Pembaca basis data atau pembaca log tidak boleh secara otomatis mendapatkan token yang dapat digunakan.

Sinyal kedua adalah penalaran siklus hidup. Pengidentifikasi anonim tidak boleh begitu saja menjadi terautentikasi. Login dan peningkatan hak istimewa melintasi batas kepercayaan, sehingga aplikasi membuat pengidentifikasi baru dan menghancurkan yang lama. Kedaluwarsa idle dan absolut ditegakkan oleh server. Menghapus cookie browser hanyalah pembersihan sisi klien; hal itu tidak mencabut salinan yang sudah dipegang oleh penyerang.

Sinyal ketiga adalah perbedaan antara autentikasi dan otorisasi. Sesi yang valid menemukan pengguna dan konteks autentikasi. Setiap permintaan tetap memeriksa keanggotaan penyewa (tenant) dan izin saat ini. Menyalin peran (roles) ke dalam rekaman sesi berumur panjang tanpa aturan pembatalan validasi (invalidation rule) dapat mempertahankan akses setelah administrator menghapus suatu peran.

Sinyal keempat adalah konsistensi terdistribusi. Janji bahwa logout global berlaku dalam lima detik memerlukan versi otoritatif atau status pencabutan, batas keusangan cache yang terikat (bounded cache staleness), dan perilaku selama terjadinya partisi jaringan. Mengatakan "hapus saja dari Redis" tidaklah lengkap ketika wilayah lain masih dapat terus menggunakan hasil positif yang di-cache.

Sinyal terakhir adalah verifikasi. Kandidat harus mengubah fiksasi, pencurian, CSRF, kedaluwarsa, rotasi bersamaan, kelambatan replika (replica lag), dan kebocoran log menjadi kasus uji yang dapat dieksekusi. Klaim keamanan menjadi kredibel ketika setiap pengidentifikasi lama memiliki peristiwa spesifik yang setelahnya permintaan yang menggunakannya harus gagal.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Klien mana saja yang masuk dalam cakupan? Jawaban ini menargetkan aplikasi browser same-site. Aplikasi native dan

klien API pihak ketiga biasanya memerlukan transport token dan siklus hidup yang berbeda.

• Apa arti "dalam waktu lima detik"? Server harus sudah menolak permintaan terproteksi pada saat itu. Tab browser

mungkin masih menampilkan konten lama sampai permintaan berikutnya dilakukan.

• Apakah sesi simultan diizinkan? Desain ini mengizinkan beberapa perangkat dan menyimpan setiap sesi

secara terpisah. Produk yang lebih ketat dapat membatasinya atau mengganti sesi yang lebih lama saat login.

• Peristiwa mana yang mencabut semuanya? Logout global dan perubahan kata sandi menaikkan (increment) epoch sesi

seluruh akun. Perubahan izin dapat menaikkan versi otorisasi tanpa harus mengeluarkan (sign out) setiap perangkat.

• Seberapa berisiko akses administrator? Desain ini melakukan rotasi saat peningkatan hak dan mencatat kekuatan

autentikasi. Operasi berdampak tinggi mungkin juga memerlukan reautentikasi terbaru.

• Apakah login lintas situs atau embedding harus berfungsi? SameSite=Lax cocok dengan asumsi navigasi first-party.

Alur lintas situs yang sah memerlukan pengecualian sempit ditambah perlindungan CSRF eksplisit.

• Apa yang terjadi selama partisi regional? Persyaratan keamanan lima detik mengimplikasikan perilaku fail-closed

untuk rute berisiko tinggi ketika status pencabutan terbaru tidak dapat diperoleh.

Kerangka Jawaban 30 Detik

"Saya akan menempatkan nilai buram 256-bit di dalam cookie __Host- dengan Secure, HttpOnly, Path=/, dan kebijakan SameSite eksplisit, sementara hanya menyimpan lookup key turunan HMAC di server. Baris sesi berisi pengguna, tenant, kekuatan autentikasi, waktu pembuatan dan aktivitas, waktu kedaluwarsa, serta versi sesi dan otorisasi pengguna. Login dan peningkatan hak administrator secara atomik menerbitkan sesi baru dan membatalkan pengidentifikasi lama. Setiap permintaan terproteksi menegakkan kedaluwarsa idle dan absolut, epoch akun saat ini, dan otorisasi saat ini. Logout mencabut baris sesi; logout-semua atau perubahan kata sandi menaikkan epoch akun dan memublikasikan pembatalan ke kedua wilayah dengan batas cache lima detik. Saya akan memverifikasi fiksasi, penggunaan ulang ID lama, rotasi bersamaan, CSRF, batasan batas waktu, lag regional, dan redaksi log."

Pembahasan Mendalam Langkah demi Langkah

Mulailah dengan model ancaman. Penyerang dapat menetapkan pengidentifikasi sebelum korban login, mencuri satu dari browser atau infrastruktur, melakukan replay dari perangkat lain, menjaganya tetap hidup, mengeksploitasi izin yang usang, atau memicu race condition pada rotasi. Sistem juga harus menahan permintaan pengubah status lintas situs (cross-site state-changing request) karena browser mengirimkan cookie secara otomatis.

Gunakan implementasi sesi kerangka kerja yang telah ditinjau daripada membuat generator dan parser acak sendiri. Untuk desain yang dinyatakan, buat 32 bita acak dengan generator yang aman secara kriptografis. Kirimkan nilai buram mentah hanya di dalam cookie. Turunkan lookup key dengan panjang tetap seperti HMAC-SHA-256(server_key, raw_id) sebelum melakukan kueri ke penyimpanan, sehingga cuplikan (snapshot) basis data tidak berisi nilai bearer. Rotasi kunci untuk HMAC tersebut memerlukan rencana migrasi dual-read yang eksplisit.

Contoh rekaman server adalah:

session_lookup_key
user_id, tenant_id
created_at, last_seen_at
idle_expires_at, absolute_expires_at
authentication_time, authentication_strength
session_epoch, authorization_version
revoked_at, revocation_reason

Browser menerima cookie host-only seperti:

Set-Cookie: __Host-session=<opaque>; Secure; HttpOnly; SameSite=Lax; Path=/

Prefiks __Host- mewajibkan Secure, menghilangkan Domain, dan menggunakan Path=/, mengurangi injeksi cookie subdomain. HttpOnly memblokir pembacaan JavaScript langsung tetapi tidak mencegah skrip yang disuntikkan melakukan tindakan terautentikasi. SameSite mengurangi beberapa permintaan lintas situs tetapi bersifat defense in depth; rute pengubah status tetap menggunakan token CSRF atau bukti terikat-permintaan lainnya dan memvalidasi Origin jika sesuai.

Terima sesi hanya dari cookie. Tolak pengidentifikasi yang diberikan melalui parameter URL atau header alternatif kecuali protokol klien terpisah secara eksplisit mendefinisikannya. URL bocor melalui riwayat, referrer, analitik, tangkapan layar, dan log proksi. Validasi sintaks token dan lakukan penanganan kegagalan dengan bentuk konstan (constant-shape failure handling), sambil menerapkan rate-limiting pada pengidentifikasi tidak valid yang berulang.

Pisahkan status anonim dan terautentikasi. Ketika kredensial berhasil, buat sesi terautentikasi baru dalam transaksi singkat dan batalkan pengidentifikasi pra-login. Pada peningkatan administrator atau peningkatan hak istimewa lainnya, minta bukti yang sesuai, buat pengidentifikasi baru lainnya, dan batalkan pengidentifikasi dengan tingkat kepercayaan lebih rendah. Respons menetapkan cookie baru hanya setelah status server di-commit.

Permintaan browser paralel membuat rotasi menjadi sensitif. Jika pengidentifikasi lama dihancurkan seketika, permintaan in-flight dapat menerima respons tidak terotorisasi. Serah terima berbatas (bounded handoff) dapat memetakan pengidentifikasi lama ke penerus yang sudah dibuat selama beberapa detik, tetapi tidak boleh menghasilkan banyak penerus atau mengembalikan nilai bearer baru ke replay sembarangan. Gunakan satu rekaman rotasi atomik dan buat penerus tersedia hanya melalui respons yang sah. Untuk peningkatan yang sangat sensitif, menerima percobaan ulang singkat (brief retry) lebih aman daripada jendela tenggang (grace window) yang luas.

Pada setiap permintaan terproteksi, cari sesi, tolak baris yang dicabut, tegakkan kedua jam kedaluwarsa menggunakan waktu server, dan bandingkan session_epoch dengan epoch akun saat ini. Batas waktu idle 30 menit berpindah hanya pada aktivitas yang bermakna dan dapat diperbarui dalam bucket untuk menghindari operasi penulisan pada setiap permintaan. Batas waktu absolut 12 jam tidak pernah berpindah. Hitung mundur pada klien meningkatkan kegunaan tetapi tidak menentukan validitas.

Kemudian muat keanggotaan tenant dan status otorisasi saat ini, atau bandingkan versi yang kontrak pembatalan validasinya eksplisit. Sesi yang valid tidak pernah menggantikan otorisasi tingkat objek. Perubahan alamat IP, jaringan, perangkat, dan user-agent adalah sinyal risiko yang berguna; mengikatnya secara kaku (hard-binding) menyebabkan logout palsu di balik jaringan seluler, proksi, dan perangkat bersama. Perubahan berisiko tinggi dapat memicu reautentikasi atau mencabut sesi sesuai kebijakan.

Logout perangkat saat ini secara atomik menandai sesi tersebut dicabut sebelum mengedaluwarsa cookie. Logout-semua dan perubahan kata sandi menaikkan session_epoch pengguna; setiap sesi yang lebih lama kemudian gagal bahkan jika baris individual tetap ada. Publikasikan epoch baru ke kedua wilayah dan batalkan cache positif. Batasi masa pakai cache paling lama lima detik, dan buat rute administrator atau rute berisiko tinggi lainnya membaca status otoritatif ketika cache usang. Selama terjadi partisi, rute tersebut fail closed karena ketersediaan tidak dapat mengesampingkan jaminan pencabutan yang telah dinyatakan.

Jangan menjanjikan batas lima detik tanpa mengukurnya. Catat waktu commit otoritatif dan waktu penolakan pertama yang diamati di setiap wilayah. Berikan peringatan ketika propagasi mendekati batas anggaran waktu. Audit pembuatan, rotasi, peningkatan, kedaluwarsa, dan pencabutan sesi dengan ID korelasi non-rahasia; jangan pernah mencatat cookie mentah, lookup key, atau header Cookie lengkap.

Bangun pengujian di sekitar transisi. Tetapkan cookie anonim yang dipilih penyerang, lakukan login, dan buktikan bahwa cookie tersebut tidak dapat mengakses akun. Lakukan replay pada ID pra-login, pra-peningkatan, yang sudah logout, kedaluwarsa, dan pra-perubahan kata sandi. Uji batas idle dan absolut yang tepat dengan jam server yang terkontrol. Buat kondisi race pada dua permintaan peningkatan, tunda pembatalan validasi di satu wilayah, simulasikan partisi, kirim permintaan lintas situs, dan pindai setiap log aplikasi, proksi, tracing, analitik, dan dukungan untuk mencari nilai bearer.

Contoh Jawaban Berkualitas Tinggi

"Saya akan memodelkan sesi sebagai state machine sisi server yang handle browser-nya adalah kredensial pembawa sementara. Untuk skenario ini, handle tersebut adalah 32 bita acak. Cookie bersifat host-only, secure, HTTP-only, path-wide, dan secara eksplisit SameSite=Lax; penyimpanan sesi hanya menerima lookup key turunan HMAC.

Rekaman tersebut berisi pengguna dan tenant, kekuatan autentikasi, waktu pembuatan dan aktivitas terakhir, batas idle 30 menit, batas absolut tetap 12 jam, serta snapshot dari epoch sesi akun dan versi otorisasi. Setiap permintaan memverifikasi baris sesi, kedua batas waktu, epoch saat ini, dan otorisasi saat ini. Perubahan IP dan perangkat menjadi masukan bagi keputusan risiko alih-alih bertindak sebagai bukti identitas yang rapuh.

Login dan peningkatan hak administrator masing-masing membuat sesi baru dan membatalkan pengidentifikasi berkepercayaan lebih rendah. Rotasi bersifat atomik sehingga permintaan paralel tidak dapat membuat penerus yang saling bersaing. Logout pertama-tama mencabut baris server, lalu membersihkan cookie. Logout-semua dan perubahan kata sandi menaikkan epoch akun dan memublikasikan pembatalan cache. Kedua wilayah membatasi usia cache positif hingga lima detik; rute berisiko tinggi fail closed jika tidak dapat menyegarkan status.

Terakhir, saya akan menguji fiksasi, replay setiap pengidentifikasi sebelumnya, CSRF, rotasi bersamaan, batas idle dan absolut, perubahan otorisasi, propagasi regional, perilaku partisi, dan log bebas rahasia. Bukti kuncinya adalah bahwa setiap peristiwa pengubah kepercayaan memiliki kredensial lama yang terdefinisi dan titik terukur setelahnya kredensial tersebut ditolak."

Kesalahan Umum

• Mempertahankan ID yang sama setelah login → penyerang dapat memilihnya terlebih dahulu dan menunggu autentikasi →

terbitkan sesi terautentikasi baru dan hancurkan sesi anonim.

• Hanya menghapus cookie saat logout → salinan yang dicuri tetap valid → **cabut status server sebelum

membersihkan status klien.**

• Memperlakukan HttpOnly sebagai perlindungan XSS → kode yang disuntikkan masih dapat mengirim permintaan terautentikasi →

cegah XSS dan tegakkan pertahanan otorisasi serta CSRF secara independen.

• Menggunakan SameSite sebagai satu-satunya kontrol CSRF → pengecualian yang sah dan perilaku browser melemahkan

asumsi ini → gunakan bukti CSRF terikat-permintaan untuk perubahan status.

• Menaruh ID di dalam URL → riwayat, referrer, dan log menyalin kredensial → **terima hanya melalui

mekanisme cookie yang ditujukan.**

• Hanya menyegarkan kedaluwarsa idle → pencurian aktif dapat bertahan selamanya → tegakkan batas waktu absolut yang pasti.
• Me-cache sesi valid tanpa batas waktu → logout global tidak dapat memenuhi batas waktunya → **berikan versi pada sesi dan

batasi atau lewati (bypass) cache positif.**

• Menyematkan peran selamanya di dalam sesi → izin yang dihapus tetap bertahan → **periksa otorisasi saat ini

atau versi yang sengaja dibatalkan validasinya.**

• Mengikat secara kaku (hard-binding) ke alamat IP → perubahan jaringan biasa akan mengeluarkan pengguna → **gunakan perubahan konteks sebagai sinyal

risiko.**

• Menambahkan masa tenggang rotasi yang luas → dua kredensial pembawa tetap dapat digunakan → **gunakan serah terima atomik yang berbatas sempit

atau terima percobaan ulang untuk peningkatan hak yang sensitif.**

• Mencatat header cookie untuk debugging → observabilitas berubah menjadi penyimpanan kredensial → **catat hanya

nilai korelasi non-rahasia.**

Pertanyaan Lanjutan dan Tanggapannya

Pertanyaan Lanjutan 1: Mengapa menggunakan sesi sisi server alih-alih JWT mandiri (self-contained)?

Pencabutan global yang diwajibkan sudah pasti membutuhkan status server terkini. Pengidentifikasi buram menjaga klaim tetap berada di luar browser dan membuat pencabutan satu baris menjadi mudah. JWT dapat berfungsi, tetapi logout seketika tetap memerlukan masa kedaluwarsa yang pendek, daftar pencabutan, atau pencarian versi akun; penandatanganan (signing) saja tidak menyelesaikannya.

Pertanyaan Lanjutan 2: Bagaimana cara menghindari operasi penulisan pada setiap permintaan untuk kedaluwarsa idle?

Simpan nilai aktivitas terakhir otoritatif dalam bucket kasar, misalnya hanya memperbarui ketika nilai yang disimpan sudah berumur beberapa menit. Server tetap menolak ketika batas waktu idle turunan telah terlewati. Pilih bucket sehingga perpanjangan maksimumnya termasuk dalam kebijakan keamanan, dan uji batasan tersebut secara eksplisit.

Pertanyaan Lanjutan 3: Bagaimana jika penyimpanan lintas wilayah tidak tersedia?

Pisahkan risiko rute. Rute publik dan hanya-baca (read-only) dapat menerima keputusan cache yang berbatas waktu jika kebijakan mengizinkan. Rute administrator dan rute berdampak tinggi lainnya harus memperoleh status epoch terbaru atau fail closed, karena jika tidak, janji logout global lima detik menjadi palsu. Lacak hal ini sebagai SLO ketersediaan dan keamanan.

Pertanyaan Lanjutan 4: Haruskah pembaruan ID sesi berkala selalu diaktifkan?

Tidak. Pembaruan dapat mengurangi masa pakai berguna dari satu pengidentifikasi yang dicuri, tetapi hal ini memperkenalkan race condition pada saat serah terima dan tidak menggantikan kedaluwarsa idle atau absolut. Lakukan rotasi saat login dan perubahan hak istimewa terlebih dahulu. Tambahkan pembaruan berkala hanya dengan protokol atomik yang teruji dan manfaat model ancaman yang jelas.

Pertanyaan Lanjutan 5: Bagaimana Anda menampilkan perangkat aktif kepada pengguna?

Simpan metadata non-rahasia seperti waktu pembuatan, bucket aktivitas terkini, label perkiraan perangkat, dan lokasi kasar. Biarkan pengguna mencabut satu baris atau menaikkan epoch akun untuk semua perangkat. Label hanyalah petunjuk, bukan bukti identitas perangkat, dan pengidentifikasi sesi mentah tidak pernah masuk ke antarmuka pengguna (UI) atau ekspor audit.

Pertanyaan Lanjutan 6: Pengujian tunggal mana yang paling baik dalam mengungkap fiksasi sesi?

Mulailah dengan pengidentifikasi yang dipilih sebelum autentikasi, selesaikan login, lalu kirim permintaan terproteksi menggunakan nilai lama dari klien lain. Permintaan tersebut harus gagal sementara pengidentifikasi yang baru diterbitkan berhasil. Ulangi untuk peningkatan administrator dan verifikasi bahwa penyimpanan serta log tidak mengungkapkan bearer pengganti.