Directives

Include#

Description: Include and evaluate a file or file pattern.

Syntax: Include [PATH_TO_CONF_FILES]

Include loads a file or a list of files from the filesystem using golang Glob syntax.

Example:

Include /path/coreruleset/rules/*.conf

Quoting Glob documentation:

The syntax of patterns is the same as in Match. The pattern may describe hierarchical names such as /usr/*/bin/ed (assuming the Separator is ‘/’). Glob ignores file system errors such as I/O errors reading directories. The only possible returned error is ErrBadPattern, when pattern is malformed.

SecAction#

Description: Unconditionally processes the action list it receives as the first and only parameter.

Syntax: SecAction "action1,action2,action3,..."

This directive is commonly used to set variables and initialize persistent collections using the initcol action. The syntax of the parameter is identical to that of the third parameter of SecRule.

Example:

SecAction "id:100,nolog,phase:1,initcol:RESOURCE=%{REQUEST_FILENAME}"

SecArgumentsLimit#

Description: Configures the maximum number of arguments Coraza keeps from each source.

Syntax: SecArgumentsLimit [LIMIT]

Default: 1000

The query string (ARGS_GET), the path (ARGS_PATH), and urlencoded or JSON request bodies (ARGS_POST) are each counted separately; JSON response bodies (RESPONSE_ARGS) use the same limit. Arguments beyond the limit are dropped and ARGUMENTS_LIMIT_REACHED is set to 1, so a rule can reject the request (see rules 200004 and 200005 in coraza.conf-recommended). The value must be greater than 0.

Example:

SecArgumentsLimit 1000

SecAuditEngine#

Description: Configures the audit logging engine.

Syntax: SecAuditEngine RelevantOnly

Default: Off

The SecAuditEngine directive is used to configure the audit engine, which logs complete transactions.

The possible values for the audit log engine are as follows:

• On: log all transactions
• Off: do not log any transactions
• RelevantOnly: only the log transactions that have triggered a warning or an error, or have a status code that is considered to be relevant (as determined by the SecAuditLogRelevantStatus directive)

Note: If you need to change the audit log engine configuration on a per-transaction basis (e.g., in response to some transaction data), use the ctl action.

The following example demonstrates how SecAuditEngine is used:

SecAuditEngine RelevantOnly
SecAuditLog logs/audit/audit.log
SecAuditLogParts ABCFHZ
SecAuditLogType concurrent
SecAuditLogStorageDir logs/audit
SecAuditLogRelevantStatus ^(?:5|4(?:0[0-35-9]|[1-9][0-9]))

SecAuditLog#

Description: Defines the path to the main audit log file (serial logging format) or the concurrent logging index file (concurrent logging format).

Syntax: SecAuditLog [ABSOLUTE_PATH_TO_LOG_FILE]

Example:

SecAuditLog "/path/to/audit.log"

Note: This audit log file is opened on startup when the server typically still runs as root. You should not allow non-root users to have write privileges for this file or for the directory.

SecAuditLogDirMode#

Description: Configures the mode (permissions) of any directories created for the concurrent audit logs, using an octal mode value as parameter (as used in chmod).

Syntax: SecAuditLogDirMode octal_mode|"default"

Default: 0600

The default mode for new audit log directories (0600) only grants read/write access to the owner.

Example:

SecAuditLogDirMode 02750

SecAuditLogFileMode#

Description: Configures the mode (permissions) of any files created for concurrent audit logs using an octal mode (as used in chmod). See SecAuditLogDirMode for controlling the mode of created audit log directories.

Syntax: SecAuditLogFileMode octal_mode|"default"

Default: 0600

Example:

SecAuditLogFileMode 00640

SecAuditLogFormat#

Description: Select the output format of the AuditLogs. The format can be the native AuditLogs format, JSON, or OCSF (Open CyberSecurity Schema Framework).

Syntax: SecAuditLogFormat JSON|JsonLegacy|Native|OCSF

Default: Native

Example:

SecAuditLogFormat JSON

SecAuditLogParts#

Description: Defines which parts of each transaction are going to be recorded in the audit log. Each part is assigned a single letter; when a letter appears in the list then the equivalent part will be recorded. See below for the list of all parts.

Syntax: SecAuditLogParts [PARTLETTERS]

Default: ABCFHZ

Example:

SecAuditLogParts ABCFHZ

Available audit log parts:

• A: Audit log header (mandatory).
• B: Request headers.
• C: Request body (present only if the request body exists and Coraza is configured to intercept it. This would require SecRequestBodyAccess to be set to on).
• D: Reserved for intermediary response headers; not implemented yet.
• E: Intermediary response body (present only if Coraza is configured to intercept response bodies, and if the audit log engine is configured to record it. Intercepting response bodies requires SecResponseBodyAccess to be enabled). Intermediary response body is the same as the actual response body unless Coraza intercepts the intermediary response body, in which case the actual response body will contain the error message.
• F: Final response headers.
• G: Reserved for the actual response body; not implemented yet.
• H: Audit log trailer.
• I: This part is a replacement for part C. It will log the same data as C in all cases except when multipart/form-data encoding in used. In this case, it will log a fake application/x-www-form-urlencoded body that contains the information about parameters but not about the files. This is handy if you don’t want to have (often large) files stored in your audit logs; not implemented yet.
• J: This part contains information about the files uploaded using multipart/form-data encoding. Available from Coraza v3.7.0.
• K: This part contains a full list of every rule that matched (one per line) in the order they were matched. The rules are fully qualified and will thus show inherited actions and default operators.
• Z: Final boundary, signifies the end of the entry (mandatory).

SecAuditLogRelevantStatus#

Description: Configures which response status code is to be considered relevant for the purpose of audit logging.

Syntax: SecAuditLogRelevantStatus [REGEX]

The main purpose of this directive is to allow you to configure audit logging for only the transactions that have the status code that matches the supplied regular expression.

Example:

SecAuditLogRelevantStatus "^(?:5|40[1235])"

This example would log all 5xx and 4xx level status codes, except for 404s. Although you could achieve the same effect with a rule in phase 5, SecAuditLogRelevantStatus is sometimes better, because it continues to work even when SecRuleEngine is disabled.

Note: Must have SecAuditEngine set to RelevantOnly. Additionally, the auditlog action is present by default in rules, this will make the engine bypass the SecAuditLogRelevantStatus and send rule matches to the audit log regardless of status. You must specify noauditlog in the rules manually or set it in SecDefaultAction.

SecAuditLogStorageDir#

Description: Configures the directory where concurrent audit log entries are stored.

Syntax: SecAuditLogStorageDir [PATH_TO_LOG_DIR]

This directive is required only when concurrent audit logging is used. Ensure that you specify a file system location with adequate disk space.

Example:

SecAuditLogStorageDir /tmp/auditlogs/

SecAuditLogType#

Description: Configures the type of audit logging mechanism to be used.

Syntax: SecAuditLogType Serial|Concurrent|HTTPS|Syslog

The possible values are:

• Serial : Audit log entries will be stored in a single file, specified by SecAuditLog. This is convenient for casual use, but it can slow down the server, because only one audit log entry can be written to the file at any one time.
• Concurrent : One file per transaction is used for audit logging. This approach is more scalable when heavy logging is required (multiple transactions can be recorded in parallel)
• HTTPS : Audit log entries will be sent to the target URL, specified by SecAuditLog.
• Syslog : Audit log entries will be sent to the syslog server, specified by SecAuditLog in one of formats: “ADDRESS:PORT” (TCP), “udp://ADDRESS:PORT”, or “unixgram:///var/run/syslog”.

Example:

SecAuditLogType Serial

SecCollectionTimeout#

Description: Would set how long persistent collection records are retained, in seconds.

Syntax: SecCollectionTimeout [SECONDS]

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecCollectionTimeout 600

SecComponentSignature#

Description: Appends component signature to the Coraza signature.

Syntax: SecComponentSignature "COMPONENT_NAME/X.Y.Z (COMMENT)"

Appends component signature to the Coraza signature.

Example:

SecComponentSignature "OWASP_CRS/4.18.0"

SecConnEngine#

Description: Would enable per-connection tracking.

Syntax: SecConnEngine On|Off|DetectOnly

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecConnEngine Off

SecConnReadStateLimit#

Description: Would limit the number of connections in the read state per IP address.

Syntax: SecConnReadStateLimit [NUMBER]

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecConnReadStateLimit 50

SecConnWriteStateLimit#

Description: Would limit the number of connections in the write state per IP address.

Syntax: SecConnWriteStateLimit [NUMBER]

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecConnWriteStateLimit 50

SecDataDir#

Description: Sets the directory where persistent collection data is stored.

Syntax: SecDataDir /path/to/dir

Example:

SecDataDir /tmp/coraza/data

SecDataset#

Description: Defines a named, inline dataset that operators such as @pmFromDataset and @ipMatchFromDataset can reference. The records are given as a backtick-quoted block, one per line.

Syntax: SecDataset NAME `\n...\n`

Example:

SecDataset test `
123
456
`

SecDebugLog#

Description: Path to the Coraza debug log file.

Syntax: SecDebugLog [ABSOLUTE_PATH_TO_DEBUG_LOG]

Logs will be written to this file. Make sure the process user has write access to the directory.

Example:

SecDebugLog /var/log/coraza/debug.log

SecDebugLogLevel#

Description: Configures the verboseness of the debug log data.

Syntax: SecDebugLogLevel [LOG_LEVEL]

Default: 3

Depending on the implementation, errors ranging from 1 to 2 might be directly logged to the connector error log. For example, level 1 (error) logs will be written to caddy server error logs. The possible values for the debug log level are:

• 0: No logging (least verbose)
• 1: Error
• 2: Warn
• 3: Info
• 4-8: Debug
• 9: Trace (most verbose)

Levels outside the 0-9 range will default to level 3 (Info)

Example:

SecDebugLogLevel 3

SecDefaultAction#

Description: Defines the default list of actions, which will be inherited by the rules in the same configuration context.

Syntax: SecDefaultAction "phase:2,log,auditlog,deny,status:403,tag:'SLA 24/7'"

Default: phase:2,log,auditlog,pass

Every rule following a previous SecDefaultAction directive in the same configuration context will inherit its settings unless more specific actions are used.

Rulesets like OWASP Core Ruleset uses this to define operation modes:

• You can set the default disruptive action to block for phases 1 and 2 and you can force a phase 3 rule to be disrupted if the thread score is high.
• You can set the default disruptive action to deny and each risky rule will interrupt the connection.

Important: Every SecDefaultAction directive must specify a disruptive action and a processing phase and cannot contain metadata actions.

Example:

SecDefaultAction "phase:2,log,auditlog,pass"

SecGsbLookupDb#

Description: Would set the path to the Google Safe Browsing database used by @gsbLookup.

Syntax: SecGsbLookupDb /path/to/db

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecGsbLookupDb /path/to/GsbMalware.dat

SecHTTPBlKey#

Description: Would set the API key used by the @rbl operator for Project Honey Pot lookups.

Syntax: SecHttpBlKey "KEY"

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecHttpBlKey "my_api_key"

SecHashEngine#

Description: Would enable the response hashing engine used to sign links and form fields.

Syntax: SecHashEngine On|Off

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecHashEngine On

SecHashKey#

Description: Would set the key used by the response hashing engine.

Syntax: SecHashKey [KEY] [KeyOnly|SessionID|RemoteIP]

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecHashKey "my_secret_key" KeyOnly

SecHashMethodPm#

Description: Would select, by phrase match, which response elements the hashing engine signs.

Syntax: SecHashMethodPm TYPE PHRASES

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecHashMethodPm HashHref "example.com"

SecHashMethodRx#

Description: Would select, by regular expression, which response elements the hashing engine signs.

Syntax: SecHashMethodRx TYPE REGEX

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecHashMethodRx HashHref "^/admin"

SecHashParam#

Description: Would set the parameter name carrying the hash added by the response hashing engine.

Syntax: SecHashParam "NAME"

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect.

Example:

SecHashParam "hmac"

SecIgnoreRuleCompilationErrors#

Description: Continues loading a rule set when a rule fails to compile, instead of aborting. Enabling it logs a warning: a faulty rule that does not load cannot protect anything, so this is a migration aid rather than a setting to run with.

Syntax: SecIgnoreRuleCompilationErrors On|Off

Example:

SecIgnoreRuleCompilationErrors Off

SecMarker#

Description: Adds a fixed rule marker that can be used as a target in a skipAfter action. A SecMarker directive essentially creates a rule that does nothing and whose only purpose is to carry the given ID.

Syntax: SecMarker [ID|TEXT]

The value can be either a number or a text string. The SecMarker directive is available to allow you to choose the best way to implement a skip-over. Here is an example used from the Core Rule Set:

SecMarker BEGIN_HOST_CHECK

	SecRule &REQUEST_HEADERS:Host "@eq 0" \
		"id:'960008',skipAfter:END_HOST_CHECK,phase:2,rev:'2.1.1',\
		t:none,block,msg:'Request Missing a Host Header',\
		tag:'PROTOCOL_VIOLATION/MISSING_HEADER_HOST',tag:'WASCTC/WASC-21',\
		tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',\
		severity:'5',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},\
		setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},\
		setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"
	SecRule REQUEST_HEADERS:Host "^$" \
		"id:'960009',phase:2,rev:'2.1.1',t:none,block,msg:'Request Missing a Host Header',\
		tag:'PROTOCOL_VIOLATION/MISSING_HEADER_HOST',tag:'WASCTC/WASC-21',\
		tag:'OWASP_TOP_10/A7',tag:'PCI/6.5.10',severity:'5',\
		setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},\
		setvar:tx.protocol_violation_score=+%{tx.notice_anomaly_score},\
		setvar:tx.%{rule.id}-PROTOCOL_VIOLATION/MISSING_HEADER-%{matched_var_name}=%{matched_var}"

	SecMarker END_HOST_CHECK

SecPcreMatchLimit#

Description: Would set the PCRE match limit.

Syntax: SecPcreMatchLimit [NUMBER]

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect. Coraza matches with RE2, which runs in linear time and has no backtracking limit to configure.

Example:

SecPcreMatchLimit 1500

SecPcreMatchLimitRecursion#

Description: Would set the PCRE match recursion limit.

Syntax: SecPcreMatchLimitRecursion [NUMBER]

Note: Coraza accepts this directive for compatibility with ModSecurity configurations, but it has no effect. Coraza matches with RE2, which does not recurse while matching.

Example:

SecPcreMatchLimitRecursion 1500

SecRemoteRules#

Description: Loads rules from a remote URL.

Syntax: SecRemoteRules [KEY] URL

Note: Coraza rejects this directive: fetching rules over the network is not implemented, so a configuration using it fails to load with an error rather than being ignored.

Example:

SecRemoteRules https://example.com/rules.conf

SecRemoteRulesFailAction#

Description: Controls what happens when rules cannot be retrieved from a remote source: Abort fails the configuration load, Warn continues.

Syntax: SecRemoteRulesFailAction Abort|Warn

Example:

SecRemoteRulesFailAction Abort

SecRequestBodyAccess#

Description: Configures whether request bodies will be buffered and processed by Coraza.

Syntax: SecRequestBodyAccess On|Off

Default: Off

This directive is required if you want to inspect the data transported request bodies (e.g., POST parameters). Request buffering is also required in order to make reliable blocking possible. The possible values are:

• On: buffer request bodies
• Off: do not buffer request bodies

Example:

SecRequestBodyAccess On

SecRequestBodyInMemoryLimit#

Description: Configures the maximum request body size that Coraza will store in memory.

Syntax: SecRequestBodyInMemoryLimit [LIMIT_IN_BYTES]

Default: defaults to RequestBodyLimit

When a multipart/form-data request is being processed, once the in-memory limit is reached, the request body will start to be streamed into a temporary file on disk.

Example:

SecRequestBodyInMemoryLimit 131072

SecRequestBodyJsonDepthLimit#

Description: Configures the maximum JSON recursion depth limit Coraza will accept.

Syntax: SecRequestBodyJsonDepthLimit [LIMIT]

Default: 1024

Anything over the limit will generate a REQBODY_ERROR in the JSON body processor.

Example:

SecRequestBodyJsonDepthLimit 1024

SecRequestBodyLimit#

Description: Configures the maximum request body size Coraza will accept for buffering.

Syntax: SecRequestBodyLimit [LIMIT_IN_BYTES]

Default: 134217728 (128 Mib)

Depends on SecRequestBodyLimitAction

• Reject: Anything over this limit will be rejected with status code 413 (Request Entity Too Large).
• ProcessPartial: The first N bytes of the request body will be processed. There is a hard limit of 1 GiB.

Example:

SecRequestBodyLimit 134217728

SecRequestBodyLimitAction#

Description: Controls what happens once a request body limit, configured with SecRequestBodyLimit, is encountered.

Syntax: SecRequestBodyLimitAction Reject|ProcessPartial

Default: Reject

By default, Coraza will reject a request body that is longer than specified to avoid OOM issues while buffering the request body prior the inspection.

Note: When SecRuleEngine is set to DetectionOnly, this directive is set to ProcessPartial to minimize disruptions when initially deploying Coraza.

Example:

SecRequestBodyLimitAction Reject

SecRequestBodyNoFilesLimit#

Description: Configures the maximum request body size Coraza will accept for buffering, excluding the size of any files being transported in the request. This directive is useful to reduce susceptibility to DoS attacks when someone is sending request bodies of very large sizes. Web applications that require file uploads must configure SecRequestBodyLimit to a high value, but because large files are streamed to disk, file uploads will not increase memory consumption. However, it’s still possible for someone to take advantage of a large request body limit and send non-upload requests with large body sizes. This directive eliminates that loophole.

Syntax: SecRequestBodyNoFilesLimit 131072

Default: 1048576 (1 MB)

Generally speaking, the default value is not small enough. For most applications, you should be able to reduce it down to 128 KB or lower. Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GiB.

Note: not implemented yet

Example:

SecRequestBodyNoFilesLimit 131072

SecResponseBodyAccess#

Description: Configures whether response bodies are to be buffered.

Syntax: SecResponseBodyAccess On|Off

Default: Off

This directive is required if you plan to inspect HTML responses and implement response blocking. Possible values are:

• On: buffer response bodies (but only if the response MIME type matches the list configured with SecResponseBodyMimeType).
• Off: do not buffer response bodies.

Example:

SecResponseBodyAccess On

SecResponseBodyJsonDepthLimit#

Description: Configures the maximum JSON recursion depth limit Coraza will accept in response bodies.

Syntax: SecResponseBodyJsonDepthLimit [LIMIT]

Default: 1024

Anything over the limit will generate a RES_BODY_ERROR in the JSON body processor. Requires SecResponseBodyAccess On to have any effect.

Example:

SecResponseBodyJsonDepthLimit 1024

SecResponseBodyLimit#

Description: Configures the maximum response body size that will be accepted for buffering.

Syntax: SecResponseBodyLimit [LIMIT_IN_BYTES]

Default: 524288 (512 Kib)

Depends on SecResponseBodyLimitAction

• Reject: Anything over this limit will be rejected with status code 500 (Internal Server Error).
• ProcessPartial: The first N bytes of the response body will be processed. This setting will not affect the responses with MIME types that are not selected for buffering. There is a hard limit of 1 GiB.

Example:

SecResponseBodyLimit 524288

SecResponseBodyLimitAction#

Description: Controls what happens once a response body limit, configured with SecResponseBodyLimit, is encountered.

Syntax: SecResponseBodyLimitAction Reject|ProcessPartial

By default, Coraza will reject a response body that is longer than specified. Some web sites, however, will produce very long responses, making it difficult to come up with a reasonable limit. Such sites would have to raise the limit significantly to function properly, defying the purpose of having the limit in the first place (to control memory consumption). With the ability to choose what happens once a limit is reached, site administrators can choose to inspect only the first part of the response, the part that can fit into the desired limit, and let the rest through. Some could argue that allowing parts of responses to go uninspected is a weakness. This is true in theory, but applies only to cases in which the attacker controls the output (e.g., can make it arbitrary long). In such cases, however, it is not possible to prevent leakage anyway. The attacker could compress, obfuscate, or even encrypt data before it is sent back, and therefore bypass any monitoring device.

Note: When SecRuleEngine is set to DetectionOnly, this directive is set to ProcessPartial to minimize disruptions when initially deploying Coraza.

Example:

SecResponseBodyLimitAction ProcessPartial

SecResponseBodyMimeType#

Description: Configures which MIME types are to be considered for response body buffering.

Syntax: SecResponseBodyMimeType MIMETYPE MIMETYPE ...

Multiple SecResponseBodyMimeType directives can be used to add MIME types. Use SecResponseBodyMimeTypesClear to clear previously configured MIME types and start over.

Example:

SecResponseBodyMimeType text/plain text/html text/xml

SecResponseBodyMimeTypesClear#

Description: Clears the list of MIME types considered for response body buffering, allowing you to start populating the list from scratch.

Syntax: SecResponseBodyMimeTypesClear

Example:

SecResponseBodyMimeTypesClear

SecRule#

Description: Creates a rule that will analyze the selected variables using the selected operator.

Syntax: SecRule VARIABLES OPERATOR [ACTIONS]

Every rule must provide one or more variables along with the operator that should be used to inspect them. If no actions are provided, the default list will be used. (There is always a default list, even if one was not explicitly set with SecDefaultAction.) If there are actions specified in a rule, they will be merged with the default list to form the final actions that will be used. (The actions in the rule will overwrite those in the default list.) Refer to SecDefaultAction for more information.

Example:

SecRule ARGS "@rx attack" "phase:1,log,deny,id:1"

SecRuleEngine#

Description: Configures the rules engine.

Syntax: SecRuleEngine On|Off|DetectionOnly

Default: Off

The possible values are:

• On: process rules
• Off: do not process rules
• DetectionOnly: process rules but never executes any disruptive actions (block, deny, drop, allow, proxy and redirect)

Example:

SecRuleEngine DetectionOnly

SecRuleRemoveByID#

Description: Removes the matching rules from the current configuration context.

Syntax: SecRuleRemoveById ID|RANGE [ID|RANGE ...]

Permanently removes rules by ID or inclusive range from the WAF configuration at parse time. The removal applies to all transactions, check the per-transaction run time ctl:ruleRemoveById action for more granular control when disabling a rule.

Note: This directive operates on the rules already loaded at the point it is parsed, so it must appear AFTER any Include directive that loads the rules to be removed. Placing it before the include has no effect because those rules do not yet exist in the configuration.

Example:

SecRule REQUEST_URI "@rx attack" "id:1000,phase:1,log,deny"
SecRuleRemoveById 1000

SecRuleRemoveByMsg#

Description: Removes the matching rules from the current configuration context.

Syntax: SecRuleRemoveByMsg MESSAGE

Permanently removes all rules with the given message from the WAF configuration at parse time. The removal applies to all transactions, check the per-transaction run time ctl:ruleRemoveByMsg action for more granular control when disabling rules.

Matching is by case-sensitive string equality.

Note: This directive operates on the rules already loaded at the point it is parsed, so it must appear AFTER any directive that loads the rules to be removed. Placing it before has no effect because those rules do not yet exist in the configuration.

Example:

SecRule REQUEST_URI "@rx attack" "id:1000,phase:1,log,deny,msg:'My Custom Rule Msg'"
SecRuleRemoveByMsg "My Custom Rule Msg"

SecRuleRemoveByTag#

Description: Removes the matching rules from the current configuration context.

Syntax: SecRuleRemoveByTag [TAG]

Permanently removes all rules carrying the given tag from the WAF configuration at parse time. The removal applies to all transactions, check the per-transaction run time ctl:ruleRemoveByTag action for more granular control when disabling rules.

Matching is by case-sensitive string equality.

Note: This directive operates on the rules already loaded at the point it is parsed, so it must appear AFTER any directive that loads the rules to be removed. Placing it before has no effect because those rules do not yet exist in the configuration.

Example:

SecRule REQUEST_URI "@rx attack" "id:1000,phase:1,log,deny,tag:my-tag"
SecRuleRemoveByTag my-tag

Note: OWASP CRS has a list of supported tags https://coreruleset.org/docs/rules/metadata/

SecRuleUpdateActionByID#

Description: Updates the action list of the specified rule(s).

Syntax: SecRuleUpdateActionById ID ACTIONLIST

This directive will overwrite the action list of the specified rule with the actions provided in the second parameter. It has two limitations: it cannot be used to change the ID or phase of a rule. Only the actions that can appear only once are overwritten. The actions that are allowed to appear multiple times in a list, will be appended to the end of the list. The following example demonstrates how SecRuleUpdateActionById is used:

SecRuleUpdateActionById 12345 "deny,status:403"

The rule ID can be single IDs or ranges of IDs. The targets are separated by a pipe character.

SecRuleUpdateTargetByID#

Description: Updates the target (variable) list of the specified rule(s).

Syntax: SecRuleUpdateTargetById ID TARGET1[|TARGET2|TARGET3]

This directive will append variables to the specified rule with the targets provided in the second parameter. The rule ID can be single IDs or ranges of IDs. The targets are separated by a pipe character.

Example:

SecRuleUpdateTargetById 7 "!REQUEST_HEADERS:/xyz/"

SecRuleUpdateTargetByTag#

Description: Updates the target (variable) list of the specified rule(s) by tag.

Syntax: SecRuleUpdateTargetByTag TAG TARGET1[|TARGET2|TARGET3]

As an alternative to SecRuleUpdateTargetById, this directive will append variables to the specified rule with the targets provided in the second parameter. It can be handy for updating an entire group of rules. Matching is by case-sensitive string equality. This directive will append variables to the specified rule with the targets provided in the second parameter. The rule ID can be single IDs or ranges of IDs. The targets are separated by a pipe character.

Note: OWASP CRS provides a list of supported tags.

Example:

SecRuleUpdateTargetByTag "attack-sqli" "!ARGS:query"

SecRxPreFilter#

Description: Enables or disables pre-filtering for the @rx operator.

Syntax: SecRxPreFilter On|Off

Default: Off

When enabled, Coraza analyses each regex pattern at rule-load time to extract required literal substrings and compute the minimum match length. At request time these fast checks run before the full regex, allowing the engine to skip the regex entirely when an input clearly cannot match.

Warning: This is an experimental feature.

Example:

SecRxPreFilter On

SecSensorID#

Description: Sets an identifier for this Coraza instance, useful when several sensors write to a shared log.

Syntax: SecSensorID "ID"

Example:

SecSensorID "sensor-01"

SecServerSignature#

Description: Sets the server signature Coraza reports. Surrounding quotes, if present, are removed.

Syntax: SecServerSignature "SIGNATURE"

Example:

SecServerSignature "Apache/2.2.15"

SecUploadDir#

Description: Configures the directory where uploaded files will be stored.

Syntax: SecUploadDir /path/to/dir

Default: ""

This directive is required when enabling SecUploadKeepFiles.

Example:

SecUploadDir /tmp/coraza/uploads

SecUploadFileLimit#

Description: Sets the maximum number of uploaded files handled per request. The value is parsed but not yet enforced; see corazawaf/coraza#1686 for the surrounding discussion.

Syntax: SecUploadFileLimit [NUMBER]

Example:

SecUploadFileLimit 10

SecUploadFileMode#

Description: Sets the file mode applied to files stored by SecUploadDir. The value is parsed as octal.

Syntax: SecUploadFileMode OCTAL_MODE

Example:

SecUploadFileMode 0600

SecUploadKeepFiles#

Description: Configures whether intercepted files will be kept after the transaction is processed.

Syntax: SecUploadKeepFiles On|RelevantOnly|Off

Default: Off

The SecUploadKeepFiles directive is used to configure whether intercepted files are preserved on disk after the transaction is processed. This directive requires the storage directory to be defined (using SecUploadDir).

Possible values are:

• On: Keep all uploaded files.
• Off: Do not keep uploaded files.
• RelevantOnly: Keep only uploaded files that matched at least one rule that would be logged (excluding rules with the nolog action).

Example:

SecUploadKeepFiles RelevantOnly

SecWebAppID#

Description: Sets an identifier for the web application being protected. The value is exposed to rules and audit logs.

Syntax: SecWebAppID "NAME"

Example:

SecWebAppID "my_application"

Unsupported#

Description: Shared handler for ModSecurity directives that Coraza parses and discards, so existing configurations continue to load.

Syntax: SecTmpDir /path/to/dir

Note: This handler backs SecArgumentSeparator, SecCookieFormat, SecRuleUpdateTargetByMsg, SecRuleScript, SecRulePerfTime, SecUnicodeMap and SecTmpDir. All are accepted and ignored.

Example:

SecTmpDir /tmp