Bayangkan seorang pengguna biasa masuk ke aplikasi e-commerce, lalu mengganti angka di URL dari order_id=10234 menjadi order_id=10235. Tanpa verifikasi tambahan, layar tersebut malah menampilkan faktur milik orang lain lengkap dengan alamat, nomor telepon, dan detail pembayaran. Kejadian semacam ini bukan fiksi. Kerentanan yang memungkinkannya dinamakan Insecure Direct Object Reference, atau disingkat IDOR.
Menurut OWASP Top 10:2025, Broken Access Control menempati posisi pertama sebagai risiko aplikasi web paling kritis. Dalam data yang dikumpulkan OWASP, 100% aplikasi yang diuji memiliki setidaknya satu bentuk kelemahan akses kontrol. Salah satu varian paling umum dan berbahaya dari kategori ini adalah IDOR. Artikel ini menjelaskan cara kerja IDOR, dampaknya, serta langkah konkret yang bisa developer terapkan untuk mencegah kebocoran data akibat referensi objek yang tidak diamankan.
Apa Itu IDOR dan Bagaimana Cara Kerjanya?
IDOR adalah kelemahan akses kontrol yang muncul ketika aplikasi menggunakan identifier objek, seperti ID database atau nama file, yang langsung dikendalikan pengguna. Aplikasi tidak memeriksa apakah pengguna yang meminta benar-benar berhak mengakses objek tersebut. Akibatnya, penyerang bisa memanipulasi nilai identifier untuk membaca, mengubah, atau menghapus data milik pengguna lain.
Konsepnya sederhana. Aplikasi menyimpan data pengguna dalam tabel dengan kolom ID unik. Saat pengguna membuka halaman profil, URL yang muncul adalah /profile?id=42. Jika server hanya mengambil data berdasarkan ID tanpa memverifikasi kepemilikan, maka ID 43, 44, atau nomor lain bisa diakses dengan mudah. Kerentanan ini tidak terbatas pada parameter URL. ID dapat berupa cookie, header, body JSON, atau nama file.
OWASP menjelaskan bahwa IDOR termasuk dalam CWE-639: Authorization Bypass Through User-Controlled Key. Artinya, kunci yang digunakan untuk mengakses objek boleh diubah oleh pengguna, tetapi proses otorisasi untuk memastikan keabsahan akses ditinggalkan. Kelemahan ini bisa terjadi pada API, aplikasi monolitik, maupun layanan mikro yang saling bertukar data.
Baca juga: Pengantar OWASP Top 10 – 10 Ancaman Web Paling Berbahaya yang Wajib Kamu Ketahui untuk memahami kerangka risiko aplikasi web secara menyeluruh.
Apa Saja Jenis IDOR yang Sering Ditemukan?
IDOR tidak selalu berbentuk angka ID yang bisa diganti secara berurutan. Bentuknya beragam tergantung pada desain aplikasi. Berikut adalah beberapa varian yang paling sering muncul dalam audit keamanan dan program bug bounty.
IDOR pada Referensi Database
Jenis ini paling klasis. Aplikasi mengekspos ID numerik atau UUID yang mengarah ke record database. Tanpa pengecekan hak akses, penyerang dapat melihat data pribadi, riwayat transaksi, atau dokumen rahasia dengan mengganti angka ID.
IDOR pada Berkas Statis
Aplikasi kadang menyimpan dokumen sensitif di server dengan nama file yang mudah ditebak, seperti invoice_1234.pdf. Penyerang bisa mencoba angka lain untuk mengunduh faktur milik pengguna lain. Teknik ini sering disebut sebagai forced browsing.
IDOR pada API dan Fungsi Aksi
Beberapa endpoint API tidak hanya membaca data, tetapi juga mengubah atau menghapus objek. Endpoint DELETE /api/address/42 yang tidak diverifikasi bisa disalahgunakan untuk menghapus alamat milik pengguna lain. Bentuk ini lebih berbahaya karena berdampak pada integritas data.
IDOR pada Fungsi Reset Password atau Undangan
Token reset password atau link undangan kadang berisi identifier yang bisa diprediksi. Jika token tidak dihubungkan dengan identitas pengguna yang sah, penyerang dapat menggunakan token milik orang lain untuk mengambil alih akun.
Mengapa IDOR Bisa Sangat Berbahaya?
Dampak IDOR bisa beragam, mulai dari kebocoran informasi pribadi hingga pengambilalihan akun. Risiko meningkat ketika aplikasi menyimpan data sensitif seperti rekam medis, dokumen keuangan, atau identitas resmi pengguna.
Beberapa insiden dunia nyata menunjukkan skala kerugian yang bisa terjadi. Pada tahun 2019, perusahaan First American Financial Corporation mengalami kebocoran lebih dari 800 juta gambar dokumen berisi nomor Social Security dan rekening bank. Penyebabnya adalah URL parameter yang memungkinkan siapa saja mengakses dokumen milik nasabah lain. Kasus ini bahkan disebutkan dalam advisory bersama CISA, NSA, dan ACSC tentang IDOR.
Di Australia, Optus mengalami pelanggaran data besar pada tahun 2022 akibat kelemahan akses kontrol pada domain publik yang terlupakan. Penyerang berhasil mengakses data pelanggan melalui proses trial and error yang relatif sederhana. Otoritas komunikasi Australia menyebut serangan tersebut tidak memerlukan teknik tingkat tinggi. Insiden itu menjadi salah satu kebocoran data terbesar dalam sejarah Australia.
Baca juga: Cara Mengamankan REST API: Panduan Lengkap Berdasarkan OWASP API Security Top 10 untuk mempelajari pilar keamanan API yang berhubungan erat dengan IDOR.
Bagaimana Cara Menemukan IDOR dalam Aplikasi?
Proses identifikasi IDOR membutuhkan pemahaman tentang alur data dan endpoint yang menerima input dari pengguna. Berikut adalah langkah praktis yang biasa dilakukan security tester dan bug bounty hunter.
Pantau Parameter yang Berisi Identifier
Setiap parameter yang berbentuk angka, UUID, atau nama file perlu diperiksa. Coba buat dua akun pengguna dengan hak yang berbeda, lalu tukar nilai identifier dari satu akun ke akun lain. Perhatikan apakah aplikasi menolak akses atau malah menampilkan data.
Uji Setiap Metode HTTP
Jangan hanya menguji metode GET. Cobalah POST, PUT, DELETE, dan PATCH pada endpoint yang sama. Terkadang pengecekan akses hanya diterapkan pada satu metode, sedangkan metode lainnya tidak dilindungi.
Manfaatkan Dua Akun Berbeda
Buat akun A dan akun B. Catat semua identifier yang muncul di akun A. Login sebagai akun B, lalu coba akses identifier milik akun A. Jika data berhasil ditampilkan, maka IDOR tersebut valid.
Perhatikan Respons API yang Terlalu Rinci
API yang mengembalikan banyak field data dalam respons bisa menjadi petunjuk. Jika server mengirimkan informasi sensitif tanpa filtering, maka IDOR dapat dieksploitasi untuk mengumpulkan data dalam jumlah besar.
Apa Saja Praktik Terbaik untuk Mencegah IDOR?
Pencegahan IDOR tidak harus kompleks, tetapi membutuhkan konsistensi di setiap endpoint. Berikut adalah praktik yang direkomendasikan OWASP dan komunitas keamanan aplikasi.
Terapkan Otorisasi di Sisi Server
Setiap kali aplikasi menerima permintaan untuk mengakses objek, server harus memeriksa apakah pengguna yang sedang login memiliki hak terhadap objek tersebut. Logika otorisasi ini harus berada di sisi server, bukan hanya disembunyikan di antarmuka klien.
Gunakan Referensi Tidak Langsung
Gantilah ID numerik yang mudah ditebak dengan indirect reference map. Aplikasi bisa memetakan ID internal ke token acak yang hanya berlaku untuk sesi pengguna tertentu. Dengan cara ini, pengguna tidak pernah melihat ID asli dari database.
Batasi Data yang Dikembalikan API
Server sebaiknya tidak mengembalikan seluruh kolom database ke klien. Gunakan data transfer object yang hanya berisi field yang memang perlu ditampilkan. Pendekatan ini mengurangi dampak jika ada endpoint yang luput dari pengecekan.
Uji Hak Akses pada Setiap Endpoint
Bangun unit test dan integration test yang secara spesifik memverifikasi akses kontrol. Uji skenario di mana pengguna mencoba mengakses objek milik pengguna lain, termasuk objek yang tidak ada. Pastikan aplikasi memberikan respons yang konsisten, seperti kode status 404 atau 403.
Enkripsi atau Tandatangani Token Akses Objek
Jika aplikasi memang harus mengekspos identifier, pertimbangkan untuk mengenkripsi atau menandatangani token tersebut. Verifikasi tanda tangan di server sebelum objek diakses. Langkah ini mempersulit penyerang memalsukan referensi.
Apa Perbedaan IDOR dengan Broken Access Control Lainnya?
IDOR sering disamakan dengan kelemahan akses kontrol lain seperti path traversal atau privilege escalation. Meskipun berkaitan, ada perbedaan penting yang perlu dipahami. IDOR berfokus pada akses langsung ke objek melalui identifier yang dikendalikan pengguna. Path traversal lebih menekankan pada akses file atau direktori di luar izin. Privilege escalation menyangkut peningkatan hak akses pengguna dari peran biasa menjadi administrator.
OWASP menempatkan IDOR di bawah kategori Broken Access Control karena akar masalahnya sama, yaitu kegagalan aplikasi dalam menegakkan kebijakan akses. Perbedaan teknis ini membantu developer dan tester memilih teknik mitigasi yang tepat. Mitigasi IDOR menekankan validasi kepemilikan objek, sementara mitigasi privilege escalation lebih fokus pada pengecekan peran dan izin fungsional.
Bagaimana IDOR Dilihat dari Sudut Pandang Compliance?
Di Indonesia, kebocoran data pribadi akibat IDOR bisa memicu kewajiban pelaporan sesuai UU Perlindungan Data Pribadi. Organisasi yang tidak melindungi data pribadi dengan baik dapat dikenai sanksi administratif dan reputasi bisnis yang merosot. Regulasi ini mendorong perusahaan teknologi untuk meninjau kembali setiap endpoint yang menangani data pengguna.
Standar internasional seperti ISO/IEC 27001 dan NIST Cybersecurity Framework juga menyoroti pentingnya akses kontrol. Kontrol akses yang kuat menjadi bagian dari praktik keamanan informasi yang harus diaudit secara berkala. Kegagalan dalam mengatasi IDOR bisa berarti kegagalan dalam memenuhi persyaratan audit tersebut.
FAQ: Pertanyaan Umum tentang IDOR
Apakah IDOR sama dengan BOLA?
IDOR dan BOLA, atau Broken Object Level Authorization, mengacu pada konsep yang serupa. IDOR lebih umum digunakan untuk aplikasi web tradisional, sementara BOLA sering dipakai dalam konteks API modern. OWASP API Security Top 10 menempatkan BOLA sebagai risiko API nomor satu.
Mengapa UUID tidak selalu aman dari IDOR?
UUID memang sulit ditebak secara acak, tetapi jika aplikasi tidak memeriksa kepemilikan, pengguna yang mengetahui UUID orang lain tetap bisa mengakses objek tersebut. UUID hanya menambah ketidakpastian, bukan menggantikan otorisasi.
Apakah IDOR bisa dieksploitasi tanpa login?
Bisa, jika endpoint bersifat publik atau tidak memerlukan autentikasi. Namun, IDOR paling sering muncul pada endpoint yang memerlukan login tetapi tidak memeriksa hak akses antarpengguna.
Tools apa yang cocok untuk menguji IDOR?
Tester bisa memanfaatkan Burp Suite, OWASP ZAP, atau skrip Python untuk otomatisasi pengujian parameter. Yang paling penting adalah memahami logika bisnis aplikasi, bukan sekadar mengandalkan alat.
Apakah IDOR termasuk kerentanan yang populer di bug bounty?
Ya, IDOR termasuk salah satu kelas kerentanan yang paling sering dilaporkan di platform bug bounty. Kasus First American dan Optus menunjukkan bahwa dampaknya bisa sangat besar, sehingga banyak perusahaan memberikan imbalan tinggi untuk temuan IDOR yang valid.
Kesimpulan: Jangan Biarkan Identifier Terbuka Tanpa Pengawasan
IDOR adalah contoh klasik dari kerentanan yang terlihat sederhana tetapi berdampak luar biasa. Kegagalan dalam memvalidasi kepemilikan objek bisa membuka jalan bagi kebocoran data skala besar. Seperti yang ditunjukkan oleh OWASP, Broken Access Control tetap menjadi ancaman nomor satu karena muncul hampir di setiap aplikasi yang diuji.
Developer dapat mengurangi risiko IDOR dengan menerapkan otorisasi di sisi server, menggunakan referensi tidak langsung, membatasi data yang dikembalikan, serta menguji setiap endpoint secara konsisten. Pendekatan ini tidak hanya melindungi pengguna, tetapi juga membantu organisasi memenuhi kewajiban regulasi dan menjaga kepercayaan publik.
Bagi yang ingin mendalami dunia akses kontrol, memahami IDOR adalah langkah penting. Mulai dari mempelajari OWASP Testing Guide hingga berlatih di lingkungan uji yang aman. Semakin cepat kelemahan ini diidentifikasi, semakin kecil kemungkinan data pengguna bocor ke tangan yang salah.