Insecure Direct Object Reference (IDOR) adalah kerentanan keamanan web di mana aplikasi mengekspos referensi ke objek internal—seperti database key, nama file, atau nomor akun—tanpa pemeriksaan otorisasi yang memadai. Akibat kelemahan ini, penyerang dapat memanipulasi parameter input untuk mengakses data atau fungsi milik pengguna lain secara langsung.
IDOR termasuk dalam kelompok risiko keamanan aplikasi web yang sangat umum dan berbahaya. Jika gagal divalidasi, penyerang hanya perlu mengganti parameter numerik atau string pada URL atau payload permintaan HTTP (seperti mengubah user_id=1001 menjadi user_id=1002) untuk membobol sistem dan mengambil data privat pihak lain.
Bagaimana Cara Kerja IDOR?
Kerentanan ini terjadi karena asumsi keliru pengembang bahwa pengguna tidak akan menebak atau mengubah nilai parameter yang dikirim melalui antarmuka pengguna. Secara teknis, alur eksploitasi IDOR melibatkan manipulasi objek referensi langsung pada HTTP request.
Berikut adalah tabel matriks yang mengilustrasikan perbedaan antara permintaan normal dan permintaan yang dieksploitasi menggunakan celah IDOR:
| Jenis Permintaan | URL / Parameter HTTP | Respons Sistem | Status Keamanan |
|---|---|---|---|
| Akses Normal | https://api.domain.com/v1/invoice?id=5001 | Menampilkan data tagihan milik pengguna yang sedang login (ID 5001). | Aman jika ada validasi sesi. |
| Eksploitasi IDOR | https://api.domain.com/v1/invoice?id=5002 | Menampilkan data tagihan milik pengguna lain (ID 5002) tanpa verifikasi kepemilikan. | Berbahaya / Rentan. |
Contoh Nyata Kasus IDOR
Celah IDOR dapat ditemukan pada berbagai fitur aplikasi web, mulai dari sistem e-commerce, perbankan digital, hingga aplikasi pesan-antar makanan. Berikut adalah beberapa skenario umum di lapangan:
- Sistem File Download: URL unduhan faktur berbentuk
/download?file=invoice_1029.pdf. Penyerang mengganti angka tersebut menjadiinvoice_1028.pdfuntuk mengunduh dokumen rahasia milik kompetitor atau pelanggan lain. - Pengubahan Profil Pengguna: Endpoint API seperti
POST /api/user/updatemenerima parameterid: 45. Penyerang mengubah nilai ID menjadi 44 dan menyisipkan data email baru, sehingga akun pengguna lain berhasil diambil alih. - Nomor Pesanan (Order ID): Pelanggan dapat melihat detail pengiriman melalui parameter urutan angka yang prediktif, memungkinkan enumerasi massal menggunakan skrip otomatis.
Dampak Kerentanan IDOR
Dampak eksploitasi IDOR bergantung pada hak istimewa objek yang direferensikan. Jika objek tersebut melibatkan data sensitif, kerugian yang ditimbulkan mencakup:
- Pencurian Data (Data Breach): Akses ilegal terhadap informasi pribadi (PII), catatan medis, laporan keuangan, atau riwayat transaksi.
- Manipulasi Data: Penyerang dapat mengubah, menghapus, atau merusak data pengguna lain karena tidak ada validasi hak akses tulis (write authorization).
- Pengambilalihan Akun (Account Takeover): Mengubah kredensial atau token keamanan pengguna lain melalui endpoint yang tidak terlindungi.
Cara Mencegah dan Menambal Celah IDOR
Pencegahan IDOR berpusat pada penerapan kontrol akses yang ketat di sisi server (server-side authorization checks). Pengembang tidak boleh hanya mengandalkan penyembunyian parameter di antarmuka frontend.
- Gunakan Direct Reference yang Tidak Dapat Ditebak: Terapkan pengenal unik global (UUID v4) alih-alih menggunakan integer berurutan (1, 2, 3, dst) untuk objek sensitif.
- Validasi Kontrol Akses Berbasis Sesi: Setiap kali ada permintaan data objek, server wajib memvalidasi apakah pengguna yang sedang aktif memiliki hak akses sah terhadap objek tersebut.
- Gunakan Indirect Reference Map: Petakan referensi objek ke nilai acak yang hanya valid untuk sesi pengguna tertentu.
- Implementasikan Pengujian Keamanan Berkala: Lakukan penetration testing dan pemindaian kode otomatis (SAST/DAST) secara rutin untuk mendeteksi potensi endpoint yang tidak aman.