Definisi dan Hubungan Hierarkis
Secara teknis, tidak ada perbedaan yang mempertentangkan antara IDOR (Insecure Direct Object Reference) dan BOLA (Broken Object Level Authorization). Faktanya, IDOR adalah bentuk spesifik dari BOLA. Dalam klasifikasi terbaru OWASP API Security Top 10, istilah IDOR telah diserap dan dikategorikan ke dalam BOLA untuk memberikan cakupan yang lebih luas terhadap kerentanan otorisasi pada tingkat objek.
BOLA adalah kategori payung yang mencakup kegagalan otorisasi saat aplikasi tidak memvalidasi apakah pengguna yang masuk memiliki izin untuk mengakses objek tertentu (seperti data pengguna lain) melalui ID yang dimanipulasi. IDOR adalah metode serangan klasik yang memanfaatkan manipulasi referensi objek langsung (seperti /api/users/123 menjadi /api/users/124) untuk mengeksploitasi celah BOLA tersebut.
Tabel Matriks Perbandingan
| Fitur | IDOR | BOLA |
|---|---|---|
| Cakupan | Spesifik (Referensi Objek) | Luas (Seluruh Otorisasi Objek) |
| Klasifikasi OWASP | Bagian dari BOLA | Kategori Utama (API1:2023) |
| Metode Eksploitasi | Manipulasi ID/Parameter | Manipulasi ID, Header, atau Token |
| Fokus Utama | Akses data via referensi | Validasi izin akses objek |
Analisis Mendalam
Apa itu IDOR?
IDOR terjadi ketika aplikasi mengekspos referensi ke objek internal (seperti database key atau nama file) tanpa pemeriksaan kontrol akses. Contoh: Seorang pengguna dengan ID 100 mengakses /api/orders/500. Jika sistem hanya memeriksa apakah pengguna sudah login tanpa memeriksa apakah order 500 milik pengguna 100, maka IDOR terjadi.
Apa itu BOLA?
BOLA adalah kegagalan sistem dalam memverifikasi otorisasi pada tingkat objek. BOLA tidak hanya terbatas pada manipulasi ID di URL. BOLA bisa terjadi melalui manipulasi parameter di body request, header HTTP, atau bahkan melalui teknik parameter pollution yang membuat sistem salah mengidentifikasi pemilik objek. BOLA adalah masalah logika bisnis yang mendasar pada arsitektur API.
Cara Mencegah
- Implementasi Otorisasi Berbasis Kebijakan: Jangan hanya mengandalkan autentikasi (siapa Anda), tetapi wajibkan otorisasi (apa yang boleh Anda akses) pada setiap endpoint.
- Gunakan UUID: Mengganti ID numerik berurutan (1, 2, 3) dengan UUID (Universally Unique Identifier) mempersulit penyerang untuk menebak ID objek lain, meskipun ini bukan solusi utama (hanya security by obscurity).
- Validasi Kepemilikan: Setiap kali API menerima request untuk objek tertentu, sistem harus melakukan query database untuk memastikan
user_idyang meminta adalah pemilik sah dariobject_idtersebut.