Menyusun rencana verifikasi keamanan aplikasi dengan ASVS

Apa yang harus dihasilkan dari rencana ASVS?

Rencana verifikasi harus menjelaskan apa yang diperiksa dan bukti apa yang akan menunjukkan hasilnya. Menulis “menggunakan ASVS” dalam lingkup pentest belum menjelaskan fitur, persyaratan, cara pemeriksaan, atau pekerjaan yang belum dilakukan.

ASVS adalah Application Security Verification Standard, rujukan OWASP untuk persyaratan keamanan aplikasi web. Halaman ini memakai rilis 5.0.0. Untuk memilih antara ASVS, daftar risiko dan panduan pengujian, baca perbandingan proyek OWASP.

Tetapkan objek dan aturan produk

Catat aplikasi, API, build, lingkungan, peran akun, pemilik data dan integrasi yang masuk lingkup. Gunakan akun serta data buatan dalam lingkungan yang diizinkan. Tuliskan alur penting, misalnya membuat akun, membaca laporan, mengubah izin dan mengekspor data.

Sebelum memeriksa akses, sepakati aturan produk. Contoh: anggota organisasi A hanya boleh membaca laporan A. Aturan itu menjadi kriteria kasus uji; jangan menentukan izin yang benar hanya dari perilaku aplikasi saat ini.

Pilih persyaratan dan simpan versinya

Mulai dari risiko dan fungsi aplikasi, lalu periksa persyaratan yang relevan pada naskah rilis. Catat setiap persyaratan dengan format seperti v5.0.0-8.2.2: akses ke objek data perlu sesuai izin pengguna. Hubungkan juga dokumentasi aturan akses dan tempat pemeriksaannya pada server.

Jika targetnya suatu level ASVS, rencanakan seluruh persyaratan yang berlaku untuk level itu. Memilih beberapa kasus berisiko tinggi tidak otomatis memenuhi level tersebut. Bagian yang tidak berlaku perlu alasan berdasarkan lingkup; bagian yang belum diperiksa tetap berstatus belum diperiksa.

Satu persyaratan dapat memerlukan beberapa metode: membaca konfigurasi atau kode, meninjau aturan, menjalankan kasus positif/negatif dan memeriksa efek samping. Hasil scanner saja sering belum menjawab aturan bisnis.

Ubah persyaratan menjadi kasus yang jelas

Catatan	Contoh rencana
Rujukan	ASVS 5.0.0, v5.0.0-8.2.2; kasus lokal AK-02.
Objek	GET /reports/B, dipanggil dengan identitas uji A.
Harapan	Ditolak menurut aturan lab: 403, tanpa REPORT_B_DEMO.
Metode	Baca aturan pemilik objek pada server; jalankan A → A dan A → B, lalu simpan respons.
Bukti	Versi source/build, identitas buatan, permintaan, status dan isi respons.
Batas	Satu endpoint baca; autentikasi nyata, ekspor dan antrean belum diperiksa.

Status 403 adalah pilihan fixture ini, bukan satu kode respons wajib untuk semua produk. Untuk menyiapkan banyak kombinasi peran dan objek, gunakan matriks pengujian hak akses.

Contoh yang dijalankan: laporan A dan B

Unduh source dan hasil lab verifikasi 1.0. Paket kecil ini berisi kode orisinal, petunjuk, serta hasil dengan data buatan; tanpa APK atau private key. Jalankan contoh server dengan Node 24:

node asvs-example.mjs > asvs-results.json

Contoh dijalankan pada 1 Oktober 2026, Node 24.21.0. Server hanya mendengar pada loopback selama tes. Identitas A/B diberikan lewat header khusus fixture; ini bukan rancangan autentikasi untuk aplikasi produksi.

• Build bad, A → A: 200, laporan A tersedia sesuai aturan.
• Build bad, A → B: 200 dan REPORT_B_DEMO muncul. Kasus gagal karena data organisasi lain terbuka.
• Build fixed, A → A: tetap 200; perbaikan tidak memblokir akses yang sah.
• Build fixed, A → B: 403, tanpa isi laporan B. Kasus penolakan memenuhi harapan lab setelah server memeriksa pemilik objek.

Hasil tersebut membuktikan perubahan pada kasus yang dijalankan. Belum membuktikan seluruh persyaratan akses objek, identitas pengguna, semua endpoint atau level ASVS. Fixture baca ini tidak melakukan perubahan data; aplikasi nyata juga perlu pemeriksaan efek samping, tautan unduhan dan pekerjaan di latar belakang.

Tinjau bukti dan pekerjaan yang tersisa

Pisahkan hasil memenuhi harapan kasus, gagal, belum diperiksa, dan tidak berlaku dengan alasan. Setelah perbaikan, simpan versi baru serta hasil uji ulang; jangan menimpa bukti sebelum perbaikan.

Gunakan catatan verifikasi keamanan aplikasi untuk menghubungkan persyaratan dengan bukti. Untuk bagian mobile, lanjutkan ke pemeriksaan penyimpanan dan komunikasi jaringan, dengan rujukan MASVS/MASTG dan lingkungan tersendiri.

Penjelasan persyaratan diringkas dari OWASP ASVS 5.0.0 dengan perubahan bahasa. Bagian adaptasi tersebut mengikuti CC BY-SA 4.0; format rencana, kode dan hasil lab adalah contoh orisinal Kompli.

Contoh tambahan: beberapa alur dalam satu rencana

Batch lab keamanan aplikasi 1.0 dijalankan pada 2 Oktober 2026, Node 24.21.0. Unduh source dan hasilnya. Ini melengkapi contoh baca laporan; tidak mengganti bukti run sebelumnya.

Rujukan / kasus	Hasil dan batas bukti
v5.0.0-8.2.2, izin laporan GraphQL	Bad membuka data B untuk A; fixed dan retest menolak pada query biasa, alias serta fragment. Identitas dikontrol fixture; mutation dan izin field belum diperiksa.
v5.0.0-4.3.1, pembatasan query	Empat alias: bad memanggil resolver empat kali; fixed/retest menolak sebelum resolver. Hitungan node pada schema kecil, bukan penilaian biaya semua query.
v5.0.0-2.3.1 dan v5.0.0-2.3.2, alur pesanan	Langkah konfirmasi, harga katalog dan aturan kunci retry diperiksa. Fixed/retest memenuhi harapan fungsi fixture. Tidak mencakup semua urutan/aturan produk.
v5.0.0-7.4.1, sesi dicabut	Bad masih menerima sesi nonaktif; fixed/retest menolak. Satu sesi di memori; cookie, JWT dan refresh token tidak diperiksa.
v5.0.0-2.3.3 / v5.0.0-2.3.4	Belum diperiksa: rollback database dan penguncian stok, karena lab tidak mempunyai database atau beberapa pekerja.
v5.0.0-6.8.2 / v5.0.0-6.8.3	Belum diperiksa: validasi tanda tangan assertion dan replay SAML. Jangan menjadikan model sesi sebagai bukti protokol federasi.

Buka pengujian alur transaksi dan GraphQL untuk langkah/hasil. Lab passkey memakai verifikasi WebAuthn tersendiri; hasilnya tidak menggantikan penilaian semua faktor autentikasi ASVS.

ID di atas berasal dari rilis ASVS 5.0.0. “Memenuhi harapan kasus” adalah status kasus yang dijalankan. Persyaratan yang lebih luas tetap perlu semua bukti yang berlaku pada lingkup dan level yang dituju.