coraza.conf-recommended

# -- Rule engine initialization ----------------------------------------------

# Enable Coraza, attaching it to every transaction.
# Possible values: On, Off, DetectionOnly.
# DetectionOnly minimises the chances of post-installation disruption by
# only logging matched rules without performing disruptive actions.
#
SecRuleEngine DetectionOnly


# -- Default actions ---------------------------------------------------------

# Configures all rules to log by default in both the error and audit logs.
# Rule-specific actions will override these defaults.
# This allows CRS correlation rules (e.g. 980170 in phase 5) to emit error logs,
# and matches the default ModSecurity actionset.
# These defaults can be adjusted to disable logging (e.g. to avoid logging sensitive
# response data in phases 3–5) via the nolog and noauditlog actions, commenting out
# or removing the lines below.
# Note:
# - phase 1 and phase 2 defaults are commented out because they are typically already provided in a CRS setup via the crs-setup.conf file.
#  - phase 2 default actions are hardcoded. This phase requires an explicit override to tweak it.
#
#SecDefaultAction "phase:1,log,auditlog,pass"
#SecDefaultAction "phase:2,log,auditlog,pass"
SecDefaultAction "phase:3,log,auditlog,pass"
SecDefaultAction "phase:4,log,auditlog,pass"
SecDefaultAction "phase:5,log,auditlog,pass"


# -- Performance optimizations -----------------------------------------------

# Toggles literal pre-filtering for the @rx operator.
# When enabled, Coraza analyses each regex pattern at rule-load time and
# builds pre-checks that will be executed before the full regex evaluation,
# allowing to skip unnecessary regex evaluations.
# Warning: Experimental feature.
#
SecRxPreFilter Off

# -- Request body handling ---------------------------------------------------

# Allows Coraza to access request bodies. Without this, Coraza
# can not see POST parameters, which opens a large security
# hole for attackers to exploit.
#
SecRequestBodyAccess On

# Enable XML request body parser.
# Initiate XML Processor in case of xml content-type
#
SecRule REQUEST_HEADERS:Content-Type "^(?:application(?:/soap\+|/)|text/)xml" \
     "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"

# Enable JSON request body parser.
# Initiate JSON Processor in case of JSON content-type; change accordingly
# if the application does not use 'application/json'
#
SecRule REQUEST_HEADERS:Content-Type "^application/json" \
     "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"

# Enable JSON request body parser for more subtypes.
# Adapt this rule to engage the JSON Processor for "+json" subtypes
#
SecRule REQUEST_HEADERS:Content-Type "^application/[a-z0-9.-]+[+]json" \
     "id:'200006',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"

# Configures the maximum JSON recursion depth limit Coraza will accept.
SecRequestBodyJsonDepthLimit 1024

# Maximum request body size (bytes) Coraza will accept for buffering. When
# supporting file uploads, this value has to be as large as the largest
# file that should be accepted.
SecRequestBodyLimit 13107200

# Maximum request body size (bytes) that Coraza will store in memory. If the body
# size exceeds this value, it will be saved to a temporary file on disk.
SecRequestBodyInMemoryLimit 131072

# Maximum request body size (bytes) Coraza will accept for buffering, with files excluded.
# This value should be kept as low as practical.
# Note: SecRequestBodyNoFilesLimit is currently NOT supported by Coraza
# SecRequestBodyNoFilesLimit 131072

# Configures the action to take if the request body size is above the configured limit.
# Possible values: Reject, ProcessPartial.
# When SecRuleEngine is set to DetectionOnly, this directive is set to ProcessPartial
# to minimize disruptions when initially deploying Coraza.
# Warning: Setting this directive to ProcessPartial introduces a potential bypass
# risk, as attackers could prepend junk data equal to or greater than the inspected body size.
#
SecRequestBodyLimitAction Reject

# Verifies that the request body was correctly processed.
# As a rule of thumb, when failing to process a request body
# the request should be rejected (when deployed in blocking mode)
# or a high-severity alert logged (when deployed in detection-only mode).
#
SecRule REQBODY_ERROR "!@eq 0" \
    "id:'200002', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"

# Enforces strict validation by default for what is accepted in the
# multipart/form-data request body. If the rule below proves to be
# too strict consider changing it to detection-only.
# Do NOT remove it, as it will catch many evasion attempts.
#
SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
    "id:'200003',phase:2,t:none,log,deny,status:400, \
    msg:'Multipart request body failed strict validation.'"


# -- Response body handling --------------------------------------------------

# Allows Coraza to access response bodies. Without this, Coraza
# can not see response content looking for errors and data leakage issues.
#
# Note that enabling this directive increases both
# memory consumption and response latency.
#
SecResponseBodyAccess On

# Configures response MIME types that Coraza will buffer and inspect. The
# configuration below should be adjusted to catch documents but avoid static
# files (e.g., images and archives).
#
SecResponseBodyMimeType text/plain text/html text/xml

# Maximum response body size (bytes) that Coraza will store in memory.
# This default equals to 512 KB.
# 
SecResponseBodyLimit 524288

# Configures the action to take if the response body size is above the configured limit.
# Possible values: Reject, ProcessPartial.
# When SecRuleEngine is set to DetectionOnly, this directive is set to ProcessPartial
# to minimize disruptions when initially deploying Coraza.
# ProcessPartial allows Coraza to inspect the portion of the response body that is within
# the configured limit, while letting the rest through. This approach may be less secure,
# but helps prevent legitimate pages from being blocked.
#
SecResponseBodyLimitAction ProcessPartial


# -- Filesystem configuration ------------------------------------------------

# The location where Coraza will keep its persistent data. This default setting
# is chosen due to all systems have /tmp available however, it
# too should be updated to a place that other users can't access.
#
SecDataDir /tmp/


# -- File uploads handling configuration -------------------------------------

# The location where Coraza stores intercepted uploaded files. This
# location must be private to Coraza. Other users on the server
# should not be able to access the files.
#
#SecUploadDir /opt/coraza/var/upload/

# Controls whether intercepted uploaded files will be kept after
# transaction is processed. Possible values: On, Off, RelevantOnly.
# RelevantOnly will keep files only when a matching rule is logged (rules with 'nolog' do not qualify).
#
#SecUploadKeepFiles RelevantOnly

# Uploaded files are by default created with permissions that do not allow
# any other user to access them. This may need to be relaxed to
# interface Coraza with an external program (e.g., an anti-virus).
# Note: SecUploadFileMode is currently NOT supported by Coraza
#
#SecUploadFileMode 0600


# -- Debug log configuration -------------------------------------------------

# Default debug log path
# Debug levels:
# 0:   No logging (least verbose)
# 1:   Error
# 2:   Warn
# 3:   Info
# 4-8: Debug
# 9:   Trace (most verbose)
#
#SecDebugLog /opt/coraza/var/log/debug.log
#SecDebugLogLevel 3


# -- Audit log configuration -------------------------------------------------

# Configure the audit logging engine, which logs transaction details.
# Possible values: On, Off, RelevantOnly
# RelevantOnly logs the transactions marked by a matched rule with auditlog,
# or relevant transaction based on response status (see SecAuditLogRelevantStatus).
#
SecAuditEngine RelevantOnly

# When SecAuditEngine is set to RelevantOnly, define which response
# status codes are considered relevant.
# The following regex matches status codes 400-419 and 500-519.
#
SecAuditLogRelevantStatus "^(?:(5|4)(0|1)[0-9])$"

# Define which parts of the transaction are recorded in the audit log.
#
SecAuditLogParts ABIJDEFHZ

# Configure the audit logging mechanism. Possible values:
# Serial (single file), Concurrent (one file per transaction),
# HTTPS (send to a URL), Syslog (send to a syslog server).
#
SecAuditLogType Serial

# Path to the audit log file (serial format) or the index file
# (concurrent format). If not specified, no audit logs will be emitted.
#
#SecAuditLog /opt/coraza/var/log/audit.log

# The format used to write the audit log.
# Possible values: JSON, JsonLegacy, Native, OCSF.
#
SecAuditLogFormat Native

# Directory for concurrent audit logging, where individual transaction logs are stored.
#
#SecAuditLogStorageDir /opt/coraza/var/audit/

# The following settings are not supported by Coraza
# SecCookieFormat 0
# SecArgumentSeparator &
# SecRule MULTIPART_UNMATCHED_BOUNDARY "@eq 1" \
#    "id:'200004',phase:2,t:none,log,deny,msg:'Multipart parser detected a possible unmatched boundary.'"
# SecRule TX:/^COR_/ "!@streq 0" \
#       "id:'200005',phase:2,t:none,deny,msg:'Coraza internal error flagged: %{MATCHED_VAR_NAME}'"