Core ModSecurity configuration

Reviewed by Atomicorp WAF Research Team

Engine mode

SecRuleEngine controls whether rules run and whether disruptive actions can execute:

SecRuleEngine DetectionOnly

• On evaluates rules and permits disruptive actions such as blocking.
• DetectionOnly evaluates and logs rules without executing disruptive actions.
• Off disables rule processing.

Use DetectionOnly for the first observation period on an existing application, verify audit events and tuning, and then change to On.

Request bodies

SecRequestBodyAccess On
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
SecRequestBodyLimitAction Reject

Request-body access is required to inspect common POST, JSON, XML, and upload traffic. Limits protect server resources. Set them high enough for legitimate application requests and deliberately handle over-limit traffic.

Response bodies

SecResponseBodyAccess On
SecResponseBodyMimeType text/plain text/html text/xml
SecResponseBodyLimit 524288
SecResponseBodyLimitAction ProcessPartial

Response inspection enables data-loss and malicious-output policies but costs memory and CPU. Restrict it to MIME types and sizes your policy needs.

Data and temporary directories

SecTmpDir and SecDataDir must exist and be writable by the web-server account. Keep temporary and persistent data outside publicly served directories.

Safe rollout

1. Validate configuration syntax before reloading the web server.
2. Start in DetectionOnly.
3. Confirm audit logging and inspect representative application traffic.
4. Fix narrow application-specific false positives without disabling broad protection.
5. Enable the engine and monitor blocks.

Upstream ModSecurity reference manuals are authoritative for directive availability. The upstream project notes that parts of its wiki are under revision, so verify version-specific behavior.