Baseline ZAP: Nol Kegagalan Bukan Angka Terpenting

Permintaan owner masuk sebelum gelombang QA backfill dimulai: jalankan ulang baseline ZAP, karena sejak sesi perbaikan sehari sebelumnya ada permukaan baru, autentikasi pengguna lewat Google OAuth. Hasilnya dibaca langsung dari artefak zap-baseline.json, bukan dari transkrip konsol. Angkanya: nol FAIL, empat WARN, 57 PASS. Dipicu otorisasi pihak ketiga baru, ekspektasi awal justru sebaliknya: integrasi semacam itu biasanya membawa header longgar atau kebijakan konten yang bocor, dan setidaknya satu alert baru diharapkan muncul. Sesi pembandingnya juga jelas: baseline dengan aturan identik sudah ada dari sehari sebelumnya, sehingga perbandingannya apel ke apel, bukan lintas versi alat atau konfigurasi yang berbeda.

Tabel delta, bukan angka tunggal

Yang membuat sesi ini layak dipercaya bukan angka nolnya, melainkan perbandingan tingkat aturan terhadap baseline sehari sebelumnya. Setiap baris bergerak turun atau diam: CSP wildcard directive dari tiga instance menjadi dua, script-src unsafe-eval tiga menjadi dua, script-src unsafe-inline tiga menjadi dua, style-src unsafe-inline tiga menjadi dua, timestamp disclosure dua menjadi satu, suspicious comments sebelas menjadi sembilan, dan modern web application tetap lima. Tidak ada aturan baru, tidak ada instance yang naik. Permukaan OAuth yang ditakutkan tidak memunculkan satu alert pun di level pasif. Angka-angka delta itu sendiri bukan hasil hitung manual: laporan sesi mewajibkan verifikasi dari berkas JSON, dan ketika jumlah instance per aturan dihitung ulang dari artefak, hasilnya cocok dengan tabel. Mesin yang menghasilkan bukti, mesin yang sama yang menutup pertanyaan.

Satu koreksi pembacaan angka perlu dicatat. Ringkasan laporan menulis empat peringatan, sementara artefak JSON memuat tujuh instance alert: empat Medium, satu Low, dua Informational. Angka empat pada ringkasan menghitung instance Medium yang dikonfigurasi sebagai WARN; sisanya tercatat sebagai PASS atau informasional. Dua pembacaan itu saling melengkapi, dan menyebut salah satunya saja akan membuat pembaca laporan salah paham tentang kondisi aplikasi.

Kenapa pasif cukup untuk tripwire

Skrip baseline resmi menjalankan spider selama satu menit secara default, menunggu pemindaian pasif selesai, lalu melaporkan hasil tanpa melakukan serangan aktif apa pun [1]. Secara default semua alert keluar sebagai WARN, dan berkas konfigurasi bisa menaikkan aturan tertentu menjadi FAIL atau mengabaikannya [1]. Untuk gerbang regresi cepat sebelum backfill, perilaku ini pas: murah, aman dijalankan berulang, dan cukup sensitif terhadap perubahan header, cookie, atau kebocoran informasi. Mode pasif juga berarti satu sesi tidak mengubah apa pun di target: tidak ada form yang dikirim, tidak ada data uji yang tertinggal, sehingga baseline boleh berjalan kapan saja tanpa koordinasi khusus. Biaya rendah itulah yang membuat kebiasaan membandingkan antar sesi akhirnya terjangkat, dan tabel delta hanya bermakna kalau membandingkan jadi kebiasaan.

Batasannya juga tertulis jelas di laporan sesi. Target adalah server pengembangan lewat HTTP tanpa nginx, dan perayapan berjalan tanpa autentikasi sehingga area admin tidak tersentuh. Pengujian manajemen sesi formal ala WSTG menuntut konteks sesi yang sah, sesuatu yang berada di luar jangkauan pemindaian pasif ini [2]. WSTG sendiri memposisikan diri sebagai kerangka praktik terbaik pengujian keamanan aplikasi web, dan pengujian baseline pasif ini adalah irisan paling tipis dari kerangka itu: cukup untuk menangkap regresi konfigurasi, belum menyentuh lapisan logika sesi [2]. Jadi baseline ini bukan pengganti audit, melainkan tripwire: jika permukaan baru membawa kerentanan pasif, tabel delta akan menampilkannya sebagai baris yang naik, bukan sebagai kesimpulan yang harus ditebak dari perubahan kode. Ada satu konsekuensi praktis dari batasan ini: sesi replay untuk area admin dan API berjalan sebagai sesi terpisah, dan sampai sesi itu diulang, klaim aman hanya berlaku untuk halaman publik yang bisa dijangkau tanpa login. Mencampur kedua cakupan dalam satu kalimat kesimpulan adalah cara tercepat membuat laporan keamanan menyesatkan.

Nol FAIL tetap kabar baik. Pelajaran yang bertahan adalah cara angka itu diperoleh: bandingkan tingkat aturan antar sesi, baca dari artefak mesin, dan catat batasan cakupan sejak awal. Tanpa ketiganya, angka nol mudah dikira jaminan, padahal ia baru berarti aman pada lapisan yang benar-benar dipindai.

Sources: [1] dokumentasi resmi zap-baseline.py [2] OWASP Web Security Testing Guide