Variables :: WGE

ARGS

Mon, 01 Jan 0001 00:00:00 +0000

Description: All request parameters Syntax: ARGS | ARGS:Key ARGS contains parameters from multiple sources, including request-line parameters, request bodies of type application/x-www-form-urlencoded, multipart/form-data, and application/json, and, when SecParseXmlIntoArgs is set to On or OnlyArgs, content parsed from application/xml request bodies. Note: When this variable is used in phase 1, it behaves the same as ARGS_GET. Example: SecRule ARGS:user "@rx admin" "id:1001,deny,msg:'Test'" ARGS Parsing Examples 1. JSON Request Body Parsing (application/json) For JSON values of type number, boolean, or null, WGE stores only the key because those values usually do not carry attack payloads.

ARGS_GET

Mon, 01 Jan 0001 00:00:00 +0000

Description: GET parameters Syntax: ARGS_GET | ARGS_GET:Key ARGS_GET contains only parameters passed in the URL query string (i.e., GET parameters). Unlike ARGS, it does not include parameters from the POST request body, making it useful for inspecting only URL-passed data without false positives from POST data. Specific parameters can be accessed via ARGS_GET:paramname. Example: # Check for SQL injection in URL query parameters SecRule ARGS_GET "@detectSQLi" "id:1001,phase:1,deny,status:403,msg:'SQL injection detected in GET parameters'" # Check specific GET parameter SecRule ARGS_GET:id "@rx [^0-9]" "id:1002,phase:1,deny,msg:'ID parameter must be numeric'"

ARGS_POST

Mon, 01 Jan 0001 00:00:00 +0000

Description: POST request parameters Syntax: ARGS_POST | ARGS_POST:Key ARGS_POST contains only parameters passed in the request body, that is, POST data. WGE supports parsing request bodies in application/x-www-form-urlencoded, multipart/form-data, and application/json formats. Use this variable to inspect only data submitted in the request body without checking URL parameters. SecRequestBodyAccess must be enabled to access this variable. Note: This variable must be used in phase 2 or later. Otherwise, its value is empty. When SecParseXmlIntoArgs is On or OnlyArgs, it also includes data parsed from application/xml request bodies. Example:

ARGS_NAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: All parameter names Syntax: ARGS_NAMES | ARGS_NAMES:Key ARGS_NAMES contains the names (keys) of all request parameters, including both GET and POST parameters. This variable is used to detect whether parameter names themselves contain attack payloads, which is a common bypass technique where attackers may inject malicious code in parameter names. Example: # Detect SQL injection keywords in parameter names SecRule ARGS_NAMES "@pm select union insert delete drop" \ "id:1005,phase:2,deny,msg:'Parameter name contains SQL keyword'" # Limit parameter names to alphanumeric and underscores only SecRule ARGS_NAMES "!@rx ^[a-zA-Z0-9_\[\]\.]+$" \ "id:1006,phase:2,deny,msg:'Parameter name contains illegal characters'"

ARGS_GET_NAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: GET parameter names Syntax: ARGS_GET_NAMES | ARGS_GET_NAMES:Key ARGS_GET_NAMES contains only the names of parameters in the URL query string. Used to detect whether GET parameter names contain suspicious content without checking POST parameter names. Example: SecRule ARGS_GET_NAMES "@detectSQLi" "id:1007,phase:1,deny,msg:'SQL injection detected in GET parameter name'"

ARGS_POST_NAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: POST parameter names Syntax: ARGS_POST_NAMES | ARGS_POST_NAMES:Key ARGS_POST_NAMES contains only the names of parameters in the request body. Used to detect whether POST parameter names contain suspicious content. SecRequestBodyAccess must be enabled to access this variable. Example: SecRule ARGS_POST_NAMES "@detectXSS" "id:1008,phase:2,deny,msg:'XSS detected in POST parameter name'"

ARGS_COMBINED_SIZE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Combined size of all parameters Syntax: ARGS_COMBINED_SIZE Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule ARGS_COMBINED_SIZE "@eq 10" "id:1001,deny,msg:'Test'"

REQUEST_HEADERS

Mon, 01 Jan 0001 00:00:00 +0000

Description: HTTP request headers Syntax: REQUEST_HEADERS | REQUEST_HEADERS:HeaderName REQUEST_HEADERS contains all HTTP request headers. Specific headers can be accessed using REQUEST_HEADERS:HeaderName, such as User-Agent, Host, Content-Type, etc. Request headers are common injection points for attackers, so key headers should be inspected. Example: # Check for malicious patterns in User-Agent SecRule REQUEST_HEADERS:User-Agent "@pm nikto sqlmap nmap" \ "id:1009,phase:1,deny,msg:'Scanning tool User-Agent detected'" # Validate Host header format SecRule REQUEST_HEADERS:Host "!@rx ^[a-zA-Z0-9\.\-]+$" \ "id:1010,phase:1,deny,msg:'Invalid Host header'" # Check for XSS in Referer header SecRule REQUEST_HEADERS:Referer "@detectXSS" \ "id:1011,phase:1,deny,msg:'XSS detected in Referer header'"

REQUEST_HEADERS_NAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: HTTP request header names Syntax: REQUEST_HEADERS_NAMES REQUEST_HEADERS_NAMES contains the names of all request headers (excluding values). Used to detect abnormal custom headers or whether header names themselves contain attack payloads. Example: # Detect abnormal characters in header names SecRule REQUEST_HEADERS_NAMES "@rx [<>'\"]" \ "id:1012,phase:1,deny,msg:'Request header name contains illegal characters'"

REQUEST_COOKIES

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request Cookie values Syntax: REQUEST_COOKIES | REQUEST_COOKIES:CookieName REQUEST_COOKIES contains the values of all cookies in the request. Specific cookies can be accessed with REQUEST_COOKIES:name. Cookies are common attack vectors where attackers may inject malicious code or attempt session hijacking. Example: # Check all cookies for SQL injection SecRule REQUEST_COOKIES "@detectSQLi" \ "id:1013,phase:1,deny,msg:'SQL injection detected in cookie'" # Validate session cookie format SecRule REQUEST_COOKIES:SESSIONID "!@rx ^[a-zA-Z0-9]{32}$" \ "id:1014,phase:1,deny,msg:'Invalid session cookie format'"

REQUEST_COOKIES_NAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request Cookie names Syntax: REQUEST_COOKIES_NAMES REQUEST_COOKIES_NAMES contains the names of all cookies. Used to detect whether cookie names contain abnormal characters or attack payloads. Example: # Detect abnormal characters in cookie names SecRule REQUEST_COOKIES_NAMES "@rx [<>'\";()]" \ "id:1015,phase:1,deny,msg:'Cookie name contains illegal characters'"

REQUEST_BODY

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request body content Syntax: REQUEST_BODY REQUEST_BODY contains the raw request body data. Unlike ARGS_POST, REQUEST_BODY is unparsed raw data. When the request body processor cannot parse the content (such as unknown Content-Type), this variable can be used to inspect the raw data. SecRequestBodyAccess must be enabled to access this variable. Example: # Check for malicious patterns in the raw request body SecRule REQUEST_BODY "@rx

REQUEST_BODY_LENGTH

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request body length Syntax: REQUEST_BODY_LENGTH Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule REQUEST_BODY_LENGTH "@rx value" "id:1001,deny,msg:'Test'"

REQUEST_METHOD

Mon, 01 Jan 0001 00:00:00 +0000

Description: HTTP request method Syntax: REQUEST_METHOD REQUEST_METHOD contains the HTTP request method, such as GET, POST, PUT, DELETE, HEAD, OPTIONS, etc. Used to restrict allowed request methods for specific endpoints or detect abnormal HTTP methods. Example: # Allow only GET and POST methods SecRule REQUEST_METHOD "!@pm GET POST HEAD" \ "id:1018,phase:1,deny,msg:'HTTP method not allowed'" # Block TRACE method (prevent XST attacks) SecRule REQUEST_METHOD "@streq TRACE" \ "id:1019,phase:1,deny,msg:'TRACE method is forbidden'"

REQUEST_URI

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request URI (decoded) Syntax: REQUEST_URI REQUEST_URI contains the complete request URI, including the query string portion, and is URL-decoded. This is the primary variable for detecting attack payloads in URLs. Unlike REQUEST_URI_RAW, the content of this variable is already decoded, making it easier to match attack patterns directly. Example: # Detect directory traversal attacks in URL SecRule REQUEST_URI "@rx \.\." \ "id:1020,phase:1,deny,msg:'Directory traversal attack detected'" # Block access to sensitive files SecRule REQUEST_URI "@rx \.(conf|ini|log|bak)$" \ "id:1021,phase:1,deny,msg:'Attempt to access sensitive file'"

REQUEST_URI_RAW

Mon, 01 Jan 0001 00:00:00 +0000

Description: Raw request URI Syntax: REQUEST_URI_RAW REQUEST_URI_RAW contains the original, non-URL-decoded request URI. Used to detect encoding bypass attacks where attackers may use multiple encoding or abnormal encoding to bypass WAF detection. It is recommended to check both REQUEST_URI and REQUEST_URI_RAW for more comprehensive protection. Example: # Detect double encoding attacks in URL SecRule REQUEST_URI_RAW "@rx %25" \ "id:1022,phase:1,deny,msg:'Double encoding detected'" # Detect NULL byte injection SecRule REQUEST_URI_RAW "@rx %00" \ "id:1023,phase:1,deny,msg:'NULL byte injection detected'"

REQUEST_FILENAME

Mon, 01 Jan 0001 00:00:00 +0000

Description: Requested file path Syntax: REQUEST_FILENAME REQUEST_FILENAME contains the file path portion of the request URI, excluding the query string. This is a normalized path extracted from the URI, used to detect access to specific files or directories. Note: This variable is automatically URL-decoded once. Example: # Block access to admin directory SecRule REQUEST_FILENAME "@beginsWith /admin" \ "id:1024,phase:1,deny,msg:'Access to admin directory forbidden'" # Block access to PHP configuration files SecRule REQUEST_FILENAME "@endsWith .htaccess" \ "id:1025,phase:1,deny,msg:'Access to .htaccess forbidden'"

REQUEST_BASENAME

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request file basename Syntax: REQUEST_BASENAME REQUEST_BASENAME contains only the filename portion of the request path, excluding the directory path. For example, for /path/to/file.php, this variable’s value is file.php. Used to detect specific filenames or file extensions. Note: This variable is automatically URL-decoded once. Example: # Block access to backup files SecRule REQUEST_BASENAME "@rx \.(bak|backup|old|orig)$" \ "id:1026,phase:1,deny,msg:'Access to backup file forbidden'" # Block execution of shell scripts SecRule REQUEST_BASENAME "@endsWith .sh" \ "id:1027,phase:1,deny,msg:'Shell script execution forbidden'"

REQUEST_PROTOCOL

Mon, 01 Jan 0001 00:00:00 +0000

Description: HTTP request protocol Syntax: REQUEST_PROTOCOL REQUEST_PROTOCOL contains the HTTP protocol version used in the request, such as HTTP/1.0, HTTP/1.1, or HTTP/2.0. Used to detect protocol violations or enforce specific protocol versions. Example: # Reject HTTP/1.0 requests SecRule REQUEST_PROTOCOL "@streq HTTP/1.0" \ "id:1028,phase:1,deny,msg:'HTTP/1.0 not supported'" # Detect abnormal protocol SecRule REQUEST_PROTOCOL "!@rx ^HTTP/[12]\.[0-9]$" \ "id:1029,phase:1,deny,msg:'Invalid HTTP protocol'"

REQUEST_LINE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Full request line Syntax: REQUEST_LINE REQUEST_LINE contains the complete HTTP request line in the format “METHOD URI PROTOCOL”, for example “GET /index.html HTTP/1.1”. Used for comprehensive inspection of abnormal content in the request line. Example: # Detect control characters in request line SecRule REQUEST_LINE "@rx [\x00-\x08\x0b\x0c\x0e-\x1f]" \ "id:1030,phase:1,deny,msg:'Request line contains control characters'" # Detect excessively long request line SecRule REQUEST_LINE "@gt 8192" "t:length,id:1031,phase:1,deny,msg:'Request line too long'"

QUERY_STRING

Mon, 01 Jan 0001 00:00:00 +0000

Description: Query string Syntax: QUERY_STRING QUERY_STRING contains the query string portion of the URL after the question mark (?), excluding the question mark itself. This is the original query string, not parsed into individual parameters. Used to detect abnormal patterns in the overall query string. Example: # Detect SQL injection in query string SecRule QUERY_STRING "@detectSQLi" \ "id:1032,phase:1,deny,msg:'SQL injection detected in query string'" # Limit query string length SecRule QUERY_STRING "@gt 2048" "t:length,id:1033,phase:1,deny,msg:'Query string too long'"

FULL_REQUEST

Mon, 01 Jan 0001 00:00:00 +0000

Description: Complete request data Syntax: FULL_REQUEST Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule FULL_REQUEST "@rx value" "id:1001,deny,msg:'Test'"

FULL_REQUEST_LENGTH

Mon, 01 Jan 0001 00:00:00 +0000

Description: Complete request length Syntax: FULL_REQUEST_LENGTH Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule FULL_REQUEST_LENGTH "@gt 10485760" "id:1001,deny,msg:'Test'"

RESPONSE_BODY

Mon, 01 Jan 0001 00:00:00 +0000

Description: HTTP response body Syntax: RESPONSE_BODY RESPONSE_BODY contains the server’s response body content. SecResponseBodyAccess must be enabled to access this variable. Used to detect sensitive information leakage, malicious content, or abnormal patterns in responses. Use in phase:4 (response body phase). Example: # Detect credit card number leakage in response SecRule RESPONSE_BODY "@rx \b(?:\d{4}[-\s]?){3}\d{4}\b" \ "id:1034,phase:4,deny,msg:'Credit card number leakage detected'" # Detect SQL error message leakage SecRule RESPONSE_BODY "@pm mysql_error ora-00 sql syntax error" \ "id:1035,phase:4,deny,msg:'Database error message leakage detected'"

RESPONSE_HEADERS

Mon, 01 Jan 0001 00:00:00 +0000

Description: Response headers Syntax: RESPONSE_HEADERS | RESPONSE_HEADERS:Key This variable references response header values and behaves the same way as request headers in REQUEST_HEADERS. Example: SecRule RESPONSE_HEADERS:User-Agent "@rx box" "id:1001,deny,msg:'Test'"

RESPONSE_HEADERS_NAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: Response header names Syntax: RESPONSE_HEADERS_NAMES | RESPONSE_HEADERS_NAMES:Key This variable references response header names and behaves the same way as request header names in REQUEST_HEADERS_NAMES. Example: SecRule RESPONSE_HEADERS_NAMES:User-Agent "@rx box" "id:1001,deny,msg:'Test'"

RESPONSE_STATUS

Mon, 01 Jan 0001 00:00:00 +0000

Description: HTTP response status code Syntax: RESPONSE_STATUS RESPONSE_STATUS contains the HTTP status code returned by the server, such as 200, 404, 500, etc. Used to detect abnormal responses or implement security policies based on status codes. Available in phase:3 (response headers phase) or later. Example: # Log all 5xx errors SecRule RESPONSE_STATUS "@rx ^5" \ "id:1036,phase:3,pass,log,msg:'Server error: %{RESPONSE_STATUS}'" # Detect information leakage (some applications may include debug info with 500 responses) SecRule RESPONSE_STATUS "@eq 500" \ "id:1037,phase:3,pass,log,msg:'Internal server error detected'"

RESPONSE_PROTOCOL

Mon, 01 Jan 0001 00:00:00 +0000

Description: Response protocol Syntax: RESPONSE_PROTOCOL This variable contains HTTP response protocol information. Example: SecRule RESPONSE_PROTOCOL "@rx value" "id:1001,deny,msg:'Test'"

RESPONSE_CONTENT_LENGTH

Mon, 01 Jan 0001 00:00:00 +0000

Description: Response content length Syntax: RESPONSE_CONTENT_LENGTH This variable returns the content-length response header and is equivalent to RESPONSE_HEADERS:content-length. Example: SecRule RESPONSE_CONTENT_LENGTH "@rx value" "id:1001,deny,msg:'Test'"

RESPONSE_CONTENT_TYPE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Response content type Syntax: RESPONSE_CONTENT_TYPE This variable returns the content-type response header and is equivalent to RESPONSE_HEADERS:content-type. Example: SecRule RESPONSE_CONTENT_TYPE "@rx value" "id:1001,deny,msg:'Test'"

REMOTE_ADDR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Remote client IP address Syntax: REMOTE_ADDR REMOTE_ADDR contains the IP address of the client making the request. This is one of the most commonly used variables for implementing IP blacklists/whitelists, rate limiting, and other security policies. Often used with the @ipMatch operator to match IP addresses or CIDR ranges. Example: # IP whitelist - skip checks for internal IPs SecRule REMOTE_ADDR "@ipMatch 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16" \ "id:1038,phase:1,pass,nolog,allow" # IP blacklist - block specific IPs SecRule REMOTE_ADDR "@ipMatch 1.2.3.4,5.6.7.8" \ "id:1039,phase:1,deny,status:403,msg:'IP has been banned'"

REMOTE_HOST

Mon, 01 Jan 0001 00:00:00 +0000

Description: Client hostname Syntax: REMOTE_HOST Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule REMOTE_HOST "@rx value" "id:1001,deny,msg:'Test'"

REMOTE_PORT

Mon, 01 Jan 0001 00:00:00 +0000

Description: Client port Syntax: REMOTE_PORT Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule REMOTE_PORT "@rx value" "id:1001,deny,msg:'Test'"

REMOTE_USER

Mon, 01 Jan 0001 00:00:00 +0000

Description: Authenticated username Syntax: REMOTE_USER Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule REMOTE_USER "@rx value" "id:1001,deny,msg:'Test'"

SERVER_ADDR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Server IP address Syntax: SERVER_ADDR Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule SERVER_ADDR "@rx value" "id:1001,deny,msg:'Test'"

SERVER_NAME

Mon, 01 Jan 0001 00:00:00 +0000

Description: Server name Syntax: SERVER_NAME Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule SERVER_NAME "@rx value" "id:1001,deny,msg:'Test'"

SERVER_PORT

Mon, 01 Jan 0001 00:00:00 +0000

Description: Server port Syntax: SERVER_PORT Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule SERVER_PORT "@rx value" "id:1001,deny,msg:'Test'"

AUTH_TYPE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Authentication type Syntax: AUTH_TYPE Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule AUTH_TYPE "@rx value" "id:1001,deny,msg:'Test'"

PATH_INFO

Mon, 01 Jan 0001 00:00:00 +0000

Description: Path information Syntax: PATH_INFO PATH_INFO contains additional path information after the file path in the URL and before the query string. For example, for /cgi-bin/script.py/extra/path, PATH_INFO’s value is /extra/path. In RESTful APIs, this variable may contain routing parameters. Note: This variable is automatically URL-decoded once. Example: # Detect directory traversal in PATH_INFO SecRule PATH_INFO "@contains .." \ "id:1040,phase:1,deny,msg:'Directory traversal detected in PATH_INFO'"

MULTIPART_FILENAME

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart filename Syntax: MULTIPART_FILENAME Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_FILENAME "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_NAME

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart field name Syntax: MULTIPART_NAME Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_NAME "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_PART_HEADERS

Mon, 01 Jan 0001 00:00:00 +0000

Description: Headers of multipart parts Syntax: MULTIPART_PART_HEADERS | MULTIPART_PART_HEADERS:HeaderName MULTIPART_PART_HEADERS contains the header information of each part in a multipart/form-data request. Used to detect abnormal content in headers like Content-Type and Content-Disposition of uploaded file parts. Example: # Detect abnormal Content-Type in multipart headers SecRule MULTIPART_PART_HEADERS "@rx application/(php|x-php|x-httpd-php)" \ "id:1041,phase:2,deny,msg:'Uploaded file has abnormal Content-Type'"

MULTIPART_CRLF_LF_LINES

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart CRLF/LF line count Syntax: MULTIPART_CRLF_LF_LINES Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_CRLF_LF_LINES "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_STRICT_ERROR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart strict parsing error flag Syntax: MULTIPART_STRICT_ERROR MULTIPART_STRICT_ERROR is a composite flag variable set to 1 when any strict mode violations are detected during multipart request body parsing. It combines multiple multipart error flags (such as MULTIPART_UNMATCHED_BOUNDARY, etc.) for quick determination of whether a multipart request contains anomalies. This is an important checkpoint for preventing file upload bypass attacks. Example: # Reject requests with multipart parsing errors SecRule MULTIPART_STRICT_ERROR "!@eq 0" \ "id:1042,phase:2,deny,status:403,msg:'Multipart request parsing anomaly'"

MULTIPART_UNMATCHED_BOUNDARY

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart unmatched boundary flag Syntax: MULTIPART_UNMATCHED_BOUNDARY MULTIPART_UNMATCHED_BOUNDARY is set to 1 when unmatched boundary markers appear in the multipart request body. Unmatched boundaries usually indicate the request has been tampered with or constructed abnormally, possibly an attacker attempting to bypass upload file detection. Example: # Reject multipart requests with unmatched boundaries SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \ "id:1043,phase:2,deny,status:403,msg:'Multipart boundary mismatch'"

MULTIPART_BOUNDARY_QUOTED

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart boundary quoting error Syntax: MULTIPART_BOUNDARY_QUOTED Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_BOUNDARY_QUOTED "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_BOUNDARY_WHITESPACE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart boundary whitespace error Syntax: MULTIPART_BOUNDARY_WHITESPACE Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_BOUNDARY_WHITESPACE "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_DATA_BEFORE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Data before multipart boundary Syntax: MULTIPART_DATA_BEFORE Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_DATA_BEFORE "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_DATA_AFTER

Mon, 01 Jan 0001 00:00:00 +0000

Description: Data after multipart boundary Syntax: MULTIPART_DATA_AFTER Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_DATA_AFTER "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_HEADER_FOLDING

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart header folding Syntax: MULTIPART_HEADER_FOLDING Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_HEADER_FOLDING "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_LF_LINE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart LF line Syntax: MULTIPART_LF_LINE Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_LF_LINE "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_MISSING_SEMICOLON

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart missing semicolon Syntax: MULTIPART_MISSING_SEMICOLON Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_MISSING_SEMICOLON "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_INVALID_QUOTING

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart invalid quoting Syntax: MULTIPART_INVALID_QUOTING Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_INVALID_QUOTING "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_INVALID_PART

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart invalid part Syntax: MULTIPART_INVALID_PART Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_INVALID_PART "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_INVALID_HEADER_FOLDING

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart invalid header folding Syntax: MULTIPART_INVALID_HEADER_FOLDING Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_INVALID_HEADER_FOLDING "@rx value" "id:1001,deny,msg:'Test'"

MULTIPART_FILE_LIMIT_EXCEEDED

Mon, 01 Jan 0001 00:00:00 +0000

Description: Multipart file count limit exceeded Syntax: MULTIPART_FILE_LIMIT_EXCEEDED Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MULTIPART_FILE_LIMIT_EXCEEDED "@rx value" "id:1001,deny,msg:'Test'"

REQBODY_ERROR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request body error flag Syntax: REQBODY_ERROR REQBODY_ERROR is set to 1 when errors occur during request body parsing. For example, when JSON format is invalid, XML format is incorrect, or multipart data is abnormal, this variable will be set. Used to detect and block requests with invalid request bodies in phase:2. Note: This variable is not currently assigned and remains at the default value 0. Example: # Reject requests with failed body parsing SecRule REQBODY_ERROR "!@eq 0" \ "id:1044,phase:2,deny,status:400,msg:'Request body parsing failed: %{REQBODY_ERROR_MSG}'"

REQBODY_ERROR_MSG

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request body error message Syntax: REQBODY_ERROR_MSG REQBODY_ERROR_MSG contains the error description when request body parsing fails. Typically used together with REQBODY_ERROR to log the specific error reason for debugging and analysis. Can be referenced in the msg action via %{REQBODY_ERROR_MSG}. Note: This variable is not currently assigned, so its default value remains empty. Example: # Log detailed request body parsing error information SecRule REQBODY_ERROR "!@eq 0" \ "id:1045,phase:2,pass,log,msg:'Request body error: %{REQBODY_ERROR_MSG}'"

REQBODY_PROCESSOR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request body processor type Syntax: REQBODY_PROCESSOR REQBODY_PROCESSOR contains the name of the request body processor used for the current request, such as URLENCODED, MULTIPART, JSON, or XML. When the Content-Type request header is application/x-www-form-urlencoded or multipart/form-data, WGE automatically sets this variable to URLENCODED or MULTIPART respectively. Users can also manually specify processors such as JSON via the ctl:requestBodyProcessor action. Example: # Configure different request body processors based on Content-Type SecRule REQUEST_HEADERS:Content-Type "^(?:application(?:/soap\\+|/)|text/)xml" \ "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML" SecRule REQUEST_HEADERS:Content-Type "^application/json" \ "id:'200001',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=JSON"

REQBODY_PROCESSOR_ERROR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request body processor error Syntax: REQBODY_PROCESSOR_ERROR Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule REQBODY_PROCESSOR_ERROR "@rx value" "id:1001,deny,msg:'Test'"

INBOUND_DATA_ERROR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Request body length limit exceeded error Syntax: INBOUND_DATA_ERROR When the request body size exceeds the value configured by the SecRequestBodyLimit directive, this variable is set to 1. Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule INBOUND_DATA_ERROR "@rx value" "id:1001,deny,msg:'Test'"

OUTBOUND_DATA_ERROR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Response body length limit exceeded error Syntax: OUTBOUND_DATA_ERROR When the response body size exceeds the value configured by the SecResponseBodyLimit directive, this variable is set to 1. Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule OUTBOUND_DATA_ERROR "@rx value" "id:1001,deny,msg:'Test'"

URLENCODED_ERROR

Mon, 01 Jan 0001 00:00:00 +0000

Description: URL encoding error Syntax: URLENCODED_ERROR Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule URLENCODED_ERROR "@rx value" "id:1001,deny,msg:'Test'"

STATUS_LINE

Mon, 01 Jan 0001 00:00:00 +0000

Description: HTTP status line Syntax: STATUS_LINE Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule STATUS_LINE "@rx value" "id:1001,deny,msg:'Test'"

HIGHEST_SEVERITY

Mon, 01 Jan 0001 00:00:00 +0000

Description: Highest severity level Syntax: HIGHEST_SEVERITY Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule HIGHEST_SEVERITY "@rx value" "id:1001,deny,msg:'Test'"

MSC_PCRE_LIMITS_EXCEEDED

Mon, 01 Jan 0001 00:00:00 +0000

Description: PCRE limits exceeded flag Syntax: MSC_PCRE_LIMITS_EXCEEDED Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MSC_PCRE_LIMITS_EXCEEDED "@rx value" "id:1001,deny,msg:'Test'"

ENV

Mon, 01 Jan 0001 00:00:00 +0000

Description: Environment variable collection Syntax: ENV Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule ENV "@rx value" "id:1001,deny,msg:'Test'"

GEO

Mon, 01 Jan 0001 00:00:00 +0000

Description: Geolocation information Syntax: GEO Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule GEO "@rx value" "id:1001,deny,msg:'Test'"

RULE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Current rule information Syntax: RULE The RULE variable provides access to the metadata of the currently executing rule. Specific properties can be accessed via subkeys, such as RULE.id (rule ID), RULE.phase (the phase where the rule runs), and RULE.operator_value (the rule operator’s argument). It is mainly used to reference the current rule’s own information in logs and dynamic messages. Example: # Reference rule information in logs SecRule ARGS "@detectSQLi" \ "id:1047,phase:2,deny,msg:'Rule %{RULE.id} triggered: SQL injection detected',\ severity:CRITICAL,tag:'attack-sqli'"

SESSIONID

Mon, 01 Jan 0001 00:00:00 +0000

Description: Session ID Syntax: SESSIONID Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule SESSIONID "@rx value" "id:1001,deny,msg:'Test'"

USERID

Mon, 01 Jan 0001 00:00:00 +0000

Description: User ID Syntax: USERID This variable contains the value set with setuid. Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule USERID "@rx value" "id:1001,deny,msg:'Test'"

WEBAPPID

Mon, 01 Jan 0001 00:00:00 +0000

Description: Web application ID Syntax: WEBAPPID Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule WEBAPPID "@rx value" "id:1001,deny,msg:'Test'"

XML

Mon, 01 Jan 0001 00:00:00 +0000

Description: XML request body data Syntax: XML:/xpath/expression The XML variable is used to access specific nodes in XML request bodies via XPath expressions. The XML parser must first be enabled via ctl:requestBodyProcessor=XML. Supports full XPath syntax, including attribute access, text node extraction, etc. Example: # Enable XML parsing SecRule REQUEST_HEADERS:Content-Type "@contains xml" \ "id:1048,phase:1,pass,nolog,ctl:requestBodyProcessor=XML" # Check XML nodes using XPath SecRule XML:/root/user/name/text() "@detectSQLi" \ "id:1049,phase:2,deny,msg:'SQL injection detected in XML node'"

MODSEC_BUILD

Mon, 01 Jan 0001 00:00:00 +0000

Description: ModSecurity build version Syntax: MODSEC_BUILD Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule MODSEC_BUILD "@rx value" "id:1001,deny,msg:'Test'"

FILES

Mon, 01 Jan 0001 00:00:00 +0000

Description: Uploaded file names Syntax: FILES | FILES:fieldname FILES contains the original filenames of files uploaded via multipart/form-data. You can access files uploaded in a specific form field using FILES:fieldname. This variable is central to file upload security checks and can be used to verify file extensions, filename formats, etc. Example: # Check for dangerous extensions in uploaded files SecRule FILES "@rx \.(php|jsp|asp|exe|sh|bat)$" \ "id:1050,phase:2,deny,status:403,msg:'Uploading this file type is forbidden'"

FILES_NAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: Uploaded file names Syntax: FILES_NAMES | FILES_NAMES:Key FILES_NAMES contains the form field names corresponding to all uploaded files. Can be used to detect anomalous content in form field names, or to verify that uploaded files are submitted through expected form fields. Example: # Ensure files are only uploaded through the 'avatar' field SecRule FILES_NAMES "!@streq avatar" \ "id:1051,phase:2,deny,msg:'Illegal file upload field'"

FILES_SIZES

Mon, 01 Jan 0001 00:00:00 +0000

Description: Uploaded file sizes Syntax: FILES_SIZES Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule FILES_SIZES "@rx value" "id:1001,deny,msg:'Test'"

FILES_TMPNAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: Uploaded file temporary names Syntax: FILES_TMPNAMES Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule FILES_TMPNAMES "@rx value" "id:1001,deny,msg:'Test'"

FILES_TMP_CONTENT

Mon, 01 Jan 0001 00:00:00 +0000

Description: Uploaded file temporary content Syntax: FILES_TMP_CONTENT | FILES_TMP_CONTENT:Key Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule FILES_TMP_CONTENT "@rx value" "id:1001,deny,msg:'Test'"

FILES_COMBINED_SIZE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Combined size of all uploaded files Syntax: FILES_COMBINED_SIZE Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule FILES_COMBINED_SIZE "@rx value" "id:1001,deny,msg:'Test'"

TX

Mon, 01 Jan 0001 00:00:00 +0000

Description: Transaction variable collection Syntax: TX:key TX (Transaction) is the most commonly used collection variable, used to store and pass data within a single transaction (request-response cycle). TX variables are automatically destroyed when the transaction ends. Set via the setvar action and accessed via TX:key. TX:0 through TX:9 are special variables that automatically store regex capture group results from the @rx operator. Additionally, TX variables are commonly used to implement anomaly scoring patterns (e.g., tx.anomaly_score).

GLOBAL

Mon, 01 Jan 0001 00:00:00 +0000

Description: Global variable collection Syntax: GLOBAL:key The GLOBAL collection is used to store global persistent data across transactions. Unlike TX, GLOBAL variables persist across multiple requests and can be used to implement global counters, global status flags, etc. Must be initialized via the initcol action before use. This variable is not recommended at the moment because its parsing and assignment behavior still has some issues. Example: # Initialize global collection SecAction "id:1055,phase:1,pass,nolog,initcol:GLOBAL=global" # Global request count SecRule GLOBAL "@eq 100" "id:1056,phase:1,deny,nolog"

IP

Mon, 01 Jan 0001 00:00:00 +0000

Description: IP address collection Syntax: IP:key The IP collection is used to store persistent data associated with client IP addresses. Commonly used to implement IP-level request rate limiting, IP reputation scoring, etc. Needs to be initialized via initcol:IP=%{REMOTE_ADDR}. Data in the IP collection persists across multiple requests from the same client IP. This variable is not recommended at the moment because its parsing and assignment behavior still has some issues.

SESSION

Mon, 01 Jan 0001 00:00:00 +0000

Description: Session variable collection Syntax: SESSION:key The SESSION collection is used to store persistent data associated with user sessions. You need to first set the session identifier via the setsid action, then initialize via initcol:SESSION=%{SESSIONID}. Can be used to track session-level behavior and implement session-level access control. This variable is not recommended at the moment because its parsing and assignment behavior still has some issues. Example: # Set session ID and initialize SecRule REQUEST_COOKIES:PHPSESSID "@rx (.+)" \ "id:1060,phase:1,pass,nolog,setsid:%{TX.1},initcol:SESSION=%{SESSIONID}"

USER

Mon, 01 Jan 0001 00:00:00 +0000

Description: User variable collection Syntax: USER:key The USER collection is used to store persistent data associated with authenticated users. You need to first set the user identifier via the setuid action and initialize it. Can be used to track specific user behavior patterns and implement user-level access control. This variable is not recommended at the moment because its parsing and assignment behavior still has some issues. Example: # Set user ID SecRule ARGS_POST:username "@rx (.+)" \ "id:1061,phase:2,pass,nolog,setuid:%{TX.1}"

RESOURCE

Mon, 01 Jan 0001 00:00:00 +0000

Description: Resource variable collection Syntax: RESOURCE:key The RESOURCE collection is used to store persistent data associated with specific resources (such as URL paths). Can be used to track access patterns for specific resources, such as the call frequency of a particular API endpoint. This variable is not recommended at the moment because its parsing and assignment behavior still has some issues. Example: # Initialize resource collection SecAction "id:1062,phase:1,pass,nolog,initcol:RESOURCE=%{REQUEST_FILENAME}"

MATCHED_VAR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Last matched variable value Syntax: MATCHED_VAR MATCHED_VAR contains the value of the last variable that matched successfully in the rule. When a rule checks multiple variables (e.g., ARGS) and finds a match, this variable holds the specific value that triggered the match. Commonly used for logging and debugging to understand exactly what content triggered the rule. Note: By default, MATCHED_VAR returns the last value matched by the parent rule. If there is no parent rule, it returns the last value matched by the current rule.

MATCHED_VAR_NAME

Mon, 01 Jan 0001 00:00:00 +0000

Description: Last matched variable name Syntax: MATCHED_VAR_NAME MATCHED_VAR_NAME contains the full name of the last variable that matched successfully. For example, if ARGS:username triggered the rule, the value of MATCHED_VAR_NAME would be “ARGS:username”. Used together with MATCHED_VAR to fully record both the location and content that triggered the rule. Note: By default, MATCHED_VAR_NAME returns the full name matched by the parent rule. If there is no parent rule, it returns the full name matched by the current rule.

MATCHED_VARS

Mon, 01 Jan 0001 00:00:00 +0000

Description: All matched variable values Syntax: MATCHED_VARS MATCHED_VARS is a collection variable containing all variable values that matched successfully in the current rule. Unlike MATCHED_VAR, when a rule matches multiple values (e.g., multiple parameters containing malicious content), MATCHED_VARS contains all these values. Can be used in chain rules to further inspect all matched content. Note: By default, MATCHED_VARS returns the values matched by the parent rule. If there is no parent rule, it returns the values matched by the current rule.

MATCHED_VARS_NAMES

Mon, 01 Jan 0001 00:00:00 +0000

Description: All matched variable names Syntax: MATCHED_VARS_NAMES MATCHED_VARS_NAMES is a collection variable containing the names of all variables that matched successfully in the current rule. Unlike MATCHED_VAR_NAME, when a rule matches multiple variables, this variable contains all matched variable names. Note: By default, MATCHED_VARS_NAMES returns the full names matched by the parent rule. If there is no parent rule, it returns the full names matched by the current rule. Example:

UNIQUE_ID

Mon, 01 Jan 0001 00:00:00 +0000

Description: Unique request ID Syntax: UNIQUE_ID UNIQUE_ID contains a unique identifier generated by WGE for each request. This ID is used in logs to correlate multiple records from the same request, facilitating post-incident analysis and debugging. Can be referenced in the msg action via %{UNIQUE_ID} to track specific requests. Example: # Log the request ID SecRule ARGS "@detectSQLi" \ "id:1067,phase:2,deny,msg:'[%{UNIQUE_ID}] SQL injection attack'"

DURATION

Mon, 01 Jan 0001 00:00:00 +0000

Description: Transaction processing duration Syntax: DURATION Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule DURATION "@rx value" "id:1001,deny,msg:'Test'"

TIME

Mon, 01 Jan 0001 00:00:00 +0000

Description: Current time (HH:MM:SS formatted string) Syntax: TIME Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME "@rx value" "id:1001,deny,msg:'Test'"

TIME_EPOCH

Mon, 01 Jan 0001 00:00:00 +0000

Description: Unix timestamp Syntax: TIME_EPOCH Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME_EPOCH "@rx value" "id:1001,deny,msg:'Test'"

TIME_YEAR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Current year value Syntax: TIME_YEAR Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME_YEAR "@rx value" "id:1001,deny,msg:'Test'"

TIME_MON

Mon, 01 Jan 0001 00:00:00 +0000

Description: Current month value Syntax: TIME_MON Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME_MON "@rx value" "id:1001,deny,msg:'Test'"

TIME_DAY

Mon, 01 Jan 0001 00:00:00 +0000

Description: Day of the month Syntax: TIME_DAY Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME_DAY "@rx value" "id:1001,deny,msg:'Test'"

TIME_HOUR

Mon, 01 Jan 0001 00:00:00 +0000

Description: Current hour value Syntax: TIME_HOUR Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME_HOUR "@rx value" "id:1001,deny,msg:'Test'"

TIME_MIN

Mon, 01 Jan 0001 00:00:00 +0000

Description: Current minute value Syntax: TIME_MIN Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME_MIN "@rx value" "id:1001,deny,msg:'Test'"

TIME_SEC

Mon, 01 Jan 0001 00:00:00 +0000

Description: Current second value Syntax: TIME_SEC Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME_SEC "@rx value" "id:1001,deny,msg:'Test'"

TIME_WDAY

Mon, 01 Jan 0001 00:00:00 +0000

Description: Current weekday value Syntax: TIME_WDAY Implementation Status: No WGE can parse this directive, but the functionality is not implemented yet. Example: SecRule TIME_WDAY "@rx value" "id:1001,deny,msg:'Test'"