IDOR, Celah Akses Data Orang Lain Hanya dengan Ganti Angka

Seorang pelanggan login ke portal toko online untuk mengunduh fakturnya. Alamat di browser terlihat seperti /faktur?id=1052. Iseng, ia mengganti angkanya menjadi 1051, dan yang muncul adalah faktur milik pelanggan lain lengkap dengan nama, alamat, dan nomor telepon. Tidak ada peretasan canggih, tidak ada alat khusus. Hanya ganti angka.

Itulah IDOR (Insecure Direct Object Reference). Aplikasi mengambil data berdasarkan ID yang dikirim pengguna, tapi lupa memeriksa satu hal paling dasar: apakah data dengan ID itu memang boleh dilihat oleh orang yang sedang meminta.

Kenapa celah sesederhana ini masih sering muncul

IDOR lahir dari asumsi yang keliru. Pengembang mengira pengguna hanya akan mengklik tombol yang disediakan, jadi ID yang dikirim pasti miliknya sendiri. Padahal setiap parameter yang datang dari browser atau aplikasi mobile bisa diubah sesuka hati, entah lewat bilah alamat, alat pengembang di browser, atau proxy penyadap seperti yang dipakai penguji keamanan.

Celah ini juga sulit tertangkap pemindai otomatis. Pemindai tidak tahu bahwa faktur 1051 seharusnya bukan milik akun yang sedang login, karena dari sisi teknis responsnya terlihat normal: kode 200, halaman tampil rapi. Yang salah adalah logika bisnisnya, dan logika bisnis hanya dipahami oleh orang yang tahu aturan aplikasinya.

OWASP menempatkan masalah ini di kategori teratas. Pada OWASP Top 10 2025, kategori A01 Broken Access Control secara eksplisit menyebut contoh "melihat atau mengubah akun orang lain dengan memberikan pengenal uniknya (insecure direct object references)". Untuk API, OWASP API Security Top 10 2023 menaruh hal serupa di urutan pertama dengan nama Broken Object Level Authorization (BOLA).

Bentuk IDOR yang sering ditemui

IDOR tidak selalu berupa angka di URL. Polanya bisa muncul di banyak tempat, dan tabel berikut merangkum yang paling umum.

Dua baris terakhir menunjukkan bahwa IDOR bukan cuma soal membaca. Mengubah dan menghapus data orang lain sering kali lebih merusak, karena korban kehilangan data atau akunnya diambil alih.

Aplikasi mobile termasuk yang paling rawan. Banyak tim menganggap API di belakang aplikasi Android atau iPhone "tidak terlihat", sehingga pemeriksaan akses dilonggarkan. Kenyataannya, lalu lintas aplikasi mobile bisa disadap dan diulang dengan alat yang sama seperti untuk website. Setiap endpoint API harus diperlakukan seolah-olah dipanggil langsung oleh orang yang tidak bisa dipercaya.

Dampaknya juga tidak berhenti di urusan teknis. Data yang bocor lewat IDOR biasanya berupa data pribadi pelanggan: nama, alamat, nomor telepon, dokumen identitas, atau riwayat transaksi. Kebocoran semacam ini menyangkut kepercayaan pelanggan dan kewajiban pengendali data untuk melindungi data pribadi yang dikelolanya.

Menyembunyikan ID bukan perbaikan

Reaksi pertama banyak tim adalah mengganti ID berurutan dengan UUID panjang atau mengenkripsinya. Langkah ini memang membuat tebakan lebih sulit, tapi tidak menutup celahnya. ID bisa bocor lewat banyak jalan: tautan yang dibagikan, email notifikasi, respons API lain yang menampilkan ID pengguna, atau log.

Begitu penyerang mendapatkan satu ID yang sah milik orang lain, aplikasi yang tidak memeriksa kepemilikan akan tetap memberikan datanya. ID acak berguna sebagai lapisan tambahan, sedangkan perbaikan sebenarnya ada di pemeriksaan otorisasi.

Cara memperbaikinya di kode

Prinsipnya satu kalimat: setiap kali server mengambil, mengubah, atau menghapus objek, server harus memastikan pengguna yang sedang login berhak atas objek itu. Dalam praktik, ini berarti beberapa kebiasaan.

Pertama, ambil data dengan menyertakan pemiliknya di kueri. Alih-alih SELECT * FROM faktur WHERE id = ?, tulis SELECT * FROM faktur WHERE id = ? AND pelanggan_id = ? dengan pelanggan_id diambil dari sesi login, bukan dari parameter yang dikirim pengguna. Bila hasilnya kosong, kembalikan "tidak ditemukan".

Kedua, jangan percaya ID pengguna dari body permintaan untuk menentukan siapa yang sedang bertindak. Identitas selalu berasal dari sesi atau token yang sudah diverifikasi server.

Ketiga, pusatkan aturan akses. Framework populer menyediakan mekanisme kebijakan atau middleware otorisasi. Memakai satu tempat untuk aturan akses lebih aman daripada menulis pengecekan manual di setiap fungsi, karena satu fungsi yang terlupa sudah cukup untuk membuka celah.

Keempat, uji dengan dua akun. Cara paling efektif menemukan IDOR adalah login sebagai pengguna A, catat semua permintaan yang membawa ID, lalu ulangi permintaan itu dengan sesi pengguna B. Bila B bisa melihat atau mengubah data A, celahnya ada. Pengujian ini bisa dijadikan bagian tetap dari pengujian sebelum rilis.

Kelima, catat percobaan akses yang ditolak. Pengguna yang berkali-kali meminta objek milik orang lain dengan ID berurutan adalah tanda pemindaian IDOR. Log seperti ini membantu tim mendeteksi percobaan serangan lebih awal.

Apa yang harus dilakukan pemilik usaha?

Pemilik bisnis tidak perlu bisa membaca kode untuk mengurangi risiko IDOR. Tanyakan kepada tim atau vendor pembuat aplikasi apakah setiap endpoint sudah memeriksa kepemilikan data, dan bagaimana hal itu diuji. Untuk aplikasi yang menyimpan data pribadi pelanggan, uji penetrasi berkala oleh pihak yang paham logika bisnis jauh lebih berguna daripada pemindaian otomatis saja.

Alat seperti OWASP ZAP tetap bermanfaat untuk menemukan masalah umum, dan bisa membantu penguji manual merekam lalu mengulang permintaan dengan sesi berbeda. Untuk gambaran celah lain yang satu kategori dengan IDOR, baca juga penjelasan SSRF dan OWASP Top 10 untuk pemilik website.

Ringkasnya

IDOR terjadi karena aplikasi percaya pada ID yang dikirim pengguna tanpa memeriksa kepemilikan. Mengacak ID hanya mempersulit tebakan, sedangkan perbaikan sejati adalah pemeriksaan otorisasi di server untuk setiap objek dan setiap aksi. Uji dengan dua akun berbeda sebelum rilis, dan celah yang tampak sepele ini bisa tertutup sebelum ada data pelanggan yang bocor.