Insecure Direct Object Reference (IDOR): Cara Kerja & Mitigasi

Insecure Direct Object Reference (IDOR) adalah jenis kerentanan keamanan siber yang terjadi ketika sebuah aplikasi mengekspos referensi ke objek internal langsung—seperti nomor database, nama file, atau kunci primer—tanpa menerapkan pemeriksaan otorisasi yang memadai. Akibat kelemahan ini, penyerang dapat memanipulasi parameter masukan untuk mengakses data atau fungsi milik pengguna lain secara ilegal tanpa hak akses yang sah.

Kerentanan ini menempati posisi krusial dalam lanskap keamanan aplikasi web dan sering diklasifikasikan di bawah kategori Broken Access Control oleh Open Worldwide Application Security Project (OWASP). Pencegahan IDOR memerlukan penerapan kontrol akses berbasis peran (RBAC) yang ketat serta penggunaan referensi objek tidak langsung (indirect reference maps).

Mekanisme Kerja Kerentanan IDOR

IDOR muncul karena pengembang sering kali mempercayai data yang dikirimkan oleh klien (pengguna). Ketika aplikasi mengandalkan parameter langsung dari URL atau badan permintaan HTTP untuk mengambil data dari backend tanpa memverifikasi apakah sesi yang sedang aktif berhak atas objek tersebut, celah eksploitasi terbuka.

Sebagai contoh, perhatikan sebuah aplikasi perbankan atau e-commerce yang memuat detail faktur melalui URL berikut:

GET /api/v1/invoices?id=10452 HTTP/1.1
Host: example.com
Cookie: session_id=xyz123

Jika seorang pengguna dengan ID sesi xyz123 mengganti nilai parameter id=10452 menjadi id=10453 di bilah alamat browser, dan server mengembalikan data faktur milik pengguna lain tanpa memvalidasi kepemilikan, maka sistem tersebut rentan terhadap IDOR.

Matriks Perbandingan: Akses Aman vs Rentan IDOR

Berikut adalah perbandingan langsung bagaimana aplikasi menangani permintaan objek antara sistem yang rentan dan sistem yang menerapkan kontrol akses aman.

Contoh Kode Rentan vs Kode Aman

Untuk memahami bagaimana kerentanan ini dieksekusi dan dicek di sisi server, perhatikan cuplikan kode backend menggunakan Node.js dan Express berikut.

Kode Rentan (Tanpa Pengecekan Otorisasi)

// Contoh endpoint yang rentan IDOR
app.get('/user/profile', authenticateToken, async (req, res) => {
    // Mengambil ID langsung dari query string tanpa validasi kepemilikan
    const userId = req.query.id;
    const userData = await database.findUserById(userId);
    
    if (!userData) {
        return res.status(404).send('User not found');
    }
    res.json(userData);
});

Kode Aman (Dengan Validasi Sesi dan Otorisasi)

// Contoh endpoint yang aman dari IDOR
app.get('/user/profile', authenticateToken, async (req, res) => {
    // Memastikan data yang diambil adalah milik pengguna yang sedang terautentikasi
    const authenticatedUserId = req.user.id;
    const requestedUserId = req.query.id;

    if (authenticatedUserId !== requestedUserId) {
        return res.status(403).json({ error: 'Access denied' });
    }

    const userData = await database.findUserById(requestedUserId);
    res.json(userData);
});

Langkah-Langkah Mitigasi dan Pencegahan

Mengamankan aplikasi dari kerentanan Insecure Direct Object Reference membutuhkan pendekatan berlapis dari tahap desain hingga implementasi kode:

1. Implementasikan Kontrol Akses Berbasis Sesi: Jangan pernah mengandalkan asumsi bahwa pengguna yang masuk berhak mengakses semua data. Setiap permintaan harus melalui fungsi middleware yang memverifikasi izin akses terhadap objek spesifik.
2. Gunakan Referensi Objek Tidak Langsung (Indirect Reference Maps): Ganti ID database yang berurutan dengan peta referensi acak (seperti UUID v4) atau gunakan mekanisme hash token yang hanya berlaku untuk sesi atau transaksi tertentu.
3. Terapkan Prinsip Hak Istimewa Terendah (Principle of Least Privilege): Pastikan akun database atau layanan mikro yang digunakan aplikasi hanya memiliki akses minimum yang diperlukan untuk menjalankan fungsinya.
4. Lakukan Pengujian Keamanan Berkala: Jalankan pengujian penetrasi (penetration testing) dan pemindaian kerentanan otomatis secara rutin untuk mendeteksi potensi celah akses kontrol sebelum aplikasi dirilis ke lingkungan produksi.