IDOR atau Insecure Direct Object Reference adalah celah keamanan tingkat lanjut yang terjadi ketika aplikasi mengekspos referensi ke objek internal langsung—seperti nomor ID database atau nama file—tanpa melakukan validasi hak akses (otorisasi) yang memadai. Penyerang dapat memanipulasi parameter ini (misalnya mengubah /api/user/101 menjadi /api/user/102) untuk mengakses data pengguna lain secara ilegal. Pencegahan IDOR pada API memerlukan penerapan kontrol akses berbasis peran (RBAC/ABAC) yang ketat di sisi server pada setiap endpoint.
Dalam arsitektur API modern, mengandalkan kerahasiaan URL atau ID acak saja tidak cukup untuk menghentikan IDOR. Sistem harus selalu memverifikasi apakah identitas yang sedang aktif (melalui token JWT atau sesi) memiliki hak penuh untuk membaca, memperbarui, atau menghapus sumber daya yang diminta.
Metodologi Pencegahan IDOR pada API
Untuk menutup celah keamanan IDOR secara menyeluruh, pengembang harus mengimplementasikan lapisan pertahanan berlapis di dalam kode sumber aplikasi backend. Berikut adalah tabel matriks strategi mitigasi teknis yang wajib diterapkan:
| Strategi Mitigasi | Penjelasan Teknis | Tingkat Efektivitas |
|---|---|---|
| Pemeriksaan Otorisasi Berbasis Sesi | Membandingkan ID pemilik objek di database dengan ID pengguna yang terautentikasi dalam token akses (JWT/Session). | Sangat Tinggi |
| Penggunaan Indirect References (Map) | Menggunakan peta atau indeks acak sementara di sisi server yang menghubungkan ID asli dengan referensi sesi pengguna. | Tinggi |
| Implementasi UUID v4 / Hash | Mengganti ID integer berurutan (1, 2, 3) dengan UUID v4 yang tidak dapat ditebak polanya. | Sedang (Sebagai pertahanan lapis kedua) |
| Validasi Input Ketat | Memastikan tipe data parameter sesuai skema menggunakan validator ketat sebelum dikirim ke query database. | Tinggi |
Contoh Implementasi Pencegahan IDOR (Node.js / Express)
Berikut adalah contoh kode backend yang rentan terhadap IDOR dan bagaimana cara memperbaikinya dengan menambahkan validasi kepemilikan data secara eksplisit.
Kode Rentan (Tanpa Pengecekan Otorisasi)
app.get('/api/orders/:orderId', authenticateToken, async (req, res) => {
// Rentan: Mengambil data hanya berdasarkan parameter URL tanpa cek kepemilikan
const order = await db.query('SELECT * FROM orders WHERE id = ?', [req.params.orderId]);
res.json(order);
});Kode Aman (Dengan Validasi Sesi dan Kepemilikan)
app.get('/api/orders/:orderId', authenticateToken, async (req, res) => {
const userId = req.user.id; // Diambil dari token JWT yang sudah diverifikasi
const orderId = req.params.orderId;
// Pastikan order milik user yang sedang login
const order = await db.query(
'SELECT * FROM orders WHERE id = ? AND user_id = ?',
[orderId, userId]
);
if (order.length === 0) {
return res.status(403).json({ error: 'Akses ditolak atau data tidak ditemukan' });
}
res.json(order);
});Langkah-Langkah Audit Keamanan API
- Mapping Endpoint: Buat daftar seluruh endpoint API yang menerima parameter objek atau ID pada path, query string, maupun body payload.
- Pengujian Multi-Akun: Gunakan minimal dua akun berbeda (misal Akun A dan Akun B) untuk mencoba mengakses sumber daya milik satu sama lain menggunakan perangkat penguji seperti Burp Suite atau Postman.
- Otomatisasi Pengujian: Integrasikan pemindai kerentanan otomatis dalam alur kerja CI/CD untuk mendeteksi perubahan endpoint yang mungkin melupakan validasi hak akses.
Tips Troubleshooting Lapangan
Jika pengujian penetrasi masih menemukan celah IDOR meskipun UUID telah diterapkan, periksa kembali apakah fungsi internal database atau fungsi administratif mengabaikan konteks pengguna yang sedang aktif. Selalu terapkan prinsip Principle of Least Privilege (PoLP) pada tingkat basis data dan pastikan ORM (Object-Relational Mapping) yang digunakan tidak secara otomatis melompati filter otorisasi.