Menguji Hak Akses Web App dengan Matriks Peran Pengguna

Tombol yang hilang dari layar belum membuktikan bahwa suatu tindakan sudah terlindungi. Saat merancang web app, pemilik bisnis perlu dapat menjelaskan siapa yang boleh melakukan apa, terhadap data yang mana. Matriks peran membuat percakapan ini lebih konkret sebelum pengujian dimulai.

Contoh di bawah memakai aplikasi pencatatan pekerjaan fiktif. Sesuaikan keputusan izin dengan proses bisnis Anda; nama peran yang sama bisa memiliki tanggung jawab berbeda pada aplikasi lain.

Mulai dari tindakan yang berisiko

Tuliskan tindakan sebagai kata kerja: melihat pekerjaan, membuat catatan, mengubah penanggung jawab, mengekspor daftar, dan menghapus pekerjaan. Pisahkan tindakan yang tampak mirip. Mengedit catatan sendiri tidak otomatis berarti boleh mengubah catatan rekan, dan membaca ringkasan tidak otomatis berarti boleh mengunduh seluruh data.

Kemudian tentukan lingkupnya: pekerjaan sendiri, satu tim, atau seluruh perusahaan. Sertakan status bila relevan. Misalnya, operator boleh memperbaiki draf sendiri tetapi catatan yang sudah disetujui hanya dapat dibuka kembali oleh pemilik. Aturan ini harus menjadi keputusan bisnis yang tertulis, bukan tebakan pengembang saat membuat tombol.

Buat matriks yang dapat diuji

Skenario contoh	Pemilik	Operator	Pembaca
Membaca pekerjaan tim yang ditugaskan	Boleh	Boleh	Boleh
Mengubah draf milik sendiri	Boleh	Boleh	Ditolak
Mengubah draf milik rekan	Boleh	Ditolak	Ditolak
Mengekspor daftar seluruh perusahaan	Boleh	Ditolak	Ditolak
Menghapus pekerjaan yang sudah disetujui	Perlu proses khusus	Ditolak	Ditolak

Kolom terakhir mengingatkan bahwa “pemilik” pun tidak harus mendapat jalan pintas untuk semua tindakan. Penghapusan mungkin memerlukan alasan, arsip, atau persetujuan tambahan. Tentukan hasil yang diharapkan untuk setiap sel: berhasil, ditolak, atau masuk proses khusus. Dengan begitu, pengujian memiliki ukuran lulus yang jelas.

Uji lewat beberapa pintu masuk

Mulailah dengan tiga akun uji dan dua pekerjaan fiktif milik operator yang berbeda. Jangan memakai data pelanggan asli untuk membuat contoh. Masuk sebagai operator pertama, buka pekerjaan sendiri, lalu coba pekerjaan operator kedua melalui alamat langsung yang sudah disediakan tim pengujian.

Ulangi untuk tindakan simpan, ekspor, dan unduh berkas. Jika aplikasi mempunyai API, pengujian terotorisasi perlu mencakup permintaan API tersebut. Menu yang tersembunyi hanya membantu navigasi; keputusan izin harus diperiksa di sisi server. Prinsip pemeriksaan setiap permintaan dan akses minimum dijelaskan dalam panduan otorisasi OWASP.

Catat juga hasil setelah peran berubah. Operator yang dipindah tim tidak seharusnya terus membaca pekerjaan lama hanya karena tab masih terbuka. Tim teknis perlu menentukan bagaimana sesi dan perubahan izin diterapkan, lalu menguji keputusan itu secara nyata.

Tambahkan perubahan peran pada skenario

Matriks statis perlu dilengkapi urutan kejadian yang menyerupai pekerjaan nyata. Dalam aplikasi contoh, seorang operator membuat draf ketika berada di tim A, kemudian dipindahkan ke tim B. Tentukan lebih dahulu apakah ia boleh membaca riwayat pekerjaan tim A, mengubah draf yang belum selesai, atau hanya melihat tugas barunya. Tidak ada satu jawaban yang cocok untuk semua bisnis; keputusan tersebut harus diketahui sebelum pengujian dijalankan.

Gunakan akun dan data yang disiapkan khusus untuk pengujian terotorisasi. Catat izin sebelum perpindahan, lakukan perubahan melalui fitur administrasi yang disepakati, lalu periksa hasil pada sesi yang sudah terbuka serta saat masuk kembali. Tulis waktu perubahan dan langkah yang dilakukan agar tim dapat mengulang kasus yang sama. Jika hasil berbeda dari matriks, laporkan tindakan serta lingkup data yang masih terbuka, bukan sekadar label perannya.

Uji aturan saat fitur bertambah

Fitur baru sering memperkenalkan tindakan yang belum ada dalam matriks. Contohnya, tombol menyalin pekerjaan mungkin membuat draf baru sekaligus menyalin lampiran. Tentukan apakah pengguna boleh menyalin kedua bagian, hanya data tertentu, atau tidak boleh melakukannya. Uji juga apa yang terjadi ketika sumber pekerjaan sudah tidak dapat diakses.

Saat kebutuhan bisnis berubah, simpan revisi matriks dan alasan perubahannya bersama daftar kasus uji. Tunjuk orang yang menyetujui aturan serta tim yang membuktikan hasilnya. Pengujian kemudian dapat diarahkan ke izin yang berubah tanpa mengabaikan tindakan lama yang masih penting. Matriks yang dapat diperbarui membantu percakapan antara pemilik proses dan pengembang tetap memakai aturan yang sama.

Simpan bukti hasil yang dapat diulang

Penolakan harus dapat dimengerti pengguna tanpa membocorkan isi data yang tidak boleh dilihat. Periksa apakah judul, pratinjau, lampiran, atau hasil pencarian masih menampilkan informasi meskipun halaman detail sudah diblokir. Sebuah pengujian tidak selesai hanya karena muncul pesan “akses ditolak”.

Simpan catatan singkat berisi akun uji, lingkup data, tindakan, hasil yang diharapkan, hasil aktual, dan versi aplikasi. Jika aturan bisnis berubah, perbarui matriks sekaligus kasus uji. Matriks ini merupakan alat kerja bersama, bukan sertifikat keamanan.

Untuk proyek baru, bahas peran dan lingkup data dalam perencanaan web app. Sertakan contoh matriks dalam brief proyek untuk Creatyf agar estimasi mencakup pengembangan serta pengujian alur izin yang benar-benar dibutuhkan.

Sumber resmi

• OWASP: Authorization Cheat Sheet
• OWASP: Testing for Bypassing Authorization Schema