ALB WAF features

Last updated on Aug 5, 2026

This page describes the features and configuration surface of the STACKIT Application Load Balancer Web Application Firewall (ALB WAF). If you are new to the ALB WAF, first read Basic concepts of the ALB WAF.

The ALB WAF is powered by the Coraza engine. Its rule model follows the SecLang grammar, but STACKIT exposes it through a structured JSON API so that you do not need to author raw SecLang directives yourself.

Feature overview and availability

The following table lists each feature area and where it is available today. Rows marked WIP indicate that the interface is being built and is not yet stable for production use.

Feature area	API	SDK	Terraform	Portal
ALB WAF configuration	Available	Available	WIP	WIP
Listener attachment	Available	Available	Available	WIP
Managed rule sets (OWASP CRS)	Available	WIP	WIP	WIP
Per-rule mode override (enable/disable/log-only)	Available	WIP	WIP	WIP
Custom rule groups (SecLang abstraction)	Available	WIP	WIP	WIP
Project quotas for ALB WAF, MRS, and CRG	Available	WIP	WIP	WIP

ALB WAF configuration

An ALB WAF configuration (waf_config) is the top-level object that binds together the rule sources that inspect your traffic. Each configuration:

Belongs to a single project and region.
Has a unique, DNS-compatible name (1-63 characters, lowercase alphanumeric characters and hyphens).
Can reference at most one managed rule set by name and at most one custom rule group by name.
Can be attached to any number of ALB listeners in the same project.
Accepts up to 64 user-defined labels for organizational metadata.

A configuration references a managed rule set through managedRuleSetName and a custom rule group through customRuleGroupName. Both are optional individually, but at least one must be set for the configuration to inspect traffic.

For endpoints and the full request and response schema of the configuration object, see v1beta API — ALB WAF configurations.

Listener attachment

The ALB WAF is enabled on a per-listener basis on the Application Load Balancer. To activate protection, set the listener’s wafConfigName property to the name of an existing ALB WAF configuration in the same project and region.

The listener starts inspecting all Layer 7 traffic that reaches that port before it is forwarded to your target pools. Removing the field disables the ALB WAF for that listener without deleting the ALB WAF configuration.

For the full listener payload and the position of wafConfigName, see the v2 API — ALB listeners reference.

Managed rule sets

A managed rule set (MRS) is a pre-built collection of rules maintained for you. It provides baseline protection without requiring you to author individual detection logic. Each MRS is a named object per project and region, and any ALB WAF configuration in the same scope can reference it.

Today the ALB WAF ships the following managed rule set type:

Type	Source	Purpose
`TYPE_OWASP_CRS`	OWASP Core Rule Set (CRS)	Broad protection against the OWASP Top 10 threats such as SQL injection, cross-site scripting (XSS), remote code execution, and local file inclusion.

When you retrieve an MRS, the response includes the pinned CRS version (for example, v4.14.0) and a map of rule groups, each keyed by its group ID (for example, group 942 covers SQL Injection). Each group contains a map of individual rules, keyed by rule ID (for example, 942100), with the fields description, severity (CRITICAL, ERROR, WARNING, INFO), and mode.

Manage MRS objects and inspect the full request and response schema at v1beta API — ManagedRuleSet.

Per-rule overrides

You do not need to accept the OWASP CRS defaults wholesale. Use PATCH to override the state of individual rules while leaving all others unchanged. The following modes are supported:

Mode	Effect
`MODE_ENABLED`	Inspects traffic and applies the rule action on a match.
`MODE_DISABLED`	Skips the rule entirely. Nothing is inspected and nothing is logged.
`MODE_LOG_ONLY`	Inspects traffic and logs matches but does not block the request.

The patch body is sparse: only the groups and rules entries you include are updated, so you can target a single rule ID without resending the rest of the group. Use MODE_LOG_ONLY to observe the impact of a rule on production traffic before enforcing it, and use MODE_DISABLED to permanently silence a rule you have accepted as a false positive for your workload.

For the exact PATCH request shape, see the v1beta API — ManagedRuleSet reference.

Custom rule groups

A custom rule group (CRG) lets you define your own detection logic for cases the OWASP CRS does not cover, such as application-specific allow-lists, business-logic checks, or targeted virtual patches. Each CRG is a named object per project and region, and any ALB WAF configuration in the same scope can reference it.

STACKIT abstracts the underlying Coraza SecLang grammar into a structured JSON model, so you configure rules using typed fields instead of writing raw SecLang directives. The engine translates your JSON into SecLang at runtime.

Manage CRG objects and inspect the full request and response schema at v1beta API — CustomRuleGroup.

Rule structure

Each rule inside a CRG has the following shape:

Rule ID — Auto-assigned by the backend in the range 1-99999. You do not set it on creation; it is returned on GET.
Description — A free-form explanation of the threat vector or business intent covered by the rule.
Behaviour — What happens when the rule matches:
- action — One of ACTION_DENY (returns HTTP 403 and halts processing), ACTION_PASS (continues to the next rule), or ACTION_ALLOW (short-circuits remaining inspection for the request).
- log — Boolean. When true, the match is written to the security log.
- log_msg — Required when log is true. A short human-readable message that is attached to the log entry to aid triage.
- severity — Classification for downstream analytics. One of SEVERITY_EMERGENCY, SEVERITY_ALERT, SEVERITY_CRITICAL, SEVERITY_ERROR, SEVERITY_WARNING, SEVERITY_NOTICE, SEVERITY_INFO, or SEVERITY_DEBUG.
Conditions — An ordered list of checks evaluated top to bottom. The first condition that matches triggers the rule’s action. Each condition combines:
- variable — The part of the HTTP transaction to inspect. An optional value narrows a map variable to a single key (for example, Host inside VARIABLE_REQUEST_HEADERS).
- transformations — Ordered normalization steps applied before the operator runs.
- operator — The comparison logic executed against the transformed variable.

For the full catalog of supported variables, operators, and transformations — including the API constant and the semantics of each value — see the ALB WAF rule selectors reference.

Example use case: block traffic to an unexpected host

A common CRG use case is to reject any request whose Host header is not on an allow-list. You would express this as a single rule with:

One condition that inspects VARIABLE_REQUEST_HEADERS narrowed to the Host key, normalizes the value with TRANSFORMATION_LOWERCASE, and compares it against the allowed hostname with OPERATOR_BEGINS_WITH.
A behaviour of ACTION_DENY with log: true and a descriptive log_msg such as Host header not on allow-list, tagged at SEVERITY_CRITICAL.

For the concrete request body and every accepted field, see v1beta API — CustomRuleGroup. Available selector values are catalogued in the ALB WAF rule selectors reference.

The rule ID is assigned automatically by the backend and returned on subsequent GET requests.

Quotas

Each project has separate quotas for ALB WAF configurations, managed rule sets, and custom rule groups. The default and maximum values are the same for all three:

Resource	Default limit per project	Maximum limit per project
ALB WAF configurations	150	Contact STACKIT support
Managed rule sets	150	Contact STACKIT support
Custom rule groups	150	Contact STACKIT support

Retrieve current usage at GET /v1beta/projects/{projectId}/regions/{region}/quotas. If you need a limit raised, contact STACKIT support.