Skip to content

ALB WAF rule selectors reference

Last updated on

This page enumerates every selector value that you can use inside a custom rule condition on the STACKIT Application Load Balancer Web Application Firewall (ALB WAF). It complements the Rule structure section of the ALB WAF features page, which explains how the selectors combine into a full rule.

The following diagram shows where the selectors on this page fit into the ALB WAF object model. An ALB listener attaches to a single ALB WAF configuration, which can reference at most one managed rule set (for example, the OWASP Core Rule Set) and at most one custom rule group. A custom rule group holds rules, and each rule contains one or more conditions built from the three selector kinds documented below.

Diagram

A single condition inside a custom rule combines three selectors:

  • A variable — the part of the HTTP transaction to inspect.
  • Zero or more transformations — normalization steps applied to the variable before comparison.
  • An operator — the comparison logic executed against the transformed variable.

Only the values listed on this page are accepted by the ALB WAF API. Coraza SecLang defines additional selectors that STACKIT does not expose today; requests using unsupported values are rejected at validation time.

A variable identifies which element of the HTTP transaction the condition inspects. Provide the variable as condition.variable.type in the API. For map-shaped variables (headers, cookies, arguments), you can further narrow the scope to a single key by setting condition.variable.value (for example, Host inside VARIABLE_REQUEST_HEADERS).

The following tables list every supported variable, grouped by the transaction side it targets.

Variables in this group inspect data returned by your backend to the client. They are useful for detecting information disclosure or backend error patterns.

Variables in this group inspect data sent by the client to your backend. They cover the request line, headers, cookies, and body.

Variables in this group cover request arguments, transport-level attributes, and internal engine state exposed for rule authoring.

An operator defines how a transformed variable is compared against a provided value. Specify the operator in condition.operator.type and the comparison argument in condition.operator.value.

The following table lists the supported operators and their expected value types. Comparison operators (OPERATOR_EQ, OPERATOR_GE, OPERATOR_GT, OPERATOR_LE, OPERATOR_LT) treat both sides as integers.

A transformation normalizes the variable before the operator runs. Provide transformations as an ordered list in condition.transformations; the engine applies them in the order given. Use TRANSFORMATION_NONE at the beginning of the list to make the pipeline explicit and avoid inheriting any default.

The following table lists every supported transformation.