Variables

Variables represent the sources of data in WGE. Different variables correspond to different source data, and most variables come from some part of the request or response.

1. Variable Data Types

In WGE, variables have two data types:

• String
• Integer

Most variables are string values, such as REQUEST_METHOD and REQUEST_URI.

Integer data is produced in the following cases:

1. A user-defined TX variable is set to a numeric value.
2. &variable_name is used to obtain the number of elements in a collection variable.

When an operator expects an integer but receives a string, it will not match, unless the negation flag is also present. When writing rules, make sure the variable type matches the operator.

2. Scalar Variables and Collection Variables

From the perspective of storage structure, variables can be divided into two categories.

1. Scalar Variables

A scalar variable stores only one value.

For example:

• REQUEST_METHOD — a request has only one request method.
• REMOTE_ADDR — a request maps to only one client address.

2. Collection Variables

A collection variable stores multiple data items.

For example:

• REQUEST_HEADERS — a request usually contains multiple headers.
• ARGS — a request may contain multiple parameters.

Collection variables support additional access patterns, described below.

3. Phase Restrictions

Some variables can be accessed only in specific phases.

For example:

• Response-related variables are always empty during request phases.
• Request-related variables may be meaningless during response phases.

When writing rules, make sure the variable contains valid data in the phase where it is used.

4. Working with Collection Variables

1. Getting the Number of Elements

Use &variable_name to get the number of elements in a collection variable. It can also be used on scalar variables to determine whether that variable has a value.

# Block requests with more than 5 headers
SecRule &REQUEST_HEADERS "@gt 5" "id:1001,phase:2,t:none,deny"

# Check whether the Referer header exists
SecRule &REQUEST_HEADERS:referer "@eq 1" "id:1002,phase:2,t:none,deny"

2. Specifying a Subvariable

Use variable_name:subvariable_name to reference a specific element in a collection.

Subvariable names support several forms:

• Plain strings
• Regular expressions wrapped in /.../
• Files specified with @...@
• Macro variables

Example:

# Plain string subvariable name
SecRule REQUEST_HEADERS:host "@rx admin" "id:1001,phase:2,t:none,deny"

# Regex subvariable name
SecRule REQUEST_HEADERS:/^host$/ "@rx admin" "id:1002,phase:2,t:none,deny"

# File-based subvariable name
SecRule REQUEST_HEADERS:@headers.data@ "@rx admin" "id:1003,phase:2,t:none,deny"

# Macro-based subvariable name
SecRule REQUEST_HEADERS:%{tx.name} "@rx admin" "id:1003,phase:2,t:none,deny"

Note:

• Files specified with @...@ support both string and regex matching. The behavior is the same as the pmFromFile operator. See pmFromFile for more information.
• Plain string subvariable names are supported for most variables, even scalar variables, but the other forms are supported only by collection variables.

3. Excluding Variables

Use !variable_name to exclude a specific variable.

This is usually used together with collection variables.

# Inspect all request headers except Host
SecRule REQUEST_HEADERS|!REQUEST_HEADERS:host "@rx admin" "id:1001,phase:2,t:none,deny"

The exclusion mechanism is commonly used to:

• Ignore specific fields
• Apply “allowlist exclusion” to collection variables