Use WAF exclusion rulesets

Some applications legitimately send content that looks like an attack: a content management system posts HTML, a code host accepts code, a database console accepts SQL. An exclusion ruleset collects the exclusions such an application needs, so you opt a route into it instead of rediscovering each false positive.

An exclusion ruleset never scores and never blocks. Each entry names a ruleset and a rule (by ID or by tag), a target with an exact name, name prefix or regular expression, and optionally a path prefix or regular expression and a set of methods. The WAF skips that rule for matching fields on matching requests only.

Entries may also require an exact value, value prefix or bounded regular expression, and a set of request-field guards. Every guard must match exactly one named field across its listed targets, or no fields when it explicitly requires absence. Multiple occurrences of a guarded field, including identical duplicates, do not satisfy that guard. Repeated unrelated fields remain individually inspected and do not by themselves disable a unique guard. Header names ignore case; values use ordinal comparison unless the regular expression specifies otherwise. Query and form values are checked after their normal parser decoding.

Guards that inspect form, multipart-text or JSON fields require a complete, valid buffered request body. They do not activate during streamed multipart-part inspection. Parser failures and inspection limits remain subject to the normal WAF policy.

Invalidly encoded names cannot activate a FormRawValue exclusion.

Exclusion rulesets apply only to routes whose WAF policy opts in. Choose them in the policy under Firewall → WAF policies, or set the clearplane.proxy.waf.exclusion-rulesets container label to a whitespace-separated list of ruleset IDs. A route whose policy has not opted in is never affected, even when the ruleset is active.

Exclusion rulesets arrive and update like any other ruleset. Their integrity tests name the ruleset they exclude from, and run only while that ruleset is active. If a test stops passing against the rulesets you run, for example after a ruleset update retires the rule it relies on, Edge sets that exclusion ruleset aside, keeps enforcing everything else, and reports it on the Rulesets page.

Application presets

The following core application presets are prepared as unpublished release candidates. They become selectable after their signed releases are published and installed. Enable a preset only in a Route WAF policy for the routes serving its application, rather than in the Global policy.

WordPress and phpMyAdmin support installation in a URL subdirectory.

The Nextcloud preset assumes an installation at the URL root, with the optional index.php front controller. A deployment under a path such as /nextcloud/ needs a separately reviewed profile with that base path.

Each preset's request guards are part of the preset, so ordinary per-route opt-in does not remove them.

Use a WAF policy's own exclusions for anything specific to your installation; see Review WAF detections.

The reference example shows the exclusion document and its vector checking the selected field and path.