Awalnya, saya tidak berekspektasi tinggi. Sekadar ingin mencoba, memahami alur aplikasi, dan melihat apakah saya bisa menemukan sesuatu yang "menarik".

Ternyata, dari sesuatu yang terlihat sangat sederhana — hanya mengganti angka di URL — saya menemukan celah yang cukup serius.

🎯 Target yang Terlihat "Normal"

Aplikasi yang diuji adalah sebuah job portal. Secara umum, fiturnya cukup standar:

  • Perusahaan bisa memposting lowongan
  • Kandidat bisa melamar
  • Perusahaan bisa mereview, menerima, atau menolak kandidat

Semua terlihat berjalan sebagaimana mestinya.

Sampai saya memperhatikan satu endpoint:

/applications/{id}

Sekilas, ini endpoint biasa untuk melihat data lamaran.

Tidak ada yang mencurigakan… sampai saya mulai penasaran.

🤔 "Apa yang Terjadi Kalau Angkanya Diganti?"

Saya login sebagai user dengan role perusahaan.

Lalu saya membuka salah satu lamaran:

/applications/3
None

Data muncul normal.

Kemudian saya melakukan hal paling klasik dalam dunia security testing:

👉 Mengganti angka 3 menjadi 6

/applications/6
None
None

Dan… ternyata tetap bisa diakses.

🚨 Saat Realisasi Itu Datang

Di titik ini, ada satu pertanyaan penting:

"Ini data punya saya… atau punya orang lain?"

Saya lanjut mencoba beberapa ID lain:

/applications/2
/applications/4
/applications/5

Semuanya bisa diakses.

Dan yang lebih mengejutkan: data tersebut bukan milik perusahaan saya.

Di sinilah saya menyadari bahwa ini bukan sekadar bug kecil.

Ini adalah IDOR (Insecure Direct Object Reference) — salah satu bentuk dari Broken Access Control yang sering dibahas oleh OWASP dalam OWASP Top 10 2021.

🔓 Bukan Cuma Bisa Lihat… Tapi Bisa Ngapa-ngapain

Biasanya, IDOR "hanya" memungkinkan kita melihat data.

Tapi di kasus ini, dampaknya lebih dalam.

Saya mencoba fitur yang tersedia:

  • Accept kandidat
  • Reject kandidat
  • Memberikan review

Dan semuanya… berhasil.

Tanpa error. Tanpa validasi. Tanpa peringatan.

Artinya:

💥 Saya bisa memproses lamaran milik perusahaan lain 💥 Saya bisa mempengaruhi hasil rekrutmen mereka 💥 Saya bisa merusak integritas sistem tanpa hambatan

🧠 Apa yang Sebenarnya Terjadi?

Masalah utamanya ternyata cukup klasik:

❌ Tidak Ada Ownership Check

Sistem tidak pernah mengecek apakah data lamaran tersebut milik perusahaan yang sedang login.

❌ Tidak Ada Validasi Otorisasi di Server

Server langsung memproses request, seolah semua user berhak mengakses semua data.

❌ ID Mudah Ditebak

Penggunaan ID incremental (1, 2, 3, ...) membuat eksploitasi jadi sangat mudah.

⚠️ Dampak Nyata (Bukan Sekadar Teori)

Kalau celah ini dieksploitasi oleh pihak yang tidak bertanggung jawab, dampaknya bisa serius:

  • Kebocoran data pelamar (privacy issue)
  • Manipulasi hasil rekrutmen
  • Perusakan reputasi perusahaan
  • Potensi fraud dalam proses hiring

Dengan kata lain, ini bukan hanya masalah teknis — tapi juga masalah bisnis.

🛠️ Bagaimana Seharusnya Ini Dicegah?

Ada beberapa hal yang seharusnya dilakukan:

✅ Validasi Kepemilikan

Setiap request harus memastikan bahwa data tersebut milik user:

SELECT * FROM applications 
WHERE id = ? AND company_id = current_user.company_id;

✅ Gunakan RBAC

Role-Based Access Control memastikan siapa boleh melakukan apa.

✅ Jangan Percaya Frontend

Semua validasi harus dilakukan di server, bukan hanya di UI.

✅ Gunakan Identifier yang Lebih Aman

Mengganti ID dengan UUID bisa memperkecil peluang eksploitasi:

/applications/550e8400-e29b-41d4-a716-446655440000

📊 Seberapa Parah Ini?

Kerentanan ini dinilai:

  • CVSS Score: 8.8 (High)
  • Dampak tinggi pada:
  • Confidentiality
  • Integrity
  • Availability

Referensi klasifikasi juga dapat ditemukan di MITRE sebagai CWE-639, serta pembahasan teknis oleh PortSwigger.

✍️ Refleksi Pribadi

Dari pengalaman ini, saya belajar satu hal penting:

Kadang, vulnerability tidak datang dari teknik yang kompleks… tapi dari hal sederhana yang terlewat.

Mengganti angka di URL mungkin terlihat sepele.

Tapi jika tidak ada kontrol akses yang benar, dampaknya bisa sangat besar.

🚀 Penutup

Challenge ini menjadi pengalaman berharga bagi saya.

Bukan hanya karena menemukan vulnerability, tapi karena memahami bagaimana bug sederhana bisa berubah menjadi risiko besar.

Dan yang paling penting:

Security bukan hanya soal login. Tapi soal memastikan setiap user hanya bisa mengakses apa yang memang menjadi haknya.