Insecure Direct Object Reference (IDOR): Bahaya Pakai Nomor Urut di URL

Bayangin Budi Liat Struk Belanja Siti...

Bayangin Siti baru saja belanja di toko *online* milik Budi. Setelah bayar, Siti diarahkan ke halaman struk belanja dengan URL: toko-budi.com/invoice/15.

Siti iseng. Dia iseng mengganti angka 15 di URL browser-nya menjadi 16, lalu menekan Enter. Tiba-tiba, Bum! Layar menampilkan struk belanja milik orang lain yang berisi nama lengkap, alamat rumah, dan nomor kartu kreditnya! Siti mencoba angka 17, 18, 19, dan dia berhasil menyedot seluruh data pelanggan Budi!

Masalahnya: ID Database yang Mudah Ditebak

Tragedi konyol namun sangat mematikan ini disebut Insecure Direct Object Reference (IDOR). Penyebabnya ada dua:

1. Budi menggunakan Auto-Increment ID (Nomor urut 1, 2, 3) di database MySQL-nya. Ini membuat *Hacker* sangat mudah menebak ID berikutnya.
2. Budi lupa menambahkan kode pengecekan otorisasi di *Backend*-nya: "Apakah user yang sedang login ini adalah pemilik asli dari invoice nomor 16?" Budi cuma ngecek "Apakah invoice 16 ada di database? Kalau ada, tampilkan!".

Nah, Di Sinilah 'UUID' Masuk!

Untuk mencegah nomor datamu ditebak, *Backend Developer* modern tidak lagi menggunakan nomor urut 1, 2, 3 untuk data publik (seperti URL Struk, URL Profil, dsb).

Mereka menggunakan UUID (Universally Unique Identifier). Saat data dibuat, ID-nya bukan 15, melainkan string acak sepanjang 36 karakter seperti: 550e8400-e29b-41d4-a716-446655440000.

Jika URL struknya menjadi toko.com/invoice/550e84..., Hacker paling jenius di bumi pun TIDAK AKAN MUNGKIN bisa menebak rangkaian karakter dari struk milik orang lain.

Intinya: Gunakan nomor urut biasa (Integer) hanya untuk urusan internal di belakang layar. Tapi jika ID itu harus muncul di URL *Browser*, wajib gunakan UUID yang tidak bisa ditebak!