CasWAF vs ModSecurity
ModSecurity is not a product you install and browse. It is a WAF engine, libmodsecurity, that a web server loads: you still pick the server, write or import the rules, manage certificates, and find something to read when a request is blocked. CasWAF is the other shape. One program is the proxy, the firewall and the console, and it runs ModSecurity’s own SecLang rules on the Coraza engine.
At a glance
| CasWAF | ModSecurity | |
|---|---|---|
| What it is | Reverse proxy, firewall and console in one program | A WAF engine loaded by a web server |
| License | Apache-2.0 | Apache-2.0 |
| Written in | Go, rules run on Coraza | C++; connectors for Apache, Nginx and IIS |
| Where rules run | Inside the gateway, on Coraza | Inside the web server, through a connector |
| Sites and certificates | In the console, with Let’s Encrypt per domain | Left to the web server and to Certbot or similar |
| Console and records | Built in, with a dashboard and alerts | None; logs go wherever the server sends them |
| Single sign-on | Casdoor, for the console and for protected sites | None |
Where CasWAF is different
The parts around the engine are included
Sites, redirects, certificates, request records, a dashboard and alerts are in the same program. With ModSecurity you assemble those from the web server, Certbot, log shipping and something to read the logs.
Same rule language, one place to put it
SecRule lines go into a rule in the console exactly as they would into a ModSecurity configuration, and Coraza runs them. You keep the rules you already know and skip the server configuration around them.
Several nodes, one database
Every gateway node reads the same sites, certificates and rules, so a rule added on one machine applies on all of them. With ModSecurity each server’s configuration is its own.
Sign-in without extra work
The console uses Casdoor for MFA, LDAP, SAML and social logins, and the same login can protect any site. ModSecurity has no notion of a user.
Windows is a first-class target
CasWAF runs as a single binary on Windows as well as Linux. ModSecurity on Windows means the IIS connector, which is a much narrower path.
Where ModSecurity is ahead
It defines the language
ModSecurity v3, and the v2 Apache module before it, is where SecLang comes from. New directives and operators appear there first, and Coraza implements the language rather than defining it.
Every directive, eventually
Coraza covers the directives and operators that real rulesets use, which is not the same as every last one. A large, unusual ModSecurity configuration may need testing before it behaves identically.
It embeds in Apache and IIS
The v2 module runs inside Apache, and there is an IIS connector. CasWAF is always a proxy in front of the application, which is a different deployment.
Two decades of scrutiny
ModSecurity has been audited, deployed and broken for far longer, and the OWASP Core Rule Set is built and tuned for it. That history is worth something on its own.
Which to pick
- You already run Nginx or Apache and only want the engine: ModSecurity with the Core Rule Set.
- You want the proxy, certificates, rules, records and console in one place: CasWAF.
- You have a ModSecurity ruleset you trust: CasWAF runs SecLang on Coraza, but test the ruleset first.
- You need the firewall inside Apache or IIS itself: ModSecurity.
Related pages
Try CasWAF on one machine
Go, Node.js and MySQL, a Casdoor application for the console, and the gateway starts on port 17000.