<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Actions :: WGE</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/index.html</link><description>Actions can be categorized into three types based on their execution timing:
Configuration Actions: Such as id, phase, etc., used to define rule metadata. Match-Triggered Actions: Such as setvar, ctl, etc., executed when a single rule matches. A “single rule” here refers to one SecRule, not a parent-child rule chain as a whole. Disruptive Actions: Such as deny, allow, etc., executed after the entire rule (including chained sub-rules) completes matching, typically affecting subsequent rule processing. Keyword Description id Unique rule identifier (required) phase Processing phase (1-5) msg Log message severity Severity level (0-7) tag Rule tag ver Rule version rev Rule revision accuracy Accuracy level (1-9) maturity Maturity level (1-9) deny Deny request drop Drop connection allow Allow request to pass allow:phase Allow request to pass current phase allow:request Allow the entire request to pass redirect Redirect to specified URL pass Continue processing subsequent rules block Use default disruptive action log Log to error log nolog Do not log to error log auditlog Log to audit log noauditlog Do not log to audit log logdata Log additional data capture Capture regex match content multiMatch Execute action for all matches setvar Set variable expirevar Set variable expiration time setenv Set environment variable setuid Set user ID setsid Set session ID setrsc Set resource ID initcol Initialize persistent collection chain Chain rules together skip Skip specified number of subsequent rules skipAfter Skip to a rule with specified marker ctl Modify engine configuration at runtime exec Execute external script or command status Set HTTP response status code xmlns Define XML namespace</description><generator>Hugo</generator><language>en</language><atom:link href="https://zhouyujt.github.io/wge/seclang-plus/actions/index.xml" rel="self" type="application/rss+xml"/><item><title>id</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/id/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/id/index.html</guid><description>Description: Unique rule identifier (required)
Syntax: id:number
The id action assigns a unique numeric identifier to a rule. This is a mandatory action for every rule. Rule IDs are used for logging, debugging, and rule management. Each rule must have a unique ID within the configuration.
Example:
SecRule ARGS "@rx test" "id:1001,deny" Parameter Type: int
Case Sensitive: Yes</description></item><item><title>phase</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/phase/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/phase/index.html</guid><description>Description: Processing phase (1-5)
Syntax: phase:1|2|3|4|5|request|response|logging
The phase action specifies which processing phase a rule executes in. WGE processes HTTP transactions through five sequential phases, each triggered when specific data becomes available. Selecting the correct phase is crucial for rule effectiveness.
phase:1 (request) - Request headers phase: Executes immediately after receiving complete request headers, before the request body is read. Used for early decisions such as IP blacklisting and URL detection. phase:2 (request) - Request body phase: Executes after the request body is fully received and parsed. Most application-layer rules run in this phase, with access to ARGS, REQUEST_BODY and other variables. phase:3 (response) - Response headers phase: Executes after receiving backend response headers, before the response body is read. Used for checking response status codes and headers. phase:4 (response) - Response body phase: Executes after the response body is fully received. Used for detecting sensitive data leakage in response content. phase:5 (logging) - Logging phase: Executes after the response is sent, cannot block requests. Used only for logging and statistics. Example:</description></item><item><title>msg</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/msg/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/msg/index.html</guid><description>Description: Log message
Syntax: msg:'value'
Case Sensitive: Yes
Similar to logdata, msg also supports macro expansion.
Example:
SecRule ARGS "@rx test" "id:1001,deny,msg:'SQL Injection Detected'" # msg with macro expansion SecRule ARGS "@rx test2" "id:1002,deny,msg:'Deny the ip %{REMOTE_ADDR}'"</description></item><item><title>severity</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/severity/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/severity/index.html</guid><description>Description: Severity level (0-7)
Syntax: severity:CRITICAL|ERROR|WARNING|NOTICE|INFO|DEBUG
The severity action assigns a severity level to a rule. This is used for categorizing threats and prioritizing alerts. Common values include CRITICAL for severe attacks, WARNING for suspicious activity, and NOTICE for informational events.
Example:
SecRule ARGS "@rx test" "id:1001,deny,severity:CRITICAL" Parameter Type: int or string
Case Sensitive: Yes</description></item><item><title>tag</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/tag/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/tag/index.html</guid><description>Description: Rule tag
Syntax: tag:'tagname'
The tag action assigns a tag to a rule for categorization and filtering purposes. Multiple tags can be assigned to a single rule. Tags are useful for organizing rules by attack type, compliance standard, or any other classification scheme.
Example:
SecRule ARGS "@rx test" "id:1001,deny,tag:'attack-sqli'" Parameter Type: string
Case Sensitive: Yes</description></item><item><title>ver</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/ver/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/ver/index.html</guid><description>Description: Rule version
Syntax: ver:'version'
The ver action specifies the version of a rule or rule set. This metadata is useful for tracking rule updates and managing different versions of rule sets across environments.
Example:
SecRule ARGS "@rx test" "id:1001,deny,ver:'1.0.0'" Parameter Type: string
Case Sensitive: Yes</description></item><item><title>rev</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/rev/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/rev/index.html</guid><description>Description: Rule revision
Syntax: rev:'revision'
The rev action specifies the revision number of a rule. This metadata tracks how many times a rule has been modified, helping with rule lifecycle management and auditing.
Example:
SecRule ARGS "@rx test" "id:1001,deny,rev:'2'" Parameter Type: string
Case Sensitive: Yes</description></item><item><title>accuracy</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/accuracy/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/accuracy/index.html</guid><description>Description: Accuracy level (1-9)
Syntax: accuracy:level
The accuracy action specifies the accuracy level of a rule on a scale of 1 to 9. Higher values indicate rules with fewer false positives. This metadata helps operators understand the reliability of different rules and make informed decisions about which rules to enable in production.
Example:
SecRule ARGS "@rx test" "id:1001,deny,accuracy:8" Parameter Type: int
Case Sensitive: Yes</description></item><item><title>maturity</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/maturity/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/maturity/index.html</guid><description>Description: Maturity level (1-9)
Syntax: maturity:level
The maturity action specifies the maturity level of a rule on a scale of 1 to 9. Higher values indicate rules that have been more thoroughly tested and are considered production-ready. This metadata helps operators understand the stability and reliability of different rules.
Example:
SecRule ARGS "@rx test" "id:1001,deny,maturity:9" Parameter Type: int
Case Sensitive: Yes</description></item><item><title>deny</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/deny/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/deny/index.html</guid><description>Description: Deny request
Syntax: deny
The deny action is the most commonly used disruptive action, used to immediately terminate processing of the current request and return an error response. When a rule matches, WGE stops processing subsequent rules and returns the specified HTTP status code to the client (default 403 Forbidden).
The deny action is typically used with the status action to specify a custom response status code. In anomaly scoring mode, deny is usually only used for the final scoring threshold check rule.</description></item><item><title>drop</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/drop/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/drop/index.html</guid><description>Description: Drop connection
Syntax: drop | drop:value
The drop action immediately terminates the TCP connection without sending a response. This is more aggressive than deny and is typically used for severe attacks where you want to minimize resource usage and avoid any response to the attacker.
Example:
SecRule ARGS "@rx test" "id:1001,drop,status:403" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>allow</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/allow/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/allow/index.html</guid><description>Description: Allow request to pass
Syntax: allow | allow:value
The allow action permits the current request to pass without blocking. When used alone, it stops rule processing for the current phase and allows the transaction to continue. This is typically used for whitelisting trusted requests or implementing exceptions.
Example:
SecRule ARGS "@rx test" "id:1001,allow,status:403" Parameter Type: none or string
Case Sensitive: Yes</description></item><item><title>allow:phase</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/allowphase/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/allowphase/index.html</guid><description>Description: Allow request to pass current phase
Syntax: allow:phase
The allow:phase action permits the request to bypass remaining rules in the current processing phase only. Rules in subsequent phases will still be evaluated. This provides finer-grained control compared to allow:request. To allow a response, add a rule in the RESPONSE_HEADERS phase and use allow.
Example:
SecRule ARGS "@rx test" "id:1001,allow:phase" Parameter Type: string
Case Sensitive: Yes</description></item><item><title>allow:request</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/allowrequest/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/allowrequest/index.html</guid><description>Description: Allow the entire request to pass
Syntax: allow:request
The allow:request action permits the entire request to bypass all remaining rules. This is useful for whitelisting known-good requests or trusted sources. Once triggered, no further rules in any phase will be evaluated for this request.
Example:
SecRule ARGS "@rx test" "id:1001,allow:request" Parameter Type: string
Case Sensitive: Yes</description></item><item><title>redirect</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/redirect/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/redirect/index.html</guid><description>Description: Redirect to specified URL
Syntax: redirect:url
Case Sensitive: Yes
Implemented: No
The redirect action sends an HTTP redirect response to the client, directing them to a specified URL. This is useful for sending detected attackers to honeypots, warning pages, or blocked pages while providing a better user experience than a simple deny.
Example:
SecRule ARGS "@detectSQLi" "id:1001,redirect:https://example.com/blocked.html" Parameter Type: string
Case Sensitive: Yes</description></item><item><title>pass</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/pass/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/pass/index.html</guid><description>Description: Continue processing subsequent rules
Syntax: pass | pass:value
The pass action allows the transaction to continue to the next rule even when the current rule matches. This is a non-disruptive action commonly used in conjunction with setvar to record matches without blocking, enabling anomaly scoring and data collection patterns.
Example:
SecRule ARGS "@rx suspicious" "id:1001,pass,setvar:tx.anomaly_score=+3" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>block</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/block/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/block/index.html</guid><description>Description: Use default disruptive action
Syntax: block | block:value
The block action executes the default disruptive action configured by SecDefaultAction. This allows rules to be written without hardcoding a specific action, making it easier to switch between different blocking behaviors (like deny or redirect) across the entire configuration.
Example:
SecRule ARGS "@rx test" "id:1001,block,status:403" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>log</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/log/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/log/index.html</guid><description>Description: Log to error log
Syntax: log | log:value
The log action records the rule match to the error log. This is the default behavior for most rules, but can be explicitly specified when combined with other actions. The logged message includes rule ID, matched variable, and the configured msg value.
Example:
SecRule ARGS "@rx test" "id:1001,log,status:403" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>nolog</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/nolog/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/nolog/index.html</guid><description>Description: Do not log to error log
Syntax: nolog | nolog:value
The nolog action prevents the rule match from being recorded in the error log. This is typically used for rules that perform internal bookkeeping (such as setting variables) where logging each match would be unnecessary and noisy.
Example:
SecRule ARGS "@rx test" "id:1001,nolog,status:403" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>auditlog</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/auditlog/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/auditlog/index.html</guid><description>Description: Log to audit log
Syntax: auditlog | auditlog:value
The auditlog action forces the transaction to be recorded in the audit log. The audit log contains detailed information about the request and response, which is useful for forensic analysis and compliance purposes.
Example:
SecRule ARGS "@rx test" "id:1001,auditlog,status:403" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>noauditlog</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/noauditlog/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/noauditlog/index.html</guid><description>Description: Do not log to audit log
Syntax: noauditlog | noauditlog:value
The noauditlog action prevents the transaction from being recorded in the audit log even when a rule matches. This is useful for rules that match frequently on known-benign traffic and would otherwise fill up the audit log with noise.
Example:
SecRule ARGS "@rx test" "id:1001,noauditlog,status:403" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>logdata</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/logdata/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/logdata/index.html</guid><description>Description: Log additional data
Syntax: logdata:'data'
The logdata action records additional information to the log when a rule matches. This is useful for including context such as the matched value, user information, or other relevant data that helps with incident investigation. The data can include variable expansion using the %{VARNAME} syntax.
Example:
SecRule ARGS "@rx attack" "id:1001,deny,logdata:'User: %{REMOTE_ADDR}, Matched: %{MATCHED_VAR}'" Parameter Type: string
Case Sensitive: Yes</description></item><item><title>capture</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/capture/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/capture/index.html</guid><description>Description: Capture regex match content
Syntax: capture | capture:value
The capture action captures the content matched by a regular expression operator. The captured groups are stored in TX:0 through TX:9 variables, where TX:0 contains the full match and TX:1 through TX:9 contain the captured subgroups. This is useful for extracting and reusing matched data in subsequent rules or log messages.
Example:
SecRule ARGS "@rx test" "id:1001,capture,status:403" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>multiMatch</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/multimatch/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/multimatch/index.html</guid><description>Description: Execute action for all matches
Syntax: multiMatch | multiMatch:value
The multiMatch action causes the rule to be evaluated against each element of a collection variable individually. Without multiMatch, a rule checking ARGS would stop after the first matching argument. With multiMatch, all matching arguments are processed, which is useful when you want to capture or log all offending values.
Example:
SecRule ARGS "@rx test" "id:1001,multiMatch,status:403" Parameter Type: none
Case Sensitive: Yes</description></item><item><title>setvar</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/setvar/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/setvar/index.html</guid><description>Description: Set variable
Syntax: setvar:collection.key=value
The setvar action creates, modifies, or deletes collection variables. This is a core action for implementing anomaly scoring, state tracking, and passing data between rules. It supports multiple operations:
setvar:tx.key=value - Set variable to specified value setvar:tx.key=+value - Increment variable by specified value (numeric addition) setvar:tx.key=-value - Decrement variable by specified value setvar:!tx.key - Delete variable Multiple setvar actions can be used in a single rule. Supports macro expansion using %{VARIABLE} to reference other variable values.</description></item><item><title>expirevar</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/expirevar/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/expirevar/index.html</guid><description>Description: Set variable expiration time
Syntax: expirevar:collection.variable=seconds
Case Sensitive: Yes
Implemented: No
The expirevar action sets a time-to-live (TTL) for a collection variable. After the specified number of seconds, the variable is automatically removed. This is commonly used for implementing temporary bans, rate limiting windows, and session-based tracking.
Example:
SecRule ARGS "@rx attack" "id:1001,pass,setvar:ip.blocked=1,expirevar:ip.blocked=600" Parameter Type: string
Case Sensitive: Yes</description></item><item><title>setenv</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/setenv/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/setenv/index.html</guid><description>Description: Set Linux/Unix environment variable (overwrite if it already exists)
Info: Original example: setenv:attack_detected=1
Syntax: setenv:'string=(value|%{variable})'
Case Sensitive: Yes
This action supports execution on non-match and unconditional execution.
Example:
SecRule ARGS "@rx test" "id:1001,setenv:http_proxy=%{REMOTE_ADDR},status:403" # Execute on non-match SecRule ARGS "@rx test" "id:1002,!setenv:http_proxy=%{REMOTE_ADDR},status:403" # Always execute SecRule ARGS "@rx test" "id:1003,*setenv:http_proxy=%{REMOTE_ADDR},status:403"</description></item><item><title>setuid</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/setuid/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/setuid/index.html</guid><description>Description: Initialize the USER collection using the provided parameter
Syntax: setuid:('string' | %{variable})
Case Sensitive: Yes
Implementation Status: Not yet implemented
This action supports execution on non-match and unconditional execution.
WGE can parse this directive correctly, but the feature is not implemented yet.
Example:
SecRule ARGS:username ".*" "phase:2,id:137,t:none,pass,capture,setuid:%{TX.0}" # Execute on non-match SecRule ARGS:username ".*" "phase:2,id:138,t:none,pass,capture,!setuid:%{TX.0}" # Always execute SecRule ARGS:username ".*" "phase:2,id:139,t:none,pass,capture,*setuid:%{TX.0}"</description></item><item><title>setsid</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/setsid/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/setsid/index.html</guid><description>Description: Initialize the SESSION collection using the provided parameter
Syntax: setsid:('string' | %{variable})
Case Sensitive: Yes
Implementation Status: Not yet implemented
This action supports execution on non-match and unconditional execution.
WGE can parse this directive correctly, but the feature is not implemented yet.
Example:
SecRule ARGS "@rx test" "id:1001,phase:2,setsid:%{REQUEST_COOKIES.PHPSESSID},status:403" # Execute on non-match SecRule ARGS "@rx test" "id:1002,phase:2,!setsid:%{REQUEST_COOKIES.PHPSESSID},status:403" # Always execute SecRule ARGS "@rx test" "id:1003,phase:2,*setsid:%{REQUEST_COOKIES.PHPSESSID},status:403"</description></item><item><title>setrsc</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/setrsc/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/setrsc/index.html</guid><description>Description: Special action that initializes the RESOURCE collection with the provided key
Syntax: setrsc:('string' | %{variable})
Case Sensitive: Yes
Implementation Status: Not yet implemented
This action supports execution on non-match and unconditional execution.
WGE can parse this directive correctly, but the feature is not implemented yet.
Example:
SecRule ARGS "@rx test" "id:1001,setrsc:'abcd1234',status:403" # Execute on non-match SecRule ARGS "@rx test" "id:1002,!setrsc:'abcd1234',status:403" # Always execute SecRule ARGS "@rx test" "id:1003,*setrsc:'abcd1234',status:403"</description></item><item><title>initcol</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/initcol/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/initcol/index.html</guid><description>Description: Initialize persistent collection
Syntax: initcol:collection=key
The initcol action initializes persistent collections (IP, SESSION, USER, RESOURCE, GLOBAL). These collections are commonly used for IP rate limiting, session tracking, and user behavior analysis.
Available Collections:
IP - Persistent storage based on client IP address SESSION - Persistent storage based on session ID USER - Persistent storage based on user ID RESOURCE - Persistent storage based on resource identifier GLOBAL - Global persistent storage At the moment, WGE can parse this action but does not implement real persistence. In practice, it behaves similarly to using setvar variables within the transaction lifecycle.</description></item><item><title>exec</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/exec/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/exec/index.html</guid><description>Description: Execute external script or command
Syntax: exec:/path/to/script
Case Sensitive: Yes
Implemented: No
The exec action executes an external script or command when the rule matches. This can be used for custom logging, alerting, or integration with external systems. The script is executed asynchronously to avoid blocking request processing.
Example:
SecRule ARGS "@detectSQLi" "id:1001,deny,exec:/usr/local/bin/alert_admin.sh" Parameter Type: string (file path)
Case Sensitive: Yes</description></item><item><title>chain</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/chain/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/chain/index.html</guid><description>Description: Chain rules together
Syntax: chain
The chain action links rules together so they act as a single compound rule. When rules are chained, subsequent rules only execute if all preceding rules in the chain match. This allows complex multi-condition checks without duplicating code.
Key behaviors:
Only the last rule in a chain can contain disruptive actions (deny, block, drop, etc.) Metadata actions (id, msg, tag, etc.) should be on the first rule of the chain If any rule in the chain fails to match, the entire chain stops processing Phase must be consistent across all chained rules Example:</description></item><item><title>ctl</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/ctl/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/ctl/index.html</guid><description>Description: Modify runtime configuration
Syntax: ctl:directive=value
The ctl (control) action allows runtime modification of processing directives for the current transaction. This enables dynamic rule behavior changes based on request characteristics.
Available options:
ctl:auditEngine=On|Off|RelevantOnly - Change audit logging mode ctl:auditLogParts=+/-PARTS - Add or remove audit log parts ctl:forceRequestBodyVariable=On|Off - Force REQUEST_BODY variable population ctl:requestBodyAccess=On|Off - Enable/disable request body inspection ctl:requestBodyProcessor=URLENCODED|MULTIPART|XML|JSON - Set body processor ctl:ruleEngine=On|Off|DetectionOnly - Change rule engine mode ctl:ruleRemoveById=ID - Remove rule by ID for current transaction ctl:ruleRemoveByTag=TAG - Remove rules by tag for current transaction ctl:ruleRemoveTargetById=ID;VARIABLE - Remove target from rule ctl:ruleRemoveTargetByTag=TAG;VARIABLE - Remove target from rules by tag Example:</description></item><item><title>skip</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/skip/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/skip/index.html</guid><description>Description: Skip a specified number of rules
Syntax: skip:N
The skip action skips the next N rules in the configuration when the current rule matches. This provides a simple way to conditionally bypass rules without using chains or markers.
Important notes:
N must be a positive integer Skip only works within the same phase Skip counts rules, not chains (each chained rule counts as one rule) For complex conditional logic, consider using skipAfter with SecMarker instead Example:</description></item><item><title>skipAfter</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/skipafter/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/skipafter/index.html</guid><description>Description: Skip to a named marker
Syntax: skipAfter:MARKER_NAME
The skipAfter action jumps to a named marker (created with SecMarker) when the current rule matches. This provides flexible flow control for conditional rule execution, especially useful for complex rule sets.
Advantages over skip:
More readable and maintainable Independent of rule count (can add/remove rules without breaking skip logic) Better for conditional bypassing of rule groups Clearer intent in configuration Example:
# Skip all SQL injection checks for trusted paths SecRule REQUEST_URI "^/api/internal/" \ "id:100,phase:2,pass,nolog,skipAfter:END_SQLI_CHECKS" SecRule ARGS "@detectSQLi" "id:101,phase:2,deny,status:403,msg:'SQL Injection'" SecRule ARGS "@rx union.*select" "id:102,phase:2,deny,status:403,msg:'SQL Union'" SecRule ARGS "@rx (\%27)|(\')" "id:103,phase:2,deny,status:403,msg:'SQL Quote'" SecMarker END_SQLI_CHECKS # Conditional authentication bypass SecRule REQUEST_URI "^/public/" \ "id:200,phase:1,pass,nolog,skipAfter:AFTER_AUTH" SecRule REQUEST_HEADERS:X-API-Key "!@streq secret123" \ "id:201,phase:1,deny,status:403,msg:'Invalid API Key'" SecMarker AFTER_AUTH Parameter Type: string</description></item><item><title>status</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/status/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/status/index.html</guid><description>Description: Set HTTP response status code
Syntax: status:CODE
The status action sets the HTTP response status code to be returned when a disruptive action (deny, block, drop) is triggered. This allows fine-grained control over error responses.
Common status codes:
400 - Bad Request (malformed input) 401 - Unauthorized (authentication required) 403 - Forbidden (access denied) 404 - Not Found (hide resource existence) 405 - Method Not Allowed 429 - Too Many Requests (rate limiting) 500 - Internal Server Error 503 - Service Unavailable Example:</description></item><item><title>t</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/t/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/t/index.html</guid><description>Description: Apply transformation function
Syntax: t:transformationName
The t (transformation) action applies a transformation function to the input data before matching against the operator. Transformations normalize or decode data to improve detection accuracy. Multiple transformations can be chained and are applied in order.
Common transformations:
t:none - Disable all default transformations t:lowercase - Convert to lowercase t:urlDecode - URL decode t:htmlEntityDecode - Decode HTML entities t:base64Decode - Base64 decode t:removeWhitespace - Remove all whitespace t:compressWhitespace - Normalize whitespace t:normalizePath - Normalize path separators t:cmdLine - Normalize command line t:hexDecode - Decode hex-encoded data Important: When using t:none, it should be the first transformation specified to clear inherited transformations from SecDefaultAction.</description></item><item><title>xmlns</title><link>https://zhouyujt.github.io/wge/seclang-plus/actions/xmlns/index.html</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://zhouyujt.github.io/wge/seclang-plus/actions/xmlns/index.html</guid><description>Description: Define XML namespace for XPath expressions
Syntax: xmlns:string
Case Sensitive: Yes
WGE can parse this directive, but the feature is not implemented yet.</description></item></channel></rss>