Pendahuluan
Insecure Direct Object Reference (IDOR) adalah salah satu kerentanan tertua dalam daftar OWASP, tapi tetap menjadi salah satu temuan paling umum di aplikasi mobile modern. Di API mobile, IDOR sering muncul sebagai Broken Object Level Authorization (BOLA) — kerentanan yang menempati posisi pertama di OWASP API Security Top 10.
Kerentanan ini terjadi ketika aplikasi mengekspos referensi langsung ke objek internal (ID user, ID transaksi, ID dokumen) tanpa memverifikasi bahwa pengguna yang meminta benar-benar berhak mengakses objek tersebut. Di aplikasi web, IDOR sudah cukup umum. Di aplikasi mobile, masalahnya sering lebih parah karena logic otorisasi kerap ditaruh di client, sementara backend API di baliknya menerima request apa pun asal formatnya benar.
Artikel ini membahas bagaimana IDOR muncul di konteks mobile, pola kerentanan yang paling sering ditemukan dalam engagement kami, dan bagaimana seharusnya object-level authorization diimplementasikan.
Bagaimana IDOR Muncul di Aplikasi Mobile
Aplikasi mobile berkomunikasi dengan backend melalui API — REST atau GraphQL — yang biasanya sama persis dengan API yang dipakai versi web atau dipakai lintas platform (iOS, Android, web). Setiap request ke API ini membawa referensi ke objek: /api/users/1042/invoices, /api/orders/5521, /api/chat/8873/messages.
Masalah muncul saat server hanya memvalidasi bahwa token autentikasi valid, tapi tidak memvalidasi apakah user pemilik token itu benar-benar berhak mengakses objek dengan ID spesifik yang diminta. Selama token valid, server mengasumsikan request itu sah — padahal autentikasi (siapa Anda) dan otorisasi (apa yang boleh Anda akses) adalah dua hal yang berbeda.
Konteks mobile menambah dimensi tambahan: APK dan IPA bisa di-decompile, traffic API bisa diintersep lewat proxy seperti Burp Suite atau mitmproxy, dan banyak tim development berasumsi bahwa karena aplikasi "hanya" dipakai lewat app store resmi, endpoint di baliknya aman dari manipulasi. Asumsi ini keliru — siapa pun yang menginstal aplikasi bisa mengekstrak API endpoint, header, dan struktur request-nya.
Kerentanan yang Paling Sering Ditemukan
1. Sequential atau Predictable Object ID
Ini adalah bentuk IDOR paling klasik. Objek — user, order, invoice, chat, dokumen — diberi ID numerik yang bertambah secara sekuensial (1, 2, 3, ...). Attacker cukup mengganti ID di request API dan mengiterasi angka untuk mengakses objek milik user lain.
Di aplikasi mobile, pola ini sering ditemukan di endpoint profil user, riwayat transaksi, dan sistem messaging. Karena ID terlihat langsung di traffic API yang bisa diintersep, kerentanan ini termasuk yang paling cepat ditemukan dan dieksploitasi begitu attacker melakukan intersep sekali saja terhadap traffic aplikasi.
2. Broken Object Level Authorization (BOLA) pada Endpoint Non-Sequential
Menggunakan UUID atau ID acak sebagai object reference sering dianggap cukup untuk mencegah IDOR. Ini keliru. UUID hanya membuat ID sulit ditebak lewat iterasi — tapi kalau ID tersebut bocor lewat respons API lain, notifikasi push, deep link, atau shared endpoint, dan server tetap tidak memverifikasi kepemilikan objek, kerentanannya tetap ada.
Kami cukup sering menemukan kasus di mana ID acak untuk objek A (misalnya order) muncul di respons API endpoint B (misalnya daftar notifikasi), sehingga user bisa mengumpulkan ID objek milik orang lain tanpa perlu menebak sama sekali.
3. Otorisasi yang Hanya Diterapkan di Sisi Client
Pola ini spesifik untuk mobile: developer mengasumsikan bahwa karena UI aplikasi hanya menampilkan tombol atau menu tertentu untuk role tertentu, maka backend aman. Padahal client — termasuk aplikasi mobile — sepenuhnya berada di bawah kendali pengguna, termasuk attacker.
Dalam pengujian, kami rutin menemukan kasus di mana fitur admin atau fitur premium disembunyikan dari UI, tapi endpoint API di baliknya tetap bisa diakses langsung dan mengembalikan data lengkap ke siapa pun yang mengirim request dengan format yang benar, tanpa peduli role user yang login. Trust boundary yang seharusnya ada di server justru dipindahkan ke client yang tidak bisa dipercaya.
4. IDOR Ditemukan Lewat Reverse Engineering APK/IPA
Endpoint API, parameter, dan bahkan API key kadang tertanam langsung di kode aplikasi mobile. Proses decompile APK (lewat tools seperti jadx atau apktool) atau analisis IPA sering mengungkap endpoint tersembunyi yang tidak terlihat dari traffic normal — endpoint debug, endpoint internal, atau endpoint versi API lama yang belum dinonaktifkan tapi masih menerima request.
Endpoint yang "tersembunyi" ini sering kali justru yang paling minim validasi otorisasinya, karena dianggap tidak akan pernah diakses langsung oleh pengguna biasa.
5. IDOR pada Endpoint Media dan File
Endpoint yang menyajikan file — foto profil, dokumen KTP untuk verifikasi, invoice PDF, hasil scan — sering luput dari review otorisasi yang sama ketatnya dengan endpoint data terstruktur. Padahal kalau URL file bisa ditebak atau dikonstruksi (/files/user_1042_ktp.jpg) dan server tidak memverifikasi kepemilikan sebelum menyajikan file, ini adalah IDOR dengan dampak yang bisa jauh lebih sensitif — kebocoran dokumen identitas atau data finansial pribadi.
Dari kelima pola di atas, broken object level authorization pada endpoint dengan ID acak (poin 2) adalah yang paling sering ditemukan penulis dalam engagement mobile, lebih sering dibanding sequential ID murni. Ini karena banyak tim sudah cukup sadar untuk tidak pakai ID sekuensial, tapi kesadaran itu berhenti di situ — mereka menganggap ID acak sama dengan otorisasi yang benar, padahal itu dua hal yang berbeda.
Implementasi yang Benar
Object-Level Authorization di Setiap Request
Setiap endpoint yang menerima object reference harus memverifikasi kepemilikan atau hak akses terhadap objek tersebut di sisi server, terlepas dari apakah ID-nya sekuensial atau acak. Pengecekan ini idealnya dilakukan lewat satu layer otorisasi yang konsisten (middleware atau policy layer), bukan diulang manual di tiap endpoint — supaya tidak ada endpoint yang lupa memasang pengecekan.
Jangan Andalkan Obscurity ID sebagai Kontrol Keamanan
UUID atau ID acak boleh dipakai, tapi statusnya hanya sebagai pengurang permukaan serangan lewat enumerasi — bukan pengganti otorisasi. Setiap tempat objek atau ID-nya bisa terekspos (respons API lain, log, notifikasi, deep link, screenshot) perlu diasumsikan sebagai kebocoran potensial, dan otorisasi tetap harus diverifikasi di server saat objek diakses.
Prinsip Least Privilege pada Level Data
Query database untuk mengambil objek sebaiknya langsung menyertakan filter kepemilikan (WHERE user_id = current_user AND id = requested_id), bukan mengambil objek dulu berdasarkan ID lalu memeriksa kepemilikannya belakangan di application layer. Pendekatan pertama membuat kebocoran data nyaris tidak mungkin terjadi meski ada bug logic di layer lain.
Rate Limiting dan Deteksi Enumerasi
Karena eksploitasi IDOR sering berbentuk iterasi ID dalam jumlah besar, rate limiting per user/per endpoint dan monitoring pola akses yang tidak wajar (satu akun mengakses ratusan ID objek berbeda dalam waktu singkat) bisa menjadi lapisan deteksi tambahan, meski bukan pengganti perbaikan otorisasi itu sendiri.
Metodologi Pengujian IDOR di Aplikasi Mobile
Pengujian IDOR di mobile app tidak bisa hanya mengandalkan black-box testing dari UI aplikasi, karena UI hanya menampilkan sebagian kecil dari permukaan API yang sebenarnya ada. Metodologi yang kami pakai mencakup: intersep seluruh traffic API lewat proxy untuk memetakan endpoint yang benar-benar dipanggil aplikasi, decompile APK/IPA untuk menemukan endpoint atau parameter yang tidak muncul di traffic normal, lalu menguji setiap endpoint dengan dua akun berbeda — mencoba mengakses objek milik akun B menggunakan token akun A.
Pengujian ini perlu dilakukan sistematis di seluruh endpoint yang menerima object reference, bukan sampling sebagian saja, karena IDOR biasanya bersifat spesifik per endpoint — satu endpoint bisa aman sementara endpoint lain dengan pola serupa ternyata rentan.
Kesimpulan
IDOR di aplikasi mobile bukan kerentanan yang butuh teknik canggih untuk ditemukan atau dieksploitasi — justru itu yang membuatnya berbahaya. Begitu attacker punya dua akun dan bisa mengintersep traffic, pengujian sudah bisa dimulai. Yang sering kurang bukan pengetahuan teknis tim development, tapi asumsi keliru bahwa API di balik aplikasi mobile terlindungi hanya karena UI membatasi apa yang terlihat.
Object-level authorization yang konsisten di setiap endpoint, diverifikasi lewat pengujian sistematis, tetap jadi satu-satunya cara efektif untuk menutup kerentanan ini.
Jika Anda ingin memastikan API di balik aplikasi mobile Anda sudah teruji dari celah IDOR dan BOLA, tim Security Squad LOGIQUE siap membantu.
