Masalah
Managed Rules dapat memblokir request valid ketika pola aplikasi menyerupai payload berbahaya. Respons yang terlalu luas, seperti mematikan seluruh ruleset, menghilangkan perlindungan yang sebenarnya masih dibutuhkan.
Security GuideCloudflareLanjutan
Cloudflare WAF Tuning: Managed Rules, false positive, dan exception yang aman
Kurangi false positive dengan scope exception yang sempit, verifikasi rule ID, dan perubahan bertahap tanpa mematikan managed protection secara luas.
Tujuan latihan
Mendesain proses WAF tuning yang menjaga proteksi sambil mengurangi dampak terhadap traffic valid.
PersiapanAkses Cloudflare WAF dan traffic/log evidence. Terapkan di staging atau change window bila memungkinkan.
Security event→
Rule evidence→
Narrow exception
Persiapan
Kumpulkan Ray ID, hostname, path, method, source, rule ID, action, dan contoh request yang sudah disanitasi. Pastikan request memang legitimate sebelum membuat pengecualian.
1. Identifikasi rule spesifik
Cari security event dan tentukan managed ruleset serta rule ID yang memicu. Bedakan false positive dari request yang benar-benar anomali.
2. Tentukan scope terkecil
Mulai dari kondisi paling sempit, misalnya hostname + path + method + karakteristik aplikasi yang stabil. Hindari expression yang mengecualikan seluruh domain bila masalah hanya ada pada satu endpoint.
3. Pilih mekanisme tuning
Cloudflare menyediakan exceptions untuk skip managed ruleset atau rule tertentu pada kondisi yang cocok, serta overrides untuk menyesuaikan action atau rule behavior. Exceptions memiliki prioritas terhadap overrides.
4. Perhatikan execution order
Skip rule hanya memengaruhi execute rules yang muncul setelahnya dalam entry point ruleset. Posisi rule penting ketika menilai kenapa exception tidak bekerja.
5. Uji dan observasi
Uji request legitimate dan beberapa negative test yang aman. Pastikan traffic valid lolos tanpa membuat endpoint terlalu permisif. Simpan alasan, owner, dan tanggal review untuk exception.
Verifikasi
Pantau security events setelah perubahan. Jika exception tidak lagi diperlukan setelah aplikasi diperbaiki, hapus atau persempit rule agar technical debt WAF tidak menumpuk.
5. Bedakan exception, skip, dan menonaktifkan ruleset
Tujuan tuning adalah mengurangi false positive dengan perubahan paling sempit. Jika platform menyediakan exception/skip untuk rule atau phase tertentu, pilih scope terkecil yang menyelesaikan masalah daripada menonaktifkan seluruh managed ruleset. Dokumentasikan rule ID dan kondisi yang dikecualikan.
6. Uji negative dan positive case
Setelah tuning, uji traffic legitimate yang sebelumnya terblokir sekaligus request berbahaya/simulasi aman yang seharusnya tetap dimitigasi. Perubahan dianggap berhasil hanya jika false positive berkurang tanpa membuka path lain secara tidak sengaja.
7. Gunakan expiry/review untuk exception sementara
Exception yang dibuat saat incident atau deployment sebaiknya memiliki owner dan tanggal review. Aplikasi berubah, sehingga bypass yang dulu diperlukan dapat menjadi celah permanen jika tidak pernah ditinjau kembali.
Kesalahan umum
Jangan membuat exception berbasis path terlalu luas seperti seluruh /api/* jika hanya satu endpoint bermasalah. Jangan memasukkan IP developer sebagai solusi permanen untuk false positive aplikasi. Jangan menurunkan sensitivity global sebelum mengetahui managed rule yang benar-benar match.
Checklist verifikasi
Simpan event ID/Ray ID, rule ID, field yang memicu, endpoint, sample request yang sudah disanitasi, scope exception, hasil retest legitimate, dan hasil kontrol keamanan. Review analytics setelah rollout untuk memastikan tidak ada lonjakan bypass atau attack traffic.
Pelajaran
WAF tuning yang baik bukan sekadar membuat false positive hilang. Tujuannya adalah mempertahankan coverage sebanyak mungkin dengan pengecualian yang sempit, dapat dijelaskan, dan dapat diaudit.