1. Pertanyaan dan Konteks
Suatu produk perlu membagikan faktur, file, atau tindakan sekali pakai. Tautan itu sendiri membawa kemampuan akses (capability), sehingga server tidak perlu mengidentifikasi akun yang masuk terlebih dahulu. Fokus wawancara ini adalah kapan model ini masuk akal dan bagaimana menangani tautan yang disalin, dicatat dalam log, atau diteruskan.
2. Apa yang Dievaluasi oleh Pewawancara
- Apakah Anda membedakan antara capability URL, sesi login, dan model kepercayaan bearer-token OAuth.
- Apakah model ancaman Anda mencakup kebocoran URL melalui log, riwayat penelusuran, analitik, perujuk (referrer), dan tangkapan layar.
- Apakah Anda merancang masa kedaluwarsa yang singkat, hak istimewa paling rendah, penggunaan tunggal, atau pengikatan audiens (audience binding).
- Apakah Anda mendukung pencabutan per tautan, pencabutan massal, dan kemampuan audit alih-alih hanya merotasi kunci global.
Panduan capability-URL W3C menyatakan bahwa akses yang diberikan harus dapat dicabut jika capability URL bocor. OWASP secara eksplisit menyarankan agar tidak menaruh kata sandi, kunci API, atau token keamanan di dalam URL, sehingga capability URL memerlukan batas risiko yang jelas dan kontrol kompensasi.
3. Pertanyaan Klarifikasi Sebelum Anda Menjawab
- Apakah sumber daya tersebut bersifat publik, bersensitivitas rendah, atau bersifat pribadi, finansial, atau terikat regulasi?
- Apakah pengunjung harus masuk (sign in), dan apakah tautan tersebut akan melintasi batas organisasi?
- Apakah akses tersebut berupa unduhan sekali pakai, rentang waktu singkat, atau kolaborasi jangka panjang?
- Setelah terjadi kebocoran, apakah Anda harus mencabut satu tautan, satu pengguna, atau seluruh sumber daya?
4. Kerangka Jawaban 30 Detik
Gunakan kesesuaian, token, kebocoran, pencabutan, dan alternatif.
Saya akan menggunakan capability URL hanya untuk akses frekuensi rendah yang dapat diaudit di mana kepemilikan tautan dapat diterima, serta membatasinya pada satu sumber daya dan rentang waktu singkat. Token harus memiliki entropi tinggi dan tidak dapat ditebak; server hanya menyimpan hash dan mencatat pembuatan, penggunaan, serta pencabutan. Saya akan menetapkan Referrer-Policy: no-referrer dan menjauhkannya dari log dan analitik pihak ketiga. Sumber daya sensitif harus menggunakan otorisasi terautentikasi, dengan capability URL yang dibatasi untuk undangan sekali pakai atau kredensial unduhan.
5. Pembahasan Mendalam Langkah demi Langkah
Langkah 1: Pilih Model Kepercayaan yang Tepat
Capability URL berarti kepemilikan memberikan wewenang; ini tidak membuktikan identitas akun. Ini cocok untuk berbagi dengan sensitivitas rendah, unduhan sekali pakai, atau undangan tanpa registrasi. Ini tidak cocok untuk keanggotaan berbutir halus (fine-grained), persyaratan audit jangka panjang, atau jaminan identitas yang kuat. Untuk bearer token OAuth, prioritaskan header Authorization; RFC 6750 mencantumkan parameter kueri URI sebagai metode transportasi yang memungkinkan namun berisiko lebih tinggi.
Langkah 2: Minimalkan Kapabilitas
Ikatkan token ke sumber daya, tindakan, dan audiens. Tambahkan kedaluwarsa singkat, penanda sekali pakai, dan batas laju (rate limit); untuk alur kerja yang dapat diteruskan, minta konfirmasi penerima atau login sebelum penukaran (redemption). Hasilkan token dengan sumber acak yang aman secara kriptografis dan simpan hanya hash-nya sehingga kebocoran basis data tidak langsung menjadi kredensial yang dapat digunakan.
Langkah 3: Kendalikan Kebocoran URL
OWASP mencatat bahwa URL masuk ke dalam log server, riwayat browser, dan catatan proksi. Setelah menerima token, landing page harus menukarnya dengan sesi berumur pendek melalui permintaan yang aman dan menghapusnya dari bilah alamat. Gunakan kebijakan perujuk (referrer policy) yang ketat dan hindari sumber daya pihak ketiga yang menerima token tersebut. Email, tangkapan layar, dan aplikasi pesan masih dapat mengekspos tautan, jadi jangan menaruh akses berhak istimewa tinggi yang berumur panjang di dalamnya.
Langkah 4: Terapkan Pencabutan dan Audit yang Presisi
Catat pembuat, sumber daya, tindakan, masa kedaluwarsa, penggunaan terakhir, dan waktu pencabutan untuk setiap token. Periksa pencabutan sebelum setiap penukaran atau pengunduhan; pencabutan per tautan tidak boleh bergantung pada rotasi kunci global. Audit penggunaan yang berhasil, gagal, berulang, dan dicabut beserta alasannya sehingga kebocoran dan penyalahgunaan dapat diselidiki.
6. Contoh Jawaban Berkualitas Tinggi
Pertama-tama saya akan mengklasifikasikan sensitivitas dan masa pakainya. Buku panduan publik tidak memerlukan capability URL. Faktur bersensitivitas rendah untuk tinjauan eksternal dapat menggunakannya, sedangkan laporan keuangan sensitif harus memerlukan login dan izin organisasi.
>
Untuk kasus yang dapat diterima, saya menghasilkan setidaknya 128 bit keacakan dan mengikat token ke satu sumber daya, satu tindakan, dan rentang waktu 24 jam. Basis data hanya menyimpan hash token, status, dan bidang audit. Penukaran yang berhasil langsung ditandai sebagai telah digunakan, dan endpoint unduhan memeriksa kedaluwarsa serta pencabutan setiap saat. Respons menetapkan Referrer-Policy: no-referrer; setelah penukaran, token dihapus dari bilah alamat dan halaman menghindari sumber daya pihak ketiga yang dapat menerima referrer.
>
Pengguna dapat mencabut satu tautan dan administrator dapat mencabut tautan berdasarkan sumber daya; pencabutan dan penggunaan berulang diaudit. Jika nantinya produk memerlukan kolaborasi, saya akan bermigrasi ke otorisasi terautentikasi dan izin keanggotaan alih-alih memperluas capability URL menjadi bearer token permanen. Hal ini menjaga kenyamanan berbagi sekaligus membatasi kebocoran pada satu sumber daya dan waktu yang terikat.
7. Pola Kegagalan Umum
- Menganggap tautan panjang sebagai keamanan sembari mengabaikan log, riwayat, dan penerusan.
- Menggunakan ID sumber daya yang dapat ditebak atau token yang bertambah secara otomatis (auto-incrementing).
- Menempatkan bearer token berumur panjang dan berhak istimewa tinggi di dalam parameter kueri.
- Hanya mendukung rotasi kunci global dan tidak ada pencabutan per tautan.
- Membiarkan token tetap berada di bilah alamat setelah penukaran saat memuat gambar atau analitik pihak ketiga.
8. Pertanyaan Lanjutan dan Tanggapan
Lanjutan 1: Mengapa hanya menyimpan hash token?
Token adalah kredensial pemegangnya. Jika akses baca basis data bocor, token teks biasa dapat langsung digunakan. Melakukan hashing memungkinkan server membandingkan nilai yang dikirimkan tanpa mengubah penyimpanan statis menjadi kebocoran kredensial (credential dump).
Lanjutan 2: Apakah penggunaan tunggal membuat penyegaran (refresh) gagal?
Gunakan token sekali pakai untuk ditukar dengan sesi berumur pendek; penyegaran menggunakan sesi tersebut daripada menukarkan kembali tautan asli. Jika penukaran berhasil tetapi respons hilang, berikan hasil penukaran idempoten yang dibatasi tanpa membuka kembali wewenang berumur panjang.
Lanjutan 3: Kapan Anda harus meninggalkan capability URL sepenuhnya?
Gunakan otorisasi terautentikasi dan izin sisi server ketika sumber daya sangat sensitif, keanggotaan harus dikelola terus-menerus, identitas pemanggil harus dibuktikan, atau organisasi memerlukan pencabutan dan audit terpusat.