IDOR (Insecure Direct Object Reference) adalah jenis kerentanan keamanan akses kontrol di mana aplikasi mengekspos referensi ke objek internal langsung, seperti database ID atau nama file, tanpa validasi otorisasi yang memadai. Penyerang dapat memanipulasi parameter ini untuk mengakses data pengguna lain secara ilegal.
Dalam dunia pengujian penetrasi (penetration testing) dan keamanan siber, kasus IDOR menempati peringkat tinggi dalam OWASP Top 10 karena dampaknya yang masif terhadap kerahasiaan data. Artikel ini membedah studi kasus nyata bagaimana IDOR terjadi pada sistem berbasis web dan API, serta bagaimana cara menambalnya secara permanen.
Anatomi Studi Kasus IDOR pada Aplikasi E-Commerce
Sebagai ilustrasi nyata, perhatikan sebuah platform e-commerce fiktif bernama TokoAman. Platform ini memiliki fitur unduh faktur pesanan bagi setiap pelanggan setelah melakukan transaksi pembayaran.
Ketika pengguna dengan ID 1005 mengunduh faktur transaksi miliknya, peramban (browser) mengirimkan permintaan HTTP GET ke endpoint API berikut:
GET /api/v1/invoices?id=58421 HTTP/1.1
Host: api.tokoaman.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...Meskipun token autentikasi (Bearer token) milik pengguna 1005 dikirimkan dengan benar, server backend TokoAman gagal memverifikasi apakah faktur dengan ID 58421 benar-benar milik pengguna 1005. Akibatnya, ketika penyerang mengganti parameter id menjadi 58422, server tetap mengembalikan data faktur lengkap dengan informasi alamat pengiriman, nomor telepon, dan rincian belanja milik pengguna lain.
Matriks Analisis Risiko dan Dampak IDOR
| Komponen Analisis | Keterangan Teknis |
|---|---|
| Vektor Serangan | Manipulasi parameter URL, form data, JSON body, atau header HTTP. |
| Dampak Kerahasiaan | Pencurian data pribadi (PII), laporan keuangan, dan dokumen rahasia. |
| Dampak Integritas | Kemungkinan modifikasi atau penghapusan data entitas lain jika metode PUT/DELETE rentan. |
| Tingkat Keparahan (CVSS) | Tinggi hingga Kritis (High to Critical), tergantung sensitivitas data. |
Jenis-Jenis IDOR Berdasarkan Lokasi Parameter
Kerentanan IDOR tidak hanya ditemukan pada parameter URL (Query String), tetapi juga sering bersembunyi di berbagai bagian permintaan HTTP yang jarang diamati oleh pengembang:
- URL Path Parameter: Contohnya pada rute RESTful seperti
/api/users/402/profiledi mana angka402dapat diganti secara leluasa. - JSON Body POST/PUT Request: Parameter tersembunyi dalam payload JSON seperti
{"account_id": 8812, "amount": 500}yang dikirim ke server. - HTTP Headers: Penggunaan header kustom seperti
X-User-ID: 992yang dipercaya mentah-mentah oleh server tanpa validasi ulang terhadap token sesi.
Langkah Mitigasi dan Pencegahan Teknis
Menambal kerentanan IDOR memerlukan perbaikan pada lapisan kontrol akses (Access Control Layer) di sisi server, bukan sekadar menyembunyikan referensi objek dari antarmuka pengguna.
1. Implementasi Pengecekan Otorisasi Berbasis Sesi (Indirect Reference / Map)
Pastikan setiap kali ada permintaan data, server membandingkan identitas pemilik objek (user ID dari token sesi yang sah) dengan pemilik data yang tersimpan di dalam database.
# Contoh pseudocode validasi otorisasi di backend
def get_invoice(request, invoice_id):
current_user = get_authenticated_user(request)
invoice = Database.find_invoice(invoice_id)
if not invoice:
return HttpResponse(404)
if invoice.user_id != current_user.id:
return HttpResponse(403, "Akses Ditolak")
return JsonResponse(invoice.data)2. Penggunaan Referensi Tidak Langsung (Indirect Reference Objects)
Alih-alih menggunakan ID berurutan (autoincrement integer seperti 1, 2, 3) yang mudah ditebak, gunakan UUID v4 atau token acak yang terenkripsi untuk setiap objek sensitif.
3. Pengujian Keamanan Berkala (Access Control Testing)
Lakukan pengujian fungsionalitas kontrol akses secara otomatis maupun manual menggunakan alat bantu seperti Burp Suite untuk memastikan tidak ada endpoint yang lolos dari validasi hak akses.