ModSecurity: the engine the Core Rule Set grew up with

Sources: the OWASP project page and the project README. Release numbers move; the repository is the place to check the current one.

An engine without rules inspects requests and decides nothing. Rules without an engine are text files. Most confusion about ModSecurity comes from treating the two as one product.

• The engine. ModSecurity parses each request and response, keeps state across the phases of a transaction, evaluates rules written in its rule language, and carries out the action a rule asks for.
• The rules. The Core Rule Set is the widely used set of generic attack-detection rules written for it. CRS decides what counts as suspicious and how many points each match adds; the engine applies that decision.

A deployment's behaviour therefore depends on both: which engine version, and which rule set version with which settings.

ModSecurity splits each transaction into five phases, and every rule names the phase it runs in, as the reference manual describes: request headers, request body, response headers, response body, and logging.

The phase decides what a rule can see. A rule in the request headers phase can refuse a request before its body is read; a rule that inspects form fields has to wait for the body; rules on the response can catch an error page leaking details, at the cost of buffering what the application sends back. The logging phase acts on nothing and records what happened.

The SecRuleEngine directive takes three values: On enforces, Off disables, and DetectionOnly evaluates every rule and logs what it would have done without blocking anything.

Detection-only is how a new rule set or a stricter configuration is usually introduced: run it against real traffic, read the log, write exceptions for the false positives, then switch to enforcing. The same practice under a different name is described on monitor mode.

The project has two lines, and they are built differently.

• Version 2. The original Apache module. The README says it is still under maintenance.
• Version 3, libModSecurity. A complete rewrite as a platform-independent library with no Apache dependencies. Web servers reach it through separate connectors, such as the one for Nginx.

Which line a guide assumes matters when copying configuration from it, because the way the engine is loaded and connected to the server differs between them.

Trustwave maintained ModSecurity for years and ended its sponsorship on 1 July 2024. Custody of the project moved to OWASP in 2024, and the OWASP project page describes the new leaders as working on a road map.

For anyone running the engine, the practical consequence is where to look: the repository now sits under the OWASP ModSecurity organisation, and security reports go to OWASP.

Coraza is an OWASP web application firewall engine written in Go. It describes itself as fully compatible with the Core Rule Set and as a drop-in replacement for ModSecurity, and it can run as a library, a sidecar or a proxy.

The Core Rule Set project names both engines. The choice between them is mostly about the surrounding stack: a Go service or proxy can embed Coraza directly, while an existing Apache or Nginx deployment may already have ModSecurity in place.