ModSecurity Adalah: Cara Kerja, Aturan CRS & Kelemahannya

Sebagian besar pengamanan server dimulai dari firewall yang bekerja dengan cara sederhana: menutup pintu yang tidak dipakai. Port basis data ditutup, port SSH dibatasi ke alamat tertentu, sisanya tertutup rapat. Cara ini ampuh menahan pemindai otomatis yang menyisir port satu per satu.

Persoalannya, dua pintu justru harus dibiarkan terbuka lebar supaya website Anda bisa diakses siapa saja: port 80 dan 443. Seluruh serangan yang menumpang permintaan HTTP biasa masuk lewat dua pintu itu. Bagi firewall jaringan, permintaan yang mencuri isi basis data dan permintaan yang membuka halaman beranda tampak sama persis: keduanya paket menuju port 443.

Untuk membedakan keduanya, dibutuhkan pemeriksa yang membaca isi permintaan, bukan sekadar alamat dan nomor portnya. Di situlah perangkat lunak yang akan kita bahas mengambil peran.

ModSecurity Adalah Penyaring di Depan Aplikasi Web Anda

ModSecurity adalah mesin web application firewall (WAF, penyaring serangan di tingkat aplikasi) sumber terbuka yang berjalan sebagai modul di dalam web server. Ia memeriksa isi setiap permintaan HTTP sebelum permintaan itu sampai ke aplikasi Anda: alamat yang diminta, parameter yang dikirim, isi formulir, header, hingga berkas yang diunggah.

Perbedaannya dengan firewall jaringan terletak pada lapisan kerjanya. Firewall jaringan memutuskan berdasarkan alamat IP dan nomor port. WAF adalah penyaring yang justru memutuskan berdasarkan isi permintaan. Karena itu WAF bisa menahan upaya penyisipan perintah basis data lewat kolom pencarian, sementara firewall jaringan meloloskannya tanpa keberatan.

ModSecurity dirilis di bawah lisensi Apache 2.0 dan sepenuhnya open source. Anda bisa memasangnya di server sendiri, membaca kode sumbernya, dan menulis aturan Anda sendiri tanpa membayar lisensi.

Nama lain yang sering Anda temui adalah mod_security dan ModSec. Ketiganya merujuk perangkat lunak yang sama. Penulisan mod_security mengikuti kebiasaan penamaan modul Apache.

Dari Modul Apache 2002 sampai Diasuh OWASP

Ivan Ristić merilis versi pertama ModSecurity pada November 2002 sebagai modul untuk Apache. Perangkat lunaknya kemudian berpindah tangan beberapa kali: dibeli Breach Security pada September 2006, lalu diakuisisi Trustwave pada Juni 2010 yang sekaligus melisensikannya ulang di bawah Apache 2.0.

Titik yang paling sering disalahpahami terjadi belakangan. Trustwave mengumumkan berakhirnya dukungan komersial mereka per 1 Juli 2024. Kabar itu menyebar sebagai "ModSecurity sudah end of life", padahal yang berakhir adalah kontrak dukungan berbayar Trustwave, bukan proyeknya. Pada 25 Januari 2024 proyek ini resmi berpindah ke OWASP Foundation dan berstatus Production Project.

Bukti bahwa proyeknya hidup ada di riwayat rilisnya. Versi 3.0.16 keluar pada 29 Juni 2026 dan versi 2.9.14 pada 2 Juli 2026. Kumpulan aturan resminya, OWASP Core Rule Set, merilis versi 4.29.0 pada 17 Agustus 2026. Ketiganya dirilis dalam rentang tiga bulan terakhir sebelum artikel ini ditulis.

Lima Fase Pemeriksaan ModSecurity dalam Satu Permintaan

Cara kerja ModSecurity paling mudah dipahami dari titik-titik pemeriksaannya. Satu permintaan tidak diperiksa sekali, melainkan lima kali pada titik berbeda. ModSecurity menyebutnya phase (fase pemrosesan), dan setiap aturan wajib menyatakan ia bekerja di fase mana.

Fase 1 dan 2 memeriksa header dan isi permintaan sebelum aplikasi, fase 3 dan 4 memeriksa respons, fase 5 mencatatnya.

1. Fase 1, header permintaan: dijalankan segera setelah header diterima, sebelum isi permintaan dibaca. Aturan yang memutus di sini menghemat sumber daya karena server tidak perlu membaca kiriman yang besar.
2. Fase 2, isi permintaan: memeriksa parameter formulir, data JSON, dan isi unggahan. Sebagian besar aturan pendeteksi serangan bekerja di fase ini.
3. Fase 3, header respons: memeriksa header yang akan dikirim server sebelum badan respons disusun.
4. Fase 4, isi respons: memeriksa isi halaman yang akan dikirim. Fase ini dipakai untuk menahan kebocoran, misalnya pesan galat basis data yang tanpa sengaja tercetak ke halaman.
5. Fase 5, pencatatan: dijalankan setelah transaksi selesai, khusus untuk menulis catatan audit.

Dua fase yang berhubungan dengan isi tidak selalu aktif. Direktif SecRequestBodyAccess menentukan apakah isi permintaan disangga dan diperiksa, dan SecResponseBodyAccess melakukan hal yang sama untuk respons. Kalau keduanya dimatikan, ModSecurity tetap berjalan tetapi hanya melihat header — dan sebagian besar serangan justru bersembunyi di isi permintaan.

Mesin ModSecurity dan Aturan CRS Itu Terpisah

Inilah bagian yang paling sering keliru dipahami: ModSecurity sendiri tidak tahu apa itu SQL injection. Ia hanya mesin pencocok pola. Seluruh pengetahuan tentang bentuk serangan berada di berkas aturan yang Anda muat. Memasang ModSecurity tanpa memuat satu pun aturan sama saja dengan memasang pintu tanpa penjaga.

Satu aturan ditulis dengan direktif SecRule dan tersusun dari empat unsur. Contoh sederhana yang menahan pola penyisipan perintah basis data:

SecRule ARGS "@rx union[\s/*]+select" \
    "id:1000001,\
     phase:2,\
     t:urlDecodeUni,t:lowercase,\
     deny,status:403,\
     log,msg:'Pola SQL injection terdeteksi'"

Baca aturan itu dari kiri. ARGS adalah variabel, yaitu bagian permintaan yang diperiksa — di sini seluruh parameter. @rx adalah operator, cara pencocokannya, yang memakai ekspresi reguler. Deretan t: adalah transformasi, yang menormalkan data supaya penyerang tidak lolos hanya dengan menyandikan hurufnya. Sisanya adalah aksi: tolak permintaan, kirim kode 403, dan tulis catatan. Setiap aturan wajib punya id unik, dan nomor itulah yang Anda pakai kalau aturannya perlu dinonaktifkan.

Menulis ratusan aturan sendiri jelas tidak masuk akal. Karena itu praktik yang lazim adalah memuat kumpulan aturan siap pakai. Tiga yang paling sering ditemui di server hosting adalah OWASP Core Rule Set, Comodo, dan aturan bawaan Imunify360. Dua yang pertama gratis, meski Comodo cenderung lebih galak; yang ketiga berbayar. Ketiganya menyasar keluarga serangan yang sama, di antaranya SQL injection dan XSS.

Memuat dua kumpulan aturan sekaligus, misalnya CRS dan Comodo bersamaan, umumnya melipatgandakan blokir keliru tanpa menambah perlindungan yang berarti. Pilih satu, lalu rawat.

Cara CRS Memutuskan Memblokir: Skor Anomali dan Paranoia Level

OWASP Core Rule Set tidak memblokir begitu satu aturan cocok. Sejak versi 3 ia memakai anomaly scoring (penilaian anomali). Setiap aturan yang cocok menambahkan angka ke skor anomali (anomaly score) permintaan itu. Skor total baru dibandingkan dengan sebuah ambang di akhir pemeriksaan.

Besaran angkanya ditetapkan di berkas konfigurasi resmi CRS berdasarkan tingkat keparahan:

Ambang bawaannya adalah 5 untuk permintaan masuk dan 4 untuk respons keluar. Sekarang perhatikan konsekuensi aritmetikanya: satu aturan berlabel CRITICAL menyumbang 5, dan 5 sudah menyentuh ambang. Artinya pada setelan bawaan, satu aturan CRITICAL saja sudah cukup untuk memblokir permintaan. Dokumentasi resmi CRS menyatakan hal ini secara terbuka. Inilah penjelasan sebenarnya mengapa blokir keliru terasa begitu mudah terjadi.

Lapisan kedua yang menentukan adalah paranoia level (tingkat kecurigaan), yaitu seberapa banyak aturan yang ikut dinilai. Nilainya 1 sampai 4:

1. Paranoia level 1: bawaan. Sebagian besar aturan inti aktif dan blokir keliru jarang terjadi. Cocok untuk server yang menampung banyak website berbeda.
2. Paranoia level 2: menambah pemeriksaan berbasis ekspresi reguler untuk SQL dan XSS. Sudah membawa sejumlah blokir keliru.
3. Paranoia level 3: menambah daftar kata kunci dan memperketat batas karakter khusus. Untuk pengelola yang sudah terbiasa menangani blokir keliru.
4. Paranoia level 4: paling ketat. Dokumentasi resminya menyebut level ini kemungkinan besar menghasilkan blokir keliru dalam jumlah sangat banyak.

Rekomendasi yang aman untuk memulai: pakai paranoia level 1, tetapi naikkan dulu ambang blokir ke angka besar, misalnya 100, supaya semua deteksi tercatat tanpa ada yang diblokir. Setelah dua minggu dan catatan Anda bersih dari deteksi yang keliru, turunkan bertahap ke 20, lalu 10, dan akhirnya 5. Perlu diperhatikan, menaikkan ambang secara permanen di atas 5 akan mematikan sebagian perlindungan penting, jadi angka besar itu hanya untuk masa penyesuaian.

Ambang blokir 5: satu aturan CRITICAL bernilai 5 langsung diblokir, dua aturan NOTICE berjumlah 4 dan tetap diteruskan.

ModSecurity v2 dan v3: Mana yang Sebenarnya Jalan di Server Anda

Ada dua garis versi yang sama-sama dirawat sampai hari ini, dan keduanya bukan sekadar beda nomor.

Versi 2 adalah modul Apache. Ia menyatu dengan Apache dan memakai fasilitas internal Apache untuk bekerja. Rilis terakhirnya, 2.9.14, keluar 2 Juli 2026. Perlu dicatat, rilis 2.9.13 secara resmi mencabut dukungan Nginx dari garis versi 2.

Versi 3 adalah penulisan ulang. Intinya dipisah menjadi pustaka mandiri bernama libmodsecurity yang tidak lagi bergantung pada Apache, ditambah connector (penghubung) terpisah untuk tiap web server. Konektor untuk Nginx dirilis sebagai proyek sendiri dan versi terakhirnya, 1.0.4, keluar pada 21 Mei 2025. Konsekuensinya, memasang ModSecurity v3 di Nginx berarti memasang dua komponen, bukan satu.

Perbedaan ini punya akibat sehari-hari yang nyata. Sebagian direktif versi 2 tidak tersedia di versi 3, sehingga panduan yang Anda temukan di internet belum tentu cocok dengan mesin yang benar-benar berjalan di server Anda. Pasangan versinya pun bisa mengikat: CRS 4.25.1 mensyaratkan libmodsecurity minimal 3.0.16, dan pada versi di bawahnya konfigurasi gagal dimuat sama sekali.

ModSecurity v2 menyatu sebagai modul di dalam Apache; v3 berupa pustaka libmodsecurity plus konektor Apache, Nginx, IIS.

ModSecurity di cPanel, LiteSpeed, dan Panel Hosting Lain

Bagi sebagian besar pemilik website di Indonesia, ModSecurity tidak pernah dipasang sendiri — ia sudah ada sejak hosting diaktifkan.

Di cPanel, ModSecurity dipasang lewat EasyApache sebagai paket bernama mod_security2. Nama itu menyimpan informasi penting: yang berjalan adalah versi 2, bukan versi 3 yang dokumentasinya paling banyak beredar. Kumpulan aturan CRS juga tidak otomatis ikut aktif; ia paket terpisah yang harus dipasang pemilik server.

Pembagian kewenangannya juga perlu Anda pahami sejak awal. Di antarmuka pengguna cPanel, yang tersedia hanyalah sakelar On dan Off per domain — tidak ada cara menonaktifkan satu aturan tertentu. Daftar aturan dan riwayat blokir berada di WHM, pada menu ModSecurity Tools, yang hanya bisa diakses pemilik server. Langkah praktis menyalakan dan mematikannya tersedia di panduan enable dan disable ModSecurity di cPanel.

Plesk menyediakan antarmuka yang lebih terbuka daripada cPanel: pengguna dapat memilih kumpulan aturan, mengatur mode pemblokiran, dan menonaktifkan aturan tertentu tanpa akses root. Panel berbasis LiteSpeed seperti CyberPanel juga membundel ModSecurity, tetapi pengaturannya berada di sisi web server.

Di server yang memakai LiteSpeed, Apache tidak berjalan sama sekali. LiteSpeed menjalankan mesin ModSecurity buatannya sendiri yang membaca berkas aturan ModSecurity yang sama, dan sejak versi 6.0 pemeriksaannya dialihkan ke kumpulan thread terpisah supaya tidak menahan pelayanan permintaan. Beberapa kemampuan sengaja tidak didukung, di antaranya skrip Lua dan pemrosesan XML, dan pencatatan audit hanya tersedia dalam mode serial.

Di cPanel pengguna hanya punya sakelar On dan Off per domain; daftar aturannya ada di WHM, Plesk, dan web server LiteSpeed.

Ketika ModSecurity Memblokir Pengunjung yang Sah

Blokir keliru, yang dalam istilah teknis disebut false positive, adalah alasan paling umum orang mencari tahu tentang ModSecurity. Gejalanya khas: artikel panjang gagal disimpan, editor WordPress menolak tulisan yang memuat potongan kode, formulir kontak menolak pesan tertentu, atau halaman admin mendadak tidak bisa dibuka.

Kode yang muncul biasanya 403 Forbidden. Sebagian server justru menampilkan 406 Not Acceptable, dan ini bukan pertanda masalah yang berbeda. Aksi deny pada ModSecurity membawa parameter status: yang bisa disetel bebas pengelola server. Sebagian penyedia memilih 406 supaya blokir WAF mudah dibedakan dari penolakan akses biasa.

Permintaan tanpa aturan cocok tampil normal; yang cocok dibalas 403 atau 406 dan menulis baris audit log berisi id 941100.

Urutan penanganan yang benar dimulai dari catatan, bukan dari sakelar:

1. Ambil nomor aturannya lebih dulu. Setiap blokir menulis satu baris ke log audit yang memuat id aturan, alamat yang diminta, dan potongan data yang memicunya. Tanpa nomor itu, penanganan berikutnya hanya tebakan.
2. Minta aturan tunggal itu dinonaktifkan. Kalau Anda memakai hosting bersama, kirimkan nomor aturan dan waktu kejadian ke penyedia. Kalau Anda pemilik server, nonaktifkan lewat WHM ModSecurity Tools, atau tambahkan pengecualian di konfigurasi.
3. Perbaiki kiriman yang memang mencurigakan. Sebagian blokir sebenarnya benar. Tulisan yang memuat contoh perintah basis data lebih aman disimpan sebagai lampiran ketimbang dipaksa lewat.
4. Matikan seluruh ModSecurity hanya sebagai langkah terakhir. Mematikannya per domain memang membuat website langsung bisa diakses, tetapi seluruh perlindungan ikut hilang. Perlakukan sebagai tindakan sementara untuk memastikan penyebabnya, lalu nyalakan kembali.

Kelemahan ModSecurity: Salah Tangkap, Beban, dan Celah

1. Blokir keliru adalah biaya tetap, bukan kecelakaan. Ini akibat langsung dari aritmetika yang dibahas sebelumnya: ambang 5 dengan satu aturan CRITICAL bernilai 5. Setiap pemasangan CRS pada aplikasi yang menerima masukan rumit hampir pasti membutuhkan penyesuaian. Anggap penyesuaian itu bagian dari pekerjaan, bukan tanda ada yang rusak.
2. Biaya performanya nyata dan tidak kecil. Sebuah pengujian yang dilaporkan di milis proyek CRS memakai h2load dengan 5.000 permintaan dan 10 koneksi. Mengaktifkan ModSecurity tanpa memuat aturan CRS praktis tidak berpengaruh. Namun dengan CRS aktif, kapasitas turun dari sekitar 3.800 permintaan per detik menjadi 1.400 sampai 2.400, atau sekitar 37 sampai 63 persen. Waktu tanggap satu permintaan naik sekitar 10,5 persen, yaitu 5,81 milidetik. Angka ini berasal dari satu pengujian pada satu mesin, jadi perlakukan sebagai gambaran urutan besaran.
3. Mesin pengamannya sendiri bisa berlubang. Antara Februari 2025 dan Juni 2026 tercatat sembilan pengumuman kerentanan pada ModSecurity. Di antaranya ada cacat pada pengurai kiriman formulir yang memungkinkan pemeriksaan dilewati, dan beberapa cacat yang bisa dipakai membuat layanan berhenti. Kesimpulannya lugas: WAF yang tidak pernah diperbarui menambah permukaan serangan, bukan menguranginya.
4. Ada batas ukuran yang diam-diam memutus pemeriksaan. Konfigurasi bawaan resminya membatasi isi permintaan pada 12,5 MB dan isi respons yang dipindai pada 512 KB. Untuk permintaan tanpa unggahan berkas, batasnya jauh lebih kecil, yaitu 128 KB. Karena batas ini, unggahan besar dan halaman panjang bisa lolos tanpa diperiksa.

Satu hal terakhir yang perlu Anda periksa sendiri. Berkas konfigurasi contoh yang disertakan proyek resminya menyetel SecRuleEngine DetectionOnly, yang artinya seluruh aturan dijalankan dan dicatat tetapi tidak satu pun permintaan diblokir. Pemasangan yang menyalin berkas contoh apa adanya akan berjalan sebagai pemantau, bukan penjaga. Untuk benar-benar memblokir, nilainya harus diubah menjadi On.

ModSecurity Dibandingkan Alternatifnya

Dua catatan yang perlu diluruskan. Pertama, WAF cloud dan ModSecurity bekerja di titik yang berbeda, jadi keduanya bisa dipakai bersamaan. CDN Cloudflare menyaring di tepi jaringan, sementara ModSecurity tetap menjaga kalau ada yang mengakses alamat IP server secara langsung. Kedua, Coraza bukan pesaing dengan bahasa aturan berbeda. Ia proyek OWASP yang ditulis ulang dalam bahasa Go dan menyebut dirinya pengganti langsung ModSecurity. Berkas aturannya sama, sehingga CRS yang sudah Anda setel bisa dipindahkan.

Kapan Anda Perlu Mengurus ModSecurity Sendiri

Jawabannya berbeda menurut posisi Anda.

Pengguna hosting bersama sebaiknya membiarkannya aktif. Anda tidak menanggung biaya performanya secara langsung, dan aturannya sudah dirawat penyedia. Saat terkena blokir, catat waktu kejadian dan alamat halamannya, lalu minta penyedia menonaktifkan aturan yang bersangkutan.

Pengelola VPS dengan satu sampai dua website sebaiknya memasang versi 3 dengan CRS pada paranoia level 1, memakai tangga ambang yang dijelaskan sebelumnya. Kalau website Anda menerima masukan rumit seperti editor artikel atau unggahan berkas, siapkan satu sampai dua jam untuk menyusun pengecualian.

Pengelola server dengan banyak klien perlu menghitung ulang. Menyesuaikan CRS untuk puluhan aplikasi berbeda memakan waktu yang jauh lebih mahal daripada lisensi aturan komersial. Pada titik itu, aturan berbayar yang diperbarui vendor lebih masuk akal.

Pertanyaan yang Sering Diajukan

Apa itu ModSecurity di cPanel?

Mesin yang sama, dipasang lewat EasyApache sebagai paket mod_security2. Artinya yang berjalan adalah ModSecurity versi 2. Di menu cPanel Anda hanya melihat sakelar On dan Off per domain; daftar aturan dan riwayat blokirnya berada di WHM, yang hanya bisa diakses pemilik server.

Apakah ModSecurity gratis?

Ya. Mesinnya dirilis di bawah lisensi Apache 2.0 dan bebas dipakai, termasuk untuk keperluan komersial. Yang bisa berbayar adalah sebagian kumpulan aturannya. OWASP Core Rule Set gratis, sementara aturan dari vendor seperti Imunify360 dijual dengan lisensi per server.

Apakah ModSecurity sudah tidak dikembangkan lagi?

Masih dikembangkan. Yang berakhir pada 1 Juli 2024 adalah dukungan komersial berbayar dari Trustwave, bukan proyeknya. Sejak 25 Januari 2024 proyek ini dikelola OWASP Foundation, dan rilis terbarunya adalah versi 3.0.16 pada 29 Juni 2026 serta versi 2.9.14 pada 2 Juli 2026.

Apakah ModSecurity cukup untuk mengamankan website?

Tidak, kalau berdiri sendiri. Ia menahan pola serangan yang dikenali aturannya, tetapi tidak menambal kerentanan pada aplikasi Anda. Pembaruan tema, plugin, dan kata sandi yang kuat tetap tak tergantikan.

Apa bedanya ModSecurity dengan OWASP CRS?

ModSecurity adalah mesinnya, CRS adalah aturannya. Mesin tanpa aturan tidak menyaring apa pun. Keduanya proyek terpisah dengan penomoran versi sendiri-sendiri.

Kenapa website saya kena 403 setelah artikel disimpan?

Kemungkinan besar isi artikel Anda memuat pola yang menyerupai serangan, misalnya potongan perintah basis data atau tag skrip. Ambil nomor aturannya dari catatan audit di sisi penyedia, lalu minta aturan itu saja yang dinonaktifkan untuk domain Anda.

Bolehkah ModSecurity dimatikan?

Boleh, tetapi sebagai langkah sementara untuk memastikan penyebab suatu blokir. Mematikannya permanen menghapus seluruh penyaringan di tingkat aplikasi. Setelah aturan yang bermasalah dinonaktifkan, nyalakan kembali.

Kesimpulan

ModSecurity adalah mesin pemeriksa isi permintaan HTTP, dan hasilnya ditentukan tiga keputusan. Mesin mana yang berjalan, versi 2 yang menyatu dengan Apache atau versi 3 yang berupa pustaka dan konektor. Aturan siapa yang dimuat. Terakhir, seberapa galak setelannya lewat paranoia level dan ambang skor anomali. Menyalakannya saja tidak cukup, karena berkas konfigurasi bawaannya justru hanya memantau tanpa memblokir.

Kalau Anda memakai hosting bersama, biarkan aktif dan tangani blokir keliru lewat nomor aturannya, bukan dengan mematikan seluruhnya. Kalau Anda mengelola server sendiri, mulai dari paranoia level 1 dengan ambang longgar, lalu turunkan setelah catatan bersih. Perlakukan pembaruan versinya sebagai keharusan, karena mesin pengaman yang usang justru menambah risiko.

Semoga artikel ini membantu.