METADATA ======= Last Updated: 2026-09-30 Title: Clearplane - Full LLM Documentation Product: Clearplane self-hosted web security gateway ================================================================================ DOCUMENT: CLI Human URL: /docs/cli/ ================================================================================ The `clearplane` command is included in the Core container. Run application commands through Docker Compose from the directory containing `docker-compose.yml`: ```bash docker compose exec clearplane-core clearplane --help ``` Replace `clearplane-core` with your Core service key if you renamed it. Docker Compose handles installation, image pulls, start, stop, restart, logs, and removal; see [Installation](../get-started/) for those commands. > Using an LLM or coding agent? Open the [plain-text CLI reference](/llms/cli/index.txt), the [LLM documentation index](/llms.txt), or the [complete documentation file](/llms/llms-full.txt). ## All commands For online commands, use `docker compose exec clearplane-core clearplane `. Database maintenance and secret rotation use the one-shot examples below. | Command | Purpose | When to run | | --- | --- | --- | | `serve` | Prepare persistent state and start Core. This is the default when no command is supplied. | Started by Compose; do not launch another serving process with `exec`. | | `installation status` | Validate installation state and print `Pending` or `Installed`. | Online. | | `setup-code` | Issue a replacement code for initial browser setup. | Online, before initial setup completes. | | `administrator create` | Prompt for username, display name, and password to create the first administrator and complete setup. | Online, before initial setup completes; attached terminal required. | | `administrator reset-password ` | Set a replacement administrator password, invalidate older sessions, and require a password change after sign-in. | Online; attached terminal required. | | `administrator reset-multi-factor-authentication ` | Reset the administrator's MFA enrollment while preserving the account's MFA requirement. | Online. | | `bans unban ` | Lift active bans matching the normalized IP address or CIDR range. | Online; restart Core afterward to reload active bans. | | `cache purge ` | Purge cached responses on every connected Edge: `everything`, `route `, `uri `, `prefix `, or `tag [ ...]`. | Online; Core must be serving. | | `secrets status` | Report redacted machine-secret generation metadata and missing, invalid, or expiring files. | Online or in a one-shot container, including when Core cannot start. | | `secrets rotate ` | Rotate one secret scope or the complete matched generation. | Stop the entire stack first. | | `database initialize` | Initialize wholly absent persistent state or validate already-current complete state. Refuses pending migrations and partial state. | Stop Core first. | | `database migrate` | Apply known forward migrations to complete existing state, or validate already-current state. Refuses absent or incompatible state. | Stop Core first. | | `help`, `--help`, `-h` | Print command help and exit. | Online or in a one-shot container. | Commands accept the exact arguments shown. Passwords are entered at prompts without echo and must be confirmed; there is no password argument. Use an attached terminal for administrator creation and password reset, without Compose's `-T` option or redirected input. ## Status and first setup ```bash docker compose exec clearplane-core clearplane installation status docker compose exec clearplane-core clearplane setup-code ``` A setup code expires after 15 minutes. A new code invalidates the previous one; five syntactically valid incorrect attempts invalidate the current code. Successful setup consumes the code and permanently closes initial setup. Submit it at your management hostname's `/setup` page over trusted HTTPS. To create the first administrator through the terminal: ```bash docker compose exec clearplane-core clearplane administrator create ``` This command completes initial setup; it does not add administrators to an already-installed system. ## Administrator recovery ```bash docker compose exec clearplane-core clearplane administrator reset-password docker compose exec clearplane-core clearplane administrator reset-multi-factor-authentication ``` Password reset invalidates the target administrator's older sessions and requires a password change after sign-in. MFA reset clears enrollment without changing whether MFA is required. These commands are available through host/container access; there is no anonymous browser recovery flow. ## Remove a ban ```bash docker compose exec clearplane-core clearplane bans unban 203.0.113.10 && docker compose restart clearplane-core ``` `` accepts an IPv4 address, IPv6 address, or CIDR range. Matching uses the normalized address or exact normalized CIDR; a CIDR argument does not remove every individual-address ban contained within that network. Restart Core after a successful command so the serving process reloads active bans. ## Purge the cache ```bash docker compose exec clearplane-core clearplane cache purge everything docker compose exec clearplane-core clearplane cache purge route 42 docker compose exec clearplane-core clearplane cache purge uri https://app.example.com/index.html docker compose exec clearplane-core clearplane cache purge prefix https://app.example.com/assets/ docker compose exec clearplane-core clearplane cache purge tag product-42 catalog ``` These are the same purges as the cache page and `POST /api/cache/purge`. A route ID is shown on the cache page. URIs are absolute HTTP or HTTPS URIs without a fragment; a prefix matches every cached URI that starts with it. Tags match the upstream's `Cache-Tag` and `Surrogate-Key` response headers, ignoring case; up to 30 tags per command, without whitespace or commas. The command calls the serving Core over the container's loopback interface with Core's own internal certificate, so it works only through `docker compose exec` while Core runs. It prints the purge revision and each Edge's result, and exits `1` when any Edge fails. When no Edge is connected, every Edge purges its whole cache when it reconnects. ## Database maintenance Normal startup prepares all three databases automatically. Use these commands for manual preparation with Core stopped. Choose the operation that matches the persistent state. Fresh provisioning requires all three databases, machine secrets, and other durable state to be absent. Existing state requires all three databases and a valid matched secret generation. Core validates every history before migrating any database; unknown, empty, reordered, or partially missing state is refused without resets. Initialize empty volumes, or validate already-current complete state: ```bash docker compose stop clearplane-core && docker compose run --rm --no-deps clearplane-core database initialize && docker compose up -d --wait ``` Migrate a complete existing installation: ```bash docker compose stop clearplane-core && docker compose run --rm --no-deps clearplane-core database migrate && docker compose up -d --wait ``` One-shot containers already use `clearplane` as their entry point, so the command follows the service key directly. The `&&` chains leave Core stopped if maintenance fails; diagnose the failure before starting it again. ## Secret status and rotation Inspect redacted status online: ```bash docker compose exec clearplane-core clearplane secrets status ``` When Core cannot start, use a one-shot container: ```bash docker compose run --rm --no-deps clearplane-core secrets status ``` Rotation supports these scopes: | Scope | Secret material | | --- | --- | | `administrator-jwt` | Administrator JWT signing key. | | `stored-certificates` | Stored-certificate protection password and re-encrypted certificates. | | `internal-tls` | Private CA and internal service identities. | | `challenge-clearance` | Bot-challenge signing key; invalidates cookies and pending proofs when Edge restarts. | | `all` | All of the above in one matched generation. | Stop the entire stack because services retain credentials in memory: ```bash docker compose down && docker compose run --rm --no-deps clearplane-core secrets rotate all && docker compose up -d --wait ``` Replace `all` with the desired scope. Rotation journals progress. If interrupted, keep the stack stopped, inspect `secrets status`, and rerun the exact same scope to resume. Never delete the journal or replace only one service's generation to force startup. ## Exit codes | Code | Meaning | | --- | --- | | `0` | Success. Help also exits successfully without starting Core. | | `1` | Operational failure, including an invalid secret status, Core not serving a cache purge, or an Edge failing one. | | `2` | Unsupported command or invalid argument syntax. | Results go to stdout and failures to stderr. Secret status is redacted; `setup-code` intentionally prints the requested setup code. ================================================================================ DOCUMENT: Configuration lifecycle Human URL: /docs/concepts/configuration-lifecycle/ ================================================================================ Clearplane separates saving configuration from making it active at Edge. This keeps related changes coherent and makes pending work visible. ## From source to Edge 1. An operator saves a UI or REST API change, or container discovery observes a label change. 2. Core validates and persists the accepted change. A material change advances the configuration revision. 3. When that revision is applied, Edge fetches the complete enabled routes, clusters, destinations, and policy assignments. 4. Edge validates the complete candidate and publishes it as one routing snapshot. Edge never activates a partial candidate. If loading fails, the previous valid snapshot continues serving requests and the new revision remains pending. ## Apply modes - **Immediate** takes effect after its save or reconciliation succeeds. - **Validated** takes effect only after Clearplane accepts the complete value. - **Apply required** is staged until automatic apply runs or an operator chooses **Apply** on the relevant service. - **Restart required** remains pending until the affected service restarts through an approved operating workflow. The exact mode belongs to each setting. Check its row in [Reference](/docs/configuration/) rather than assuming that every setting from the same source behaves alike. ## Revisions and pending state Edge reports the revision it has loaded, allowing the UI to distinguish applying work from changes still waiting to be applied. Container-discovered route changes use the same revision path. Follow [Change and apply configuration](/docs/operations/change-apply-configuration/) for the operator workflow. ================================================================================ DOCUMENT: Configuration ownership Human URL: /docs/concepts/configuration-ownership/ ================================================================================ Clearplane gives the UI/API model and Docker-label model equal importance. They feed the same persisted routing and policy model, but every resource keeps the source that owns it. ## UI and REST API ownership Resources created through the UI or REST API are UI/API-owned. They remain editable and removable through either interface, subject to authorization and validation. The UI and REST API are two interfaces to the same ownership source. A resource created through one does not become a different kind of runtime resource when it is later edited through the other. Management API grid responses contain list summaries. Retrieve the resource’s full configuration through its detail endpoint before editing; a grid row does not contain the complete configuration needed for an update. ## Docker-label ownership Container discovery creates label-owned routes, clusters, destinations, inline policies, and each route's policy states and assignments. These resources are visible in the UI with their source, but are read-only there. Edit the labels on the owning container instead. A label-owned WAF policy keeps its disabled rules, target exclusions and per-ruleset thresholds editable, because labels cannot address individual rules. When discovery accepts a label change, it reconciles the complete owned resource graph. An invalid or conflicting candidate is reported as a discovery issue and the previous valid graph remains in place. Removing every `clearplane.*` discovery label from a container deletes its label-owned proxy route or standalone redirect, cluster, destinations, and inline policies. An issued certificate remains available under UI/API ownership. Setting the route's enable label to `false`, removing only that enable label while other Clearplane labels remain, or stopping the container disables the route without deleting its owned graph. ## Resource groups Resource groups organize routes, clusters, certificates, ACME DNS profiles, access control policies and aliases, rate limit policies, auto-ban policies, CORS policies, authentication policies, request headers and response headers policies, WAF policies, and WAF rulesets. Pages for these resources show one section per group that contains resources, followed by **Ungrouped**. The search box above the sections filters every section at once and hides sections without matches. Turn off **Group by resource group** to list the page's resources in one table instead. Clearplane saves that choice per page for your account, so it follows you across browsers. Logs, bans, audit, metrics, background jobs, and settings are operational pages and do not use resource groups. ## Hybrid configuration You can use both models in one Clearplane installation. For example, application teams can publish services with Docker labels while operators manage shared policies through the UI or REST API. Ownership remains per resource. Clearplane does not silently convert a label-owned resource into UI/API ownership, and recreating the same resource in another source does not override its owner. To change ownership, remove the original definition and create its replacement through the intended source. Use the source badge and locked-field state in the UI to identify where a change belongs. Then follow [Change and apply configuration](/docs/operations/change-apply-configuration/) to verify when it becomes effective. ================================================================================ DOCUMENT: Concepts Human URL: /docs/concepts/ ================================================================================ Use Concepts when you need the model behind a task. [Guides](../guides/) tell you what to do, while [Reference](../configuration/) lists exact settings and accepted values. - [Routes, clusters, and destinations](routing-model/) explains how a request reaches an application. - [Policies, scope, and precedence](policies-and-scope/) explains reusable behavior and which policy applies to a route. - [Configuration ownership](configuration-ownership/) explains the equal UI/API and Docker-label configuration paths. - [Configuration lifecycle](configuration-lifecycle/) explains revisions, validation, apply modes, and last-valid behavior. ================================================================================ DOCUMENT: Policies, scope, and precedence Human URL: /docs/concepts/policies-and-scope/ ================================================================================ Policies add reusable behavior to the request pipeline without duplicating the same settings on every route. Clearplane has policy families for access control, authentication, auto-ban, cache, compression, CORS, rate limit, request headers, response headers and the web application firewall (WAF). ## Policy names Policies have a display **Name** and a **System name** (`SystemName` in the API). The name is free text shown in lists. The system name is generated from the name while creating a policy and can be edited. For example, `PublicAPI` generates `publicapi`; you can edit that to `public-api`. Labels resolve the system name. Renaming a saved policy leaves its system name and label references unchanged. Editing the system name requires updating labels that reference it. The API preserves the existing system name when an update omits `SystemName`. ## Route policy state Every route has one state per policy family: **Inherit**, **On** or **Off**. The state decides which policies apply to the route. | State | Policies applied to the route | |---|---| | Inherit | The enabled Global policy of the family, or its enabled Global policies. This is the default. | | On | The route's own enabled policies. They replace the Global ones. | | Off | None, even when a Global policy exists. | The families differ only in how many policies a route and the installation can hold: | Families | Policies per route | Global policies | |---|---|---| | Cache, CORS, compression, request headers, response headers, WAF | One | At most one | | Access control, rate limit, automatic bans | One or more | Any number | | Authentication | One or more, combined by the policy's combine mode | None, so Inherit and Off both mean no authentication | A route that is **On** keeps its own policies even when they are disabled. A disabled policy stops applying, and its routes get no policy of that family until it is enabled again; they never fall back to the Global policy. A policy's **Enabled** switch never changes a route's state. In the UI, set the state in the **Policies** section of the route dialog. **On** asks for the route's policies. Assigning a policy to a route from a policy dialog sets that family to **On**. Removing the route's last policy of the family sets it back to **Inherit**. The REST API accepts the same `{Family}PolicyState` and `{Family}PolicyIds` fields on a route. ## Docker labels Every family has one root label and the same label shape: ```text clearplane.proxy.: Inherit | On | Off clearplane.proxy..policy clearplane.proxy.. clearplane.proxy.... ``` Only the root label switches a route to its own policies. With `on`, set `policy` to reference existing route-scoped policies by system name, or give inline settings to create a policy for this route alone. The one-policy families accept one system name, and the others accept a space-separated list. Combining `policy` with inline settings rejects the container. Inline settings you leave out take their documented defaults, never the Global policy's values. An inline WAF policy defaults to `Detection` when `clearplane.proxy.waf.mode` is omitted. ```yaml clearplane.proxy.waf: "On" clearplane.proxy.waf.policy: "strict-api" clearplane.proxy.rate-limit: "On" clearplane.proxy.rate-limit.policy: "login-throttle api-burst" clearplane.proxy.cors: "Off" ``` Family labels without the root label reject the container, and the rejection names the missing `clearplane.proxy.: On`. Under `Inherit` or `Off`, the family's other labels are kept but ignored, so you can switch a route off without removing its settings. The [Docker label reference](/docs/configuration/docker-labels/#policy-labels) has an example for every family, and the [configuration catalog](/docs/configuration/catalog/#proxy-directives) lists every supported field. ## Ownership An inline policy is generated for one discovered route and remains owned by that service. Clearplane updates it as labels change and deletes it when the service, the family labels or the inline selection disappears, or when the root label leaves `on`. Container-managed policies are visible but read-only through the UI and REST API, and one service cannot select another service's inline policy by system name. A container-managed WAF policy is the exception for rule tuning: its disabled rules, target exclusions and per-ruleset thresholds stay editable, because labels cannot address individual rules, and discovery keeps them. Named policies remain managed by the source that created them. Switching from inline labels to `policy` deletes the generated policy and attaches the named policy; removing `policy` and supplying inline settings performs the inverse transition. ## Global scope A Global policy is the default for its family. It applies to every route whose state for that family is **Inherit**. A new installation ships the Global WAF policy **Default WAF** in Detection, so every route that inherits the WAF is inspected once a ruleset is active. Set a route's WAF state to **Off** to opt it out. ## Precedence A route's own policies replace the Global ones of the same family. Clearplane never merges a Global policy into the route's own policies. Evaluation inside the selected policy depends on the policy family. For example, access-control entries decide whether an address is allowed or blocked, while a rate limit policy decides whether capacity is available. Use [Reference](/docs/configuration/) for each family's exact fields and accepted values. Auto-ban policies observe behavior on the routes in their scope. Once an address is banned, the resulting IP ban is enforced across Clearplane until it expires or is removed. Start with [Ban abusive clients automatically](/docs/guides/protect-service/) for the recommended protection workflow. ================================================================================ DOCUMENT: Routes, clusters, and destinations Human URL: /docs/concepts/routing-model/ ================================================================================ Clearplane represents proxying as three connected resources: 1. A **route** matches an incoming request and selects one upstream cluster. 2. A **cluster** defines how Clearplane communicates with a logical pool of upstreams. 3. A **destination** is one concrete upstream address in that cluster. ## Routes match requests A route can match a host, path, and optional HTTP methods. It also carries an order for resolving overlapping matches: lower order values are evaluated first. Route settings control request-facing behavior such as redirects, path rewriting, and policy assignments. Disabling a route removes that match from the active Edge configuration without deleting its cluster. ## Wildcard hosts Proxy routes accept exact DNS hosts and a leading wildcard such as `*.example.com`. A wildcard matches one subdomain level: it covers `tenant.example.com`, but excludes `example.com` and `deep.tenant.example.com`. List the apex separately when it should reach the same application. At equal route order, exact host matches take precedence over wildcard matches. For Docker-discovered routes, use `clearplane.proxy.host` and the whitespace-separated `clearplane.proxy.additional-hosts`. Routing and TLS coverage are separate. A wildcard certificate does not create a wildcard route, and a wildcard route needs a covering certificate for trusted HTTPS. See [Enable HTTPS](/docs/guides/enable-https/#wildcard-routing-and-certificates) for DNS-01 profiles, certificate automation, and a complete label example. ## Clusters group upstream behavior A cluster owns one or more destinations and the behavior shared between them, including load balancing, health checks, timeouts, retries, and session affinity. Multiple routes can point to the same cluster when they should share the same upstream pool. ## Destinations identify applications Each enabled destination supplies a concrete upstream address. Edge selects an eligible destination from the route's cluster and proxies the request to it. For a Docker-discovered service, Clearplane creates and maintains this route-and-cluster graph from the proxy labels and observed container address. Through the UI or REST API, you create the same ordinary resources directly. Both paths produce the same Edge routing model. ## Request flow `Client request → matching route → upstream cluster → eligible destination` If no route matches, Edge returns a not-found response. If a route matches but no destination can serve the request, Edge returns an upstream failure response. Use [Troubleshoot a service](/docs/operations/troubleshoot-service/) to work backward through that flow. ================================================================================ DOCUMENT: Complete configuration catalog Human URL: /docs/configuration/catalog/ ================================================================================ This reference is generated from Clearplane's validated configuration catalog. Each directive lists its supported sources, defaults, validation, apply behavior, and UI location. ## Resolution and ownership Runtime values resolve independently per setting in this order: **environment variable → validated Clearplane container label → saved UI value → built-in default**. Environment variables carry bootstrap settings and secrets only. Every other runtime setting uses its documented container label or the UI; a label makes the matching UI field read-only until the label is removed. The MaxMind license key is the one runtime setting that also accepts an environment variable, because it is a secret. Secret environment settings also accept the listed `_FILE` twin, which is read from a file mounted into the container; setting both forms is an error. Bootstrap settings are read once at process start, so every bootstrap change needs a restart, and an invalid bootstrap value stops the process with a message naming the variable. Container-discovered resources are read only from Docker labels; Clearplane never reads the labeled container's environment variables. - **Bootstrap:** environment-only and applied at process startup. - **Runtime:** may be changed through its documented sources and reports the effective source. - **Service resource:** label-only configuration attached to a discovered proxy route or standalone redirect container. - **Immediate:** consumed without an explicit Edge apply. **Validated:** accepted only after validation succeeds. **Staged:** saved until Edge configuration is applied. **Restart required:** effective after the owning process restarts. > [!WARNING] > Docker labels are visible through container inspection. Clearplane accepts secret labels because every supported label has the same configuration semantics, but the `_FILE` environment twin or the encrypted UI field are safer for credentials. APIs, diagnostics, logs, and this document never render secret values. ## Label values - **Names** are the API field names in kebab-case. Related fields share dotted groups such as `brotli.*` or `waf.challenge.*`. Boolean subfeatures use `.enabled`, such as `brotli.enabled` or `waf.websocket.enabled`. Proxy policy families use their root label with `Inherit`, `On` or `Off`; they do not have an `.enabled` label. Units end the name: `-seconds`, `-minutes`, `-bytes`, `-megabytes`. - **Enumerations** are written like the REST API and the UI, for example `On`, `Prevention` or `MemoryOnly`. Matching ignores case; numeric backing values are not accepted. Fields documented with literal numeric choices, such as redirect status codes, accept those listed numbers instead. - **Booleans** are `true` or `false`, ignoring case. - **Lists** are whitespace-delimited. YAML's folded form works because line breaks become spaces. - **Invalid owner-runtime values** under `clearplane.core.*`, `clearplane.edge.*`, `clearplane.ui.*` or `clearplane.container-proxy.*` are reported as warnings. The setting retains its previous valid label value; when none exists, the invalid label supplies no value and normal source resolution applies. Invalid service-resource values reject the discovered container and keep its previous route. - **Unknown owner-runtime keys** under those prefixes are reported as warnings and ignored. An unknown key does not preserve the override from a known runtime label it replaced; normal label-removal fallback still applies. Unknown service-resource keys reject the discovered container, except under `clearplane.proxy.cache.*` (but not `cache.key.*`), `compression.*`, `error-page.*`, `group.*`, `redirect.*` and `clearplane.redirect.group.*`. Those families cannot weaken protection, so an unknown key there is also reported as a warning and ignored. Each semantic collection uses indexed structured labels shaped as `..`. Indices are one-based, may contain gaps, and are ordered numerically. Every indexed item must include its required fields; malformed, incomplete, duplicate, unknown, or out-of-range entries are rejected. Every proxy policy family has the same envelope. The root label `clearplane.proxy.` is `Inherit` (the default, which applies the family's enabled Global policies), `On` (the route's own policies, which replace the Global ones) or `Off` (no policy, even when a Global policy exists). Other family labels require the root label and reject the container without it; under `Inherit` or `Off` they are kept without validation. With `On`, `clearplane.proxy..policy` selects existing policies by system name; otherwise the family's labels create an inline route-scoped policy and every omitted field takes its documented default. Named and inline fields cannot be combined. Authentication has no defaults to fall back on, so an inline authentication policy needs `type` and its credentials or keys. ## Core directives | Directive | Type | Accepted values | Built-in default | Environment variable | Docker label | Sources | Lifecycle | Sensitivity | Apply | UI location | Description | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | clearplane.core.acme.email-address | String | Valid email address, 1-320 characters | (empty) | — | clearplane.core.acme.email-address | Container label, UI | Runtime | Public | Validated | System / Settings / Certificates / Let's Encrypt account | Required contact email address registered with the selected Let's Encrypt account. | | clearplane.core.acme.environment | AcmeEnvironment | Production, Staging | Production | — | clearplane.core.acme.environment | Container label, UI | Runtime | Public | Validated | System / Settings / Certificates / Let's Encrypt account | Let's Encrypt environment used for ACME accounts and certificate orders. | | clearplane.core.acme.terms-of-service-agreed | Boolean | true | false | — | clearplane.core.acme.terms-of-service-agreed | Container label, UI | Runtime | Public | Validated | System / Settings / Certificates / Let's Encrypt account | Must be true to confirm acceptance of the Let's Encrypt terms before saving the account configuration. | | clearplane.core.analytics.daily-retention-days | Integer | Positive integer no less than hourly-retention-days | 90 | — | clearplane.core.analytics.daily-retention-days | Container label, UI | Runtime | Public | Validated | System / Settings / Analytics | Days of daily analytics rollups retained before pruning. | | clearplane.core.analytics.hourly-retention-days | Integer | Positive integer no greater than daily-retention-days | 14 | — | clearplane.core.analytics.hourly-retention-days | Container label, UI | Runtime | Public | Validated | System / Settings / Analytics | Days of hourly analytics rollups retained before compaction into daily rollups. | | clearplane.core.bootstrap.acme-dns-profile.api-token | String | Non-blank value, up to 4096 characters | (empty) | CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_<INDEX>_API_TOKEN
CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_<INDEX>_API_TOKEN_FILE | — | Environment | Bootstrap | Secret | Restart required | — | Required API token for this numbered DNS profile. May be injected directly from a deployment secret or through its _FILE environment twin. | | clearplane.core.bootstrap.acme-dns-profile.name | String | Trimmed unique name, 1-200 characters | (empty) | CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_<INDEX>_NAME | — | Environment | Bootstrap | Public | Restart required | — | Required case-insensitively unique name for this numbered DNS profile. Indices start at 1 and may contain gaps. Certificate labels select this name. | | clearplane.core.bootstrap.acme-dns-profile.propagation-seconds | Integer (optional) | 1-3600, or empty for the provider default | (empty) | CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_<INDEX>_PROPAGATION_SECONDS | — | Environment | Bootstrap | Public | Restart required | — | Optional DNS propagation delay in seconds for this numbered credential profile. | | clearplane.core.bootstrap.acme-dns-profile.provider | AcmeDnsProvider | Cloudflare | Cloudflare | CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_<INDEX>_PROVIDER | — | Environment | Bootstrap | Public | Restart required | — | DNS provider for this numbered credential profile. | | clearplane.core.bootstrap.acme-dns-profiles | String | JSON object with a profiles array of unique name, Cloudflare provider, apiToken, and optional propagationSeconds fields; or empty | (empty) | CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILES
CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILES_FILE | — | Environment | Bootstrap | Secret | Restart required | — | One-line JSON document containing read-only ACME DNS profiles. Unknown properties are rejected; names must be trimmed, case-insensitively unique and at most 200 characters, tokens must be non-blank and at most 4096 characters, and propagationSeconds must be 1-3600 when present. | | clearplane.core.bootstrap.analytics-path | String | — | ../var/analytics | CLEARPLANE_CORE_BOOTSTRAP_ANALYTICS_PATH | — | Environment | Bootstrap | Public | Restart required | — | Persistent Core analytics data directory. | | clearplane.core.bootstrap.certificate-password | String | — | (empty) | CLEARPLANE_CORE_BOOTSTRAP_CERTIFICATE_PASSWORD
CLEARPLANE_CORE_BOOTSTRAP_CERTIFICATE_PASSWORD_FILE | — | Environment | Bootstrap | Secret | Restart required | — | Password protecting stored certificates. | | clearplane.core.bootstrap.cloud-uri | String | Absolute HTTPS base URI with path / or /api/ | https://cloud.clearplane.net/api/ | CLEARPLANE_CORE_BOOTSTRAP_CLOUD_URI | — | Environment | Bootstrap | Public | Restart required | — | Clearplane Cloud API base URI. Used only when Cloud integration is enabled. Credentials, queries and fragments are rejected. | | clearplane.core.bootstrap.compose-project-name | String | — | (empty) | CLEARPLANE_CORE_BOOTSTRAP_COMPOSE_PROJECT_NAME | — | Environment | Bootstrap | Public | Restart required | — | Compose project owning the Clearplane containers. When omitted, Core resolves the project from its runtime container identity. | | clearplane.core.bootstrap.container-proxy-data-path | String | — | /app/container-proxy-data | CLEARPLANE_CORE_BOOTSTRAP_CONTAINER_PROXY_DATA_PATH | — | Environment | Bootstrap | Public | Restart required | — | Persistent data directory published to ContainerProxy. | | clearplane.core.bootstrap.container-proxy-uri | String | Absolute HTTPS origin | https://clearplane-container-proxy:8443 | CLEARPLANE_CORE_BOOTSTRAP_CONTAINER_PROXY_URI | — | Environment | Bootstrap | Public | Restart required | — | Internal ContainerProxy origin. Credentials, paths, queries and fragments are rejected. | | clearplane.core.bootstrap.data-path | String | — | ../var/data | CLEARPLANE_CORE_BOOTSTRAP_DATA_PATH | — | Environment | Bootstrap | Public | Restart required | — | Persistent Core data directory. | | clearplane.core.bootstrap.edge-data-path | String | — | /app/edge-data | CLEARPLANE_CORE_BOOTSTRAP_EDGE_DATA_PATH | — | Environment | Bootstrap | Public | Restart required | — | Persistent data directory published to Edge. | | clearplane.core.bootstrap.jwt-audience | String | — | clearplane | CLEARPLANE_CORE_BOOTSTRAP_JWT_AUDIENCE | — | Environment | Bootstrap | Public | Restart required | — | JWT audience written to and accepted from Core authentication tokens. | | clearplane.core.bootstrap.jwt-issuer | String | — | clearplane | CLEARPLANE_CORE_BOOTSTRAP_JWT_ISSUER | — | Environment | Bootstrap | Public | Restart required | — | JWT issuer written to and accepted from Core authentication tokens. | | clearplane.core.bootstrap.jwt-issuer-signing-key | String | — | (redacted) | CLEARPLANE_CORE_BOOTSTRAP_JWT_ISSUER_SIGNING_KEY
CLEARPLANE_CORE_BOOTSTRAP_JWT_ISSUER_SIGNING_KEY_FILE | — | Environment | Bootstrap | Secret | Restart required | — | JWT signing key used by Core. | | clearplane.core.bootstrap.logs-path | String | — | ../var/logs | CLEARPLANE_CORE_BOOTSTRAP_LOGS_PATH | — | Environment | Bootstrap | Public | Restart required | — | Base directory for Core logs. | | clearplane.core.bootstrap.setup-uri | String | — | /setup | CLEARPLANE_CORE_BOOTSTRAP_SETUP_URI | — | Environment | Bootstrap | Public | Restart required | — | Setup URI displayed by the setup-code command. This does not configure the UI host or its routing. | | clearplane.core.bootstrap.ui-data-path | String | — | /app/ui-data | CLEARPLANE_CORE_BOOTSTRAP_UI_DATA_PATH | — | Environment | Bootstrap | Public | Restart required | — | Persistent data directory published to UI. | | clearplane.core.bootstrap.ui-uri | String | Absolute HTTPS origin | https://clearplane-ui:8443 | CLEARPLANE_CORE_BOOTSTRAP_UI_URI | — | Environment | Bootstrap | Public | Restart required | — | Internal UI origin. Credentials, paths, queries and fragments are rejected. | | clearplane.core.bootstrap.waf-ruleset-signing-keys | String | Comma-separated <key-id>:<base64 P-521 SubjectPublicKeyInfo> entries | (empty) | CLEARPLANE_CORE_BOOTSTRAP_WAF_RULESET_SIGNING_KEYS | — | Environment | Bootstrap | Public | Restart required | — | Trusted WAF ruleset signing keys. When set, these replace the signing keys built into this Clearplane version instead of adding to them. Invalid entries stop the service from starting. Leave empty to trust only the built-in keys. | | clearplane.core.container-discovery.enabled | Boolean | — | true | — | clearplane.core.container-discovery.enabled | Container label | Runtime | Public | Immediate | — | Enable reconciliation of proxied services from container labels. | | clearplane.core.geo-ip.enabled | Boolean | — | true | — | clearplane.core.geo-ip.enabled | Container label, UI | Runtime | Public | Validated | System / Settings / Country geolocation | Enable country geolocation and enforcement of country-dependent access control policies. | | clearplane.core.geo-ip.license-key | String | 0-512 characters | (empty) | CLEARPLANE_CORE_GEO_IP_LICENSE_KEY
CLEARPLANE_CORE_GEO_IP_LICENSE_KEY_FILE | clearplane.core.geo-ip.license-key | Environment, Container label, UI | Runtime | Secret | Validated | System / Settings / Country geolocation | MaxMind license key. It is required only when country geolocation is effectively enabled with the MaxMind provider; empty is allowed when geolocation is disabled or DbIp is effective. | | clearplane.core.geo-ip.provider | GeoIpProvider | DbIp, MaxMind | DbIp | — | clearplane.core.geo-ip.provider | Container label, UI | Runtime | Public | Validated | System / Settings / Country geolocation | GeoIP database provider. | | clearplane.core.logs.indexed-retention-days | Integer | Positive integer | 30 | — | clearplane.core.logs.indexed-retention-days | Container label, UI | Runtime | Public | Validated | System / Settings / Logs | Days of queryable indexed logs retained before pruning. | | clearplane.core.logs.raw-retention-days | Integer | Non-negative integer | 1 | — | clearplane.core.logs.raw-retention-days | Container label, UI | Runtime | Public | Validated | System / Settings / Logs | Days of fully ingested raw JSONL files retained. Zero removes rolled files after ingestion. | ## Edge directives | Directive | Type | Accepted values | Built-in default | Environment variable | Docker label | Sources | Lifecycle | Sensitivity | Apply | UI location | Description | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | clearplane.edge.analytics.flush-interval-seconds | Integer | 1-3600 | 30 | — | clearplane.edge.analytics.flush-interval-seconds | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Telemetry | Seconds between Edge analytics counter flushes to Core. Edge reads this once at startup, so a change takes effect when Edge restarts. | | clearplane.edge.bootstrap.cache-path | String | — | ../var/cache | CLEARPLANE_EDGE_BOOTSTRAP_CACHE_PATH | — | Environment | Bootstrap | Public | Restart required | — | Persistent response-cache directory. | | clearplane.edge.bootstrap.certificate-password | String | — | (empty) | CLEARPLANE_EDGE_BOOTSTRAP_CERTIFICATE_PASSWORD
CLEARPLANE_EDGE_BOOTSTRAP_CERTIFICATE_PASSWORD_FILE | — | Environment | Bootstrap | Secret | Restart required | — | Password used to read stored certificates. | | clearplane.edge.bootstrap.challenge-clearance-key | String | Canonical 43-character base64url encoding of 32 bytes, or empty to disable issuance | (empty) | CLEARPLANE_EDGE_BOOTSTRAP_CHALLENGE_CLEARANCE_KEY
CLEARPLANE_EDGE_BOOTSTRAP_CHALLENGE_CLEARANCE_KEY_FILE | — | Environment | Bootstrap | Secret | Restart required | — | Machine key for bot-challenge tokens and clearance cookies. Read once at Edge startup; empty disables issuance, while malformed configured material stops Edge at startup. | | clearplane.edge.bootstrap.core-uri | String | Absolute HTTPS origin | — | CLEARPLANE_EDGE_BOOTSTRAP_CORE_URI | — | Environment | Bootstrap | Public | Restart required | — | Internal Core HTTPS origin used for the mutually authenticated control-plane connection. Credentials, paths, queries and fragments are rejected. | | clearplane.edge.bootstrap.data-path | String | — | ../var/data | CLEARPLANE_EDGE_BOOTSTRAP_DATA_PATH | — | Environment | Bootstrap | Public | Restart required | — | Read-only shared data directory. | | clearplane.edge.bootstrap.http-port | Integer | 1-65535 | 80 | CLEARPLANE_EDGE_BOOTSTRAP_HTTP_PORT | — | Environment | Bootstrap | Public | Restart required | — | HTTP listen port inside the Edge container. | | clearplane.edge.bootstrap.https-port | Integer | 1-65535 | 443 | CLEARPLANE_EDGE_BOOTSTRAP_HTTPS_PORT | — | Environment | Bootstrap | Public | Restart required | — | HTTPS listen port inside the Edge container. | | clearplane.edge.bootstrap.instance-id | String | — | (empty) | CLEARPLANE_EDGE_BOOTSTRAP_INSTANCE_ID | — | Environment | Bootstrap | Public | Restart required | — | Stable Edge instance identifier; defaults to the machine name when empty. | | clearplane.edge.bootstrap.logs-path | String | — | ../var/logs | CLEARPLANE_EDGE_BOOTSTRAP_LOGS_PATH | — | Environment | Bootstrap | Public | Restart required | — | Base directory for Edge logs. | | clearplane.edge.bootstrap.minimum-tls-version | String | 1.2, 1.3 | 1.2 | CLEARPLANE_EDGE_BOOTSTRAP_MINIMUM_TLS_VERSION | — | Environment | Bootstrap | Public | Restart required | — | Minimum TLS version accepted on the HTTPS listener. Any other value stops Edge at startup; TLS 1.0 and 1.1 are unavailable. | | clearplane.edge.bootstrap.waf-memory-admission-percent | Integer | 10-100 | 85 | CLEARPLANE_EDGE_BOOTSTRAP_WAF_MEMORY_ADMISSION_PERCENT | — | Environment | Bootstrap | Public | Restart required | — | Share of the managed heap ceiling a compiled WAF ruleset set may occupy. A configuration revision whose projected cost exceeds this share is refused and the previously published rulesets keep serving. A value outside the accepted range stops Edge at startup. | | clearplane.edge.cache.maximum-per-tier-size-megabytes | Integer | 1-1048576 | 1024 | — | clearplane.edge.cache.maximum-per-tier-size-megabytes | Container label, UI | Runtime | Public | Staged | System / Settings / Edge / Capacity | Maximum response-cache capacity per storage tier in megabytes. The memory tier and the persistent tier each stay within this limit, so both together can reach twice it. | | clearplane.edge.configuration.automatic-apply | Boolean | — | false | — | clearplane.edge.configuration.automatic-apply | Container label, UI | Runtime | Public | Immediate | System / Settings / Edge / Configuration delivery | Apply saved configuration changes to Edge automatically. | | clearplane.edge.configuration.automatic-apply-discovered-routes | Boolean | — | true | — | clearplane.edge.configuration.automatic-apply-discovered-routes | Container label, UI | Runtime | Public | Immediate | System / Settings / Edge / Configuration delivery | Apply container-discovered route changes automatically. | | clearplane.edge.connections.maximum-per-ip | Integer (optional) | Positive integer or empty for unlimited | 100 | — | clearplane.edge.connections.maximum-per-ip | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Request safety | Maximum concurrent connections per client address. | | clearplane.edge.connections.maximum-total | Integer (optional) | Positive integer or empty for unlimited | 10000 | — | clearplane.edge.connections.maximum-total | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Request safety | Maximum concurrent connections accepted by Edge. | | clearplane.edge.http1.enabled | Boolean | — | true | — | clearplane.edge.http1.enabled | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / HTTPS protocols | Accept HTTP/1.1 connections on the public HTTPS listener. The clearplane.edge.http1.enabled label on the Edge container overrides the saved UI value. Keep at least one HTTPS protocol enabled. Changes require an Edge restart; the plain HTTP listener retains HTTP/1.1 for redirects, ACME, and health checks. | | clearplane.edge.http2.enabled | Boolean | — | true | — | clearplane.edge.http2.enabled | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / HTTPS protocols | Accept HTTP/2 connections on the public HTTPS listener. The clearplane.edge.http2.enabled label on the Edge container overrides the saved UI value. Keep at least one HTTPS protocol enabled. Changes require an Edge restart; the plain HTTP listener retains HTTP/1.1 for redirects, ACME, and health checks. | | clearplane.edge.http3.enabled | Boolean | — | true | — | clearplane.edge.http3.enabled | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / HTTPS protocols | Accept HTTP/3 connections on the public HTTPS listener when QUIC is supported. The clearplane.edge.http3.enabled label on the Edge container overrides the saved UI value. Keep at least one HTTPS protocol enabled. HTTP/3 alone requires clients that can discover or directly request it and a QUIC-capable runtime. Changes require an Edge restart. | | clearplane.edge.requests.headers-timeout-seconds | Integer | 1-300 | 30 | — | clearplane.edge.requests.headers-timeout-seconds | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Request safety | Seconds allowed for receiving request headers. | | clearplane.edge.requests.maximum-body-size-bytes | Long integer (optional) | Positive integer or empty for unlimited | 30000000 | — | clearplane.edge.requests.maximum-body-size-bytes | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Request safety | Maximum request-body size in bytes. | | clearplane.edge.requests.maximum-headers-total-size-bytes | Integer | 1024-1048576 | 32768 | — | clearplane.edge.requests.maximum-headers-total-size-bytes | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Request safety | Maximum combined request-header size in bytes. | | clearplane.edge.requests.maximum-uri-length-bytes | Integer | 256-16384 | 8192 | — | clearplane.edge.requests.maximum-uri-length-bytes | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Request safety | Maximum request URI size in bytes. | | clearplane.edge.requests.minimum-body-data-rate-bytes-per-second | Integer (optional) | Positive integer or empty to disable | 240 | — | clearplane.edge.requests.minimum-body-data-rate-bytes-per-second | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Request safety | Minimum request-body data rate in bytes per second. | | clearplane.edge.requests.minimum-body-data-rate-grace-period-seconds | Integer | 1-60 | 5 | — | clearplane.edge.requests.minimum-body-data-rate-grace-period-seconds | Container label, UI | Runtime | Public | Restart required | System / Settings / Edge / Request safety | Grace period in seconds for the minimum request-body data rate. | | clearplane.edge.tracking.maximum-partitions | Integer | 1000-10000000 | 100000 | — | clearplane.edge.tracking.maximum-partitions | Container label, UI | Runtime | Public | Staged | System / Settings / Edge / Capacity | Maximum in-memory partitions retained for rate-limit counting and auto-ban tracking. Unrelated to the response cache. | | clearplane.edge.trusted-proxies | Whitespace list of string values | Whitespace-delimited canonical IPv4 addresses or IPv4 CIDR ranges; /0 is forbidden | (empty) | — | clearplane.edge.trusted-proxies | Container label, UI | Runtime | Public | Staged | System / Settings / Edge / Network | Addresses or CIDR ranges trusted to supply forwarded client information; an empty list trusts none. Never list the Docker bridge gateway address: with Docker's userland proxy or IPv6 published ports every external client arrives from it, and trusting it lets any client choose its own X-Forwarded-For. | | clearplane.edge.upstream.restricted-destination-classes | Whitespace list of UpstreamDestinationRestrictionClass values | Loopback, PrivateNetwork, LinkLocal, CloudMetadata, ControlPlaneNetwork | (empty) | — | clearplane.edge.upstream.restricted-destination-classes | Container label, UI | Runtime | Public | Staged | System / Settings / Edge / Network | Unique whitespace-delimited destination address classes denied for upstream proxy connections. Empty allows all classes. ControlPlaneNetwork may be selected only when control-plane ranges exist. | ## UI directives | Directive | Type | Accepted values | Built-in default | Environment variable | Docker label | Sources | Lifecycle | Sensitivity | Apply | UI location | Description | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | clearplane.ui.bootstrap.data-path | String | — | ../var/data | CLEARPLANE_UI_BOOTSTRAP_DATA_PATH | — | Environment | Bootstrap | Public | Restart required | — | Read-only persistent UI data directory. | | clearplane.ui.bootstrap.logs-path | String | — | ../var/logs | CLEARPLANE_UI_BOOTSTRAP_LOGS_PATH | — | Environment | Bootstrap | Public | Restart required | — | Base directory for UI logs. | | clearplane.ui.bootstrap.public-core-uri | String | Empty or absolute HTTP/HTTPS origin | (empty) | CLEARPLANE_UI_BOOTSTRAP_PUBLIC_CORE_URI | — | Environment | Bootstrap | Public | Restart required | — | Public Core origin for split-port development; empty uses the browser origin. Credentials, paths, queries and fragments are rejected. | ## ContainerProxy directives | Directive | Type | Accepted values | Built-in default | Environment variable | Docker label | Sources | Lifecycle | Sensitivity | Apply | UI location | Description | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | clearplane.container-proxy.bootstrap.data-path | String | — | ../var/data | CLEARPLANE_CONTAINER_PROXY_BOOTSTRAP_DATA_PATH | — | Environment | Bootstrap | Public | Restart required | — | Read-only persistent ContainerProxy data directory. | | clearplane.container-proxy.bootstrap.logs-path | String | — | ../var/logs | CLEARPLANE_CONTAINER_PROXY_BOOTSTRAP_LOGS_PATH | — | Environment | Bootstrap | Public | Restart required | — | Base directory for ContainerProxy logs. | | clearplane.container-proxy.bootstrap.socket-path | String | — | /var/run/docker.sock | CLEARPLANE_CONTAINER_PROXY_BOOTSTRAP_SOCKET_PATH | — | Environment | Bootstrap | Public | Restart required | — | Container-runtime Unix socket path. | ## Proxy directives | Directive | Type | Accepted values | Built-in default | Environment variable | Docker label | Sources | Lifecycle | Sensitivity | Apply | UI location | Description | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | clearplane.proxy.access-control | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.access-control | Container label | Service resource | Public | Immediate | — | Inherit the Global access control policies, turn on this proxy route's own access control policies, or turn the feature off for this route. | | clearplane.proxy.access-control.allow-addresses | Whitespace list of string values | Whitespace-delimited IP addresses or CIDR ranges | (empty) | — | clearplane.proxy.access-control.allow-addresses | Container label | Service resource | Public | Immediate | — | Addresses allowed by the generated inline access control policy. | | clearplane.proxy.access-control.allow-countries | Whitespace list of string values | Whitespace-delimited ISO alpha-2 country codes | (empty) | — | clearplane.proxy.access-control.allow-countries | Container label | Service resource | Public | Immediate | — | Countries allowed by the generated inline access control policy. | | clearplane.proxy.access-control.block-addresses | Whitespace list of string values | Whitespace-delimited IP addresses or CIDR ranges | (empty) | — | clearplane.proxy.access-control.block-addresses | Container label | Service resource | Public | Immediate | — | Addresses blocked by the generated inline access control policy. | | clearplane.proxy.access-control.block-countries | Whitespace list of string values | Whitespace-delimited ISO alpha-2 country codes | (empty) | — | clearplane.proxy.access-control.block-countries | Container label | Service resource | Public | Immediate | — | Countries blocked by the generated inline access control policy. | | clearplane.proxy.access-control.default-action | AccessControlAction | Allow, Block | Allow | — | clearplane.proxy.access-control.default-action | Container label | Service resource | Public | Immediate | — | Default action for the generated inline access control policy. | | clearplane.proxy.access-control.policy | String | Unique whitespace-delimited policy system names | — | — | clearplane.proxy.access-control.policy | Container label | Service resource | Public | Immediate | — | Existing Route-scoped access control policies, each using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.access-control is On. Without it, the route's labels create an inline policy; references cannot be mixed with inline access-control fields. | | clearplane.proxy.additional-hosts | Whitespace list of string values | Unique whitespace-delimited exact DNS hosts (max 253 characters) or single-label wildcards whose base is max 253 characters | (empty) | — | clearplane.proxy.additional-hosts | Container label | Service resource | Public | Immediate | — | Additional public hosts matched by the generated route. They are compared case-insensitively, must not repeat the primary host, and should list a wildcard's base domain explicitly when it should also match. | | clearplane.proxy.authentication | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.authentication | Container label | Service resource | Public | Immediate | — | Turn on this proxy route's own authentication policies. Authentication has no Global policy, so Inherit and Off both leave the route without authentication. | | clearplane.proxy.authentication.basic.realm | String | Non-empty string, up to 200 characters | — | — | clearplane.proxy.authentication.basic.realm | Container label | Service resource | Public | Immediate | — | Required realm shown by the generated Basic authentication challenge. | | clearplane.proxy.authentication.combine-mode | AuthenticationCombineMode | Or, And | Or | — | clearplane.proxy.authentication.combine-mode | Container label | Service resource | Public | Immediate | — | How the route combines several authentication policies. Or accepts a request that satisfies any policy; And requires every policy. | | clearplane.proxy.authentication.jwt.audiences | Whitespace list of string values | 1-20 unique whitespace-delimited values, each up to 400 characters | — | — | clearplane.proxy.authentication.jwt.audiences | Container label | Service resource | Public | Immediate | — | Required accepted JWT audiences for the generated policy. | | clearplane.proxy.authentication.jwt.clock-skew-seconds | Integer | 0 to 300 | 60 | — | clearplane.proxy.authentication.jwt.clock-skew-seconds | Container label | Service resource | Public | Immediate | — | JWT expiry and not-before tolerance in seconds. | | clearplane.proxy.authentication.jwt.issuer | String | Non-empty string, up to 400 characters | — | — | clearplane.proxy.authentication.jwt.issuer | Container label | Service resource | Public | Immediate | — | Required expected JWT issuer claim for the generated policy. | | clearplane.proxy.authentication.key-location | AuthenticationKeyLocation | Edge, Core | Edge | — | clearplane.proxy.authentication.key-location | Container label | Service resource | Public | Immediate | — | Location that verifies credentials for the generated inline policy. | | clearplane.proxy.authentication.policy | String | Unique whitespace-delimited policy system names | — | — | clearplane.proxy.authentication.policy | Container label | Service resource | Public | Immediate | — | Existing authentication policies, each using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.authentication is On. Without it, the route's authentication labels create an inline policy; a reference cannot be mixed with inline authentication fields. | | clearplane.proxy.authentication.type | AuthenticationType | Basic, JwtBearer | — | — | clearplane.proxy.authentication.type | Container label | Service resource | Public | Immediate | — | Authentication method for the generated inline policy. Required when clearplane.proxy.authentication is On without a policy reference. | | clearplane.proxy.auto-ban | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.auto-ban | Container label | Service resource | Public | Immediate | — | Inherit the Global auto-ban policies, turn on this proxy route's own auto-ban policies, or turn the feature off for this route. | | clearplane.proxy.auto-ban.ban-duration-seconds | Integer | Positive integer | 600 | — | clearplane.proxy.auto-ban.ban-duration-seconds | Container label | Service resource | Public | Immediate | — | Initial automatic ban duration in seconds. | | clearplane.proxy.auto-ban.error-response.enabled | Boolean | — | true | — | clearplane.proxy.auto-ban.error-response.enabled | Container label | Service resource | Public | Immediate | — | Ban clients that exceed the configured 4xx-response threshold. Proxied 400–499 responses count, as does Edge's own 401 when presented credentials fail authentication. Server failures never count. | | clearplane.proxy.auto-ban.error-response.status-codes | Whitespace list of integer values | Unique whitespace-delimited HTTP status codes in the 400-499 range | (empty) | — | clearplane.proxy.auto-ban.error-response.status-codes | Container label | Service resource | Public | Immediate | — | Proxied client-error status codes counted by the error-response trigger. Empty counts every 400-499 response. | | clearplane.proxy.auto-ban.error-response.threshold | Integer | Positive integer | 100 | — | clearplane.proxy.auto-ban.error-response.threshold | Container label | Service resource | Public | Immediate | — | Proxied HTTP 400–499 responses permitted during the tracking window before a ban. | | clearplane.proxy.auto-ban.error-response.window-seconds | Integer | Positive integer | 60 | — | clearplane.proxy.auto-ban.error-response.window-seconds | Container label | Service resource | Public | Immediate | — | Proxied 4xx-response tracking window in seconds. | | clearplane.proxy.auto-ban.escalation.enabled | Boolean | — | false | — | clearplane.proxy.auto-ban.escalation.enabled | Container label | Service resource | Public | Immediate | — | Increase repeat ban durations within the escalation window. | | clearplane.proxy.auto-ban.escalation.maximum-duration-seconds | Integer | Positive integer no less than ban-duration-seconds when escalation is enabled | 86400 | — | clearplane.proxy.auto-ban.escalation.maximum-duration-seconds | Container label | Service resource | Public | Immediate | — | Maximum escalated ban duration in seconds. Applies only when escalation is enabled; a policy without escalation always uses the initial duration. | | clearplane.proxy.auto-ban.escalation.multiplier | Integer | Integer greater than or equal to 1; at least 2 when escalation is enabled | 2 | — | clearplane.proxy.auto-ban.escalation.multiplier | Container label | Service resource | Public | Immediate | — | Multiplier applied to repeat automatic bans. | | clearplane.proxy.auto-ban.escalation.window-seconds | Integer | Positive integer | 86400 | — | clearplane.proxy.auto-ban.escalation.window-seconds | Container label | Service resource | Public | Immediate | — | Repeat-ban escalation window in seconds. | | clearplane.proxy.auto-ban.policy | String | Unique whitespace-delimited policy system names | — | — | clearplane.proxy.auto-ban.policy | Container label | Service resource | Public | Immediate | — | Existing Route-scoped auto-ban policies, each using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.auto-ban is On. Without it, the route's labels create an inline policy; references cannot be mixed with inline auto-ban fields. | | clearplane.proxy.auto-ban.rate-limit-violation.enabled | Boolean | — | true | — | clearplane.proxy.auto-ban.rate-limit-violation.enabled | Container label | Service resource | Public | Immediate | — | Ban clients that exceed the rate-limit violation threshold. Only rejections by an IP-keyed rate limit policy count as violations. | | clearplane.proxy.auto-ban.rate-limit-violation.threshold | Integer | Positive integer | 50 | — | clearplane.proxy.auto-ban.rate-limit-violation.threshold | Container label | Service resource | Public | Immediate | — | Rate-limit violations permitted during the violation window before a ban. | | clearplane.proxy.auto-ban.rate-limit-violation.window-seconds | Integer | Positive integer | 60 | — | clearplane.proxy.auto-ban.rate-limit-violation.window-seconds | Container label | Service resource | Public | Immediate | — | Rate-limit violation tracking window in seconds. | | clearplane.proxy.cache | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.cache | Container label | Service resource | Public | Immediate | — | Inherit the Global cache policy, turn on this proxy route's own cache policy, or turn caching off for this route. | | clearplane.proxy.cache.bypass-cookies | Whitespace list of string values | Unique whitespace-delimited cookie names, name prefixes ending in *, or * alone | (empty) | — | clearplane.proxy.cache.bypass-cookies | Container label | Service resource | Public | Immediate | — | Request cookies that make a request bypass the cache. Other request cookies are ignored for caching and still forwarded upstream. | | clearplane.proxy.cache.default-time-to-live-seconds | Integer | 1-31536000 | 7200 | — | clearplane.proxy.cache.default-time-to-live-seconds | Container label | Service resource | Public | Immediate | — | Fresh cache lifetime in seconds when the upstream declares none and no per-status lifetime applies. Must be between the minimum and maximum lifetimes. | | clearplane.proxy.cache.downstream-cache-control | DownstreamCacheControl | Passthrough, Override, Strip | Passthrough | — | clearplane.proxy.cache.downstream-cache-control | Container label | Service resource | Public | Immediate | — | Cache-Control sent to the client. | | clearplane.proxy.cache.downstream-maximum-age-seconds | Integer | 0-31536000 | 0 | — | clearplane.proxy.cache.downstream-maximum-age-seconds | Container label | Service resource | Public | Immediate | — | Client max-age in seconds when the downstream cache control is overridden. | | clearplane.proxy.cache.eligibility | CacheEligibility | StaticFiles, Everything | StaticFiles | — | clearplane.proxy.cache.eligibility | Container label | Service resource | Public | Immediate | — | Requests that use the cache. StaticFiles caches only paths ending in one of the file extensions; Everything caches any path. | | clearplane.proxy.cache.file-extensions | Whitespace list of string values | Unique whitespace-delimited extensions of letters and digits without the leading dot, each up to 32 characters | 7z avi apk avif bin bmp bz2 class css csv dat doc docx dmg ejs eot eps exe flac gif gz ico iso jar jpeg jpg js map mid midi mjs mkv mp3 mp4 ogg otf pdf pict pls png ppt pptx ps rar svg svgz swf tar tif tiff ttf wasm webm webmanifest webp woff woff2 xls xlsx zip zst | — | clearplane.proxy.cache.file-extensions | Container label | Service resource | Public | Immediate | — | File extensions cached when eligibility is StaticFiles. Matching ignores case. | | clearplane.proxy.cache.honor-cdn-cache-control | Boolean | — | true | — | clearplane.proxy.cache.honor-cdn-cache-control | Container label | Service resource | Public | Immediate | — | Prefer the CDN-Cache-Control header over Cache-Control. | | clearplane.proxy.cache.ignore-request-no-cache | Boolean | — | true | — | clearplane.proxy.cache.ignore-request-no-cache | Container label | Service resource | Public | Immediate | — | Serve a stored response despite a client request no-cache directive, so a browser reload cannot force an upstream fetch. | | clearplane.proxy.cache.ignore-request-no-store | Boolean | — | true | — | clearplane.proxy.cache.ignore-request-no-store | Container label | Service resource | Public | Immediate | — | Allow serving and storing a response despite a client request no-store directive. This overrides the client's strongest cache privacy directive. | | clearplane.proxy.cache.ignore-upstream-cache-control | Boolean | — | false | — | clearplane.proxy.cache.ignore-upstream-cache-control | Container label | Service resource | Public | Immediate | — | Discard the lifetime declared by the upstream and use the default lifetime. Cannot be true together with require-upstream-cache-control. | | clearplane.proxy.cache.ignore-upstream-no-cache | Boolean | — | false | — | clearplane.proxy.cache.ignore-upstream-no-cache | Container label | Service resource | Public | Immediate | — | Serve cached responses despite an upstream no-cache directive. | | clearplane.proxy.cache.key.headers | Whitespace list of string values | Unique whitespace-delimited HTTP header names, each up to 200 characters | (empty) | — | clearplane.proxy.cache.key.headers | Container label | Service resource | Public | Immediate | — | Request headers included in cache keys. Authorization, Proxy-Authorization and Cookie are forbidden. | | clearplane.proxy.cache.key.include-host | Boolean | — | true | — | clearplane.proxy.cache.key.include-host | Container label | Service resource | Public | Immediate | — | Include the request host in cache keys. | | clearplane.proxy.cache.key.include-path | Boolean | — | true | — | clearplane.proxy.cache.key.include-path | Container label | Service resource | Public | Immediate | — | Include the request path in cache keys. | | clearplane.proxy.cache.key.query-mode | CacheQueryStringMode | All, None, Include, Exclude | All | — | clearplane.proxy.cache.key.query-mode | Container label | Service resource | Public | Immediate | — | Query-string contribution to cache keys. | | clearplane.proxy.cache.key.query-parameters | Whitespace list of string values | Unique whitespace-delimited names, each non-blank and up to 200 characters | (empty) | — | clearplane.proxy.cache.key.query-parameters | Container label | Service resource | Public | Immediate | — | Query parameters included or excluded by query mode. Include and Exclude require at least one name. | | clearplane.proxy.cache.maximum-response-size-megabytes | Integer | 1-1048576 | 64 | — | clearplane.proxy.cache.maximum-response-size-megabytes | Container label | Service resource | Public | Immediate | — | Maximum cached response size in megabytes. Must not exceed maximum-total-size-megabytes. | | clearplane.proxy.cache.maximum-time-to-live-seconds | Integer | 1-31536000 | 31536000 | — | clearplane.proxy.cache.maximum-time-to-live-seconds | Container label | Service resource | Public | Immediate | — | Ceiling applied to a lifetime declared by the upstream, in seconds. Must not be less than the minimum or default lifetime. | | clearplane.proxy.cache.maximum-total-size-megabytes | Integer | 1-1048576 | 256 | — | clearplane.proxy.cache.maximum-total-size-megabytes | Container label | Service resource | Public | Immediate | — | Cache pool in megabytes shared by every route that uses this policy. | | clearplane.proxy.cache.minimum-time-to-live-seconds | Integer | 0-31536000 | 0 | — | clearplane.proxy.cache.minimum-time-to-live-seconds | Container label | Service resource | Public | Immediate | — | Floor applied to a lifetime declared by the upstream, in seconds. Must not exceed the default or maximum lifetime. | | clearplane.proxy.cache.path-rules | Whitespace list of string values | Up to 32 unique whitespace-delimited pattern=action[,ttl=seconds][,ignore-upstream-cache-control][,browser-ttl=seconds] rules; action is cache or bypass; a pattern starts with / and contains no whitespace, =, comma, ? or # | (empty) | — | clearplane.proxy.cache.path-rules | Container label | Service resource | Public | Immediate | — | Ordered path rules; the first rule whose pattern matches the request path applies, and * matches any characters including /. cache caches the path whatever the eligibility and extensions, optionally with its own lifetime (ttl), without the upstream's lifetime (ignore-upstream-cache-control) and with a client max-age (browser-ttl); bypass never caches it. For example: /_framework/*=cache,ttl=31536000 /api/*=bypass /=cache. | | clearplane.proxy.cache.policy | String | One policy system name | — | — | clearplane.proxy.cache.policy | Container label | Service resource | Public | Immediate | — | One existing Route-scoped cache policy using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.cache is On. Without it, the route's labels create an inline policy; the reference cannot be mixed with inline cache fields. | | clearplane.proxy.cache.purge-on-redeploy | Boolean | — | true | — | clearplane.proxy.cache.purge-on-redeploy | Container label | Service resource | Public | Immediate | — | Purge this route's cached responses when discovery sees its container recreated, for example after a deploy. | | clearplane.proxy.cache.require-upstream-cache-control | Boolean | — | false | — | clearplane.proxy.cache.require-upstream-cache-control | Container label | Service resource | Public | Immediate | — | Cache only responses that declare a cache lifetime. Cannot be true together with ignore-upstream-cache-control. | | clearplane.proxy.cache.stale-if-error-seconds | Integer | 0-31536000 | 300 | — | clearplane.proxy.cache.stale-if-error-seconds | Container label | Service resource | Public | Immediate | — | Stale-if-error window in seconds. | | clearplane.proxy.cache.stale-while-revalidate-seconds | Integer | 0-31536000 | 30 | — | clearplane.proxy.cache.stale-while-revalidate-seconds | Container label | Service resource | Public | Immediate | — | Stale-while-revalidate window in seconds. | | clearplane.proxy.cache.status-codes | Whitespace list of integer values | Unique whitespace-delimited HTTP status codes from 100 through 599 | 200 301 302 303 404 410 | — | clearplane.proxy.cache.status-codes | Container label | Service resource | Public | Immediate | — | Response status codes eligible for caching. | | clearplane.proxy.cache.status-codes-time-to-live | Whitespace list of string values | Non-overlapping whitespace-delimited code[-code]=seconds entries; codes 100-599 and seconds 0-31536000 | 302-303=1200 404=180 410=180 | — | clearplane.proxy.cache.status-codes-time-to-live | Container label | Service resource | Public | Immediate | — | Per-status cache lifetimes that replace the default lifetime when the upstream declares none. | | clearplane.proxy.cache.storage-mode | CacheStorageMode | MemoryOnly, PersistentOnly, MemoryWithPersistentFallback | MemoryWithPersistentFallback | — | clearplane.proxy.cache.storage-mode | Container label | Service resource | Public | Immediate | — | Cache storage mode. | | clearplane.proxy.cache.vary-handling | CacheVaryHandling | Honor, Ignore | Honor | — | clearplane.proxy.cache.vary-handling | Container label | Service resource | Public | Immediate | — | Honor stores a separate copy per value of each header the upstream lists in Vary; Ignore stores one copy regardless of Vary. Vary: *, Cookie or Authorization is never stored. | | clearplane.proxy.certificate.additional-domains | Whitespace list of string values | Unique whitespace-delimited exact DNS hosts (max 253 characters) or single-label wildcards whose base is max 253 characters | (empty) | — | clearplane.proxy.certificate.additional-domains | Container label | Service resource | Public | Immediate | — | Extra certificate domains beyond the route's hosts and redirect sources. The final certificate may have at most 99 subject alternative names. Wildcards require a DNS profile or inline credentials. | | clearplane.proxy.certificate.dns.api-token | String | Non-empty single-line value, up to 4096 characters | — | — | clearplane.proxy.certificate.dns.api-token | Container label | Service resource | Secret | Immediate | — | Required whenever any inline DNS field is present. Core encrypts the token before persistence. Inline DNS fields cannot be combined with dns.profile. | | clearplane.proxy.certificate.dns.profile | String | Trimmed non-empty profile name, up to 200 characters | — | — | clearplane.proxy.certificate.dns.profile | Container label | Service resource | Public | Immediate | — | Named DNS profile used for DNS-01 validation. Cannot be combined with the dns.provider, dns.api-token, or dns.propagation-seconds fields. Without either form of DNS configuration, HTTP-01 is used. | | clearplane.proxy.certificate.dns.propagation-seconds | Integer (optional) | 1-3600, or empty for the provider default | — | — | clearplane.proxy.certificate.dns.propagation-seconds | Container label | Service resource | Public | Immediate | — | Optional propagation delay in seconds for this route's inline DNS credentials. Requires dns.api-token. | | clearplane.proxy.certificate.dns.provider | AcmeDnsProvider | Cloudflare | Cloudflare | — | clearplane.proxy.certificate.dns.provider | Container label | Service resource | Public | Immediate | — | Provider for this route's inline DNS credentials. Requires dns.api-token and cannot be combined with the dns.profile field. | | clearplane.proxy.certificate.domain | String | Exact DNS host, up to 253 characters | — | — | clearplane.proxy.certificate.domain | Container label | Service resource | Public | Immediate | — | Primary certificate domain. Defaults to the route host or the base of a covering wildcard route host. An explicit domain must not be covered by a requested wildcard. Wildcard route hosts are included in the certificate and require a DNS profile. | | clearplane.proxy.certificate.enabled | Boolean | — | false | — | clearplane.proxy.certificate.enabled | Container label | Service resource | Public | Immediate | — | Request and renew an ACME certificate for this proxy route. | | clearplane.proxy.certificate.wildcard | Boolean | — | false | — | clearplane.proxy.certificate.wildcard | Container label | Service resource | Public | Immediate | — | Include a one-label wildcard for the primary certificate domain. Enabling it requires a named DNS profile or inline DNS credentials. | | clearplane.proxy.compression | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.compression | Container label | Service resource | Public | Immediate | — | Inherit the Global compression policy, turn on this proxy route's own compression policy, or turn the feature off for this route. | | clearplane.proxy.compression.brotli.enabled | Boolean | — | true | — | clearplane.proxy.compression.brotli.enabled | Container label | Service resource | Public | Immediate | — | Enable Brotli response compression in the generated inline policy. At least one of Brotli or gzip must be enabled. | | clearplane.proxy.compression.brotli.level | Integer | 0 to 11 | 4 | — | clearplane.proxy.compression.brotli.level | Container label | Service resource | Public | Immediate | — | Brotli quality level for the generated inline policy. | | clearplane.proxy.compression.content-types | Whitespace list of string values | Up to 256 unique whitespace-delimited media-type selectors, each up to 200 characters; prefix exclusions with ! | text/* application/json application/*+json application/javascript application/x-javascript application/xml application/*+xml application/wasm image/svg+xml font/* application/vnd.ms-fontobject application/x-font-opentype application/x-font-truetype application/x-font-ttf !text/event-stream !font/woff !font/woff2 | — | clearplane.proxy.compression.content-types | Container label | Service resource | Public | Immediate | — | Response content types eligible for compression. Selectors may be exact, type/*, type/*+suffix, or */*. Exclusions always win, the combined selectors must leave at least one included type, and HTTP request methods are not filtered. | | clearplane.proxy.compression.gzip.enabled | Boolean | — | true | — | clearplane.proxy.compression.gzip.enabled | Container label | Service resource | Public | Immediate | — | Enable gzip response compression in the generated inline policy. At least one of Brotli or gzip must be enabled. | | clearplane.proxy.compression.gzip.level | Integer | 1 to 9 | 6 | — | clearplane.proxy.compression.gzip.level | Container label | Service resource | Public | Immediate | — | gzip compression level for the generated inline policy. | | clearplane.proxy.compression.minimum-length-bytes | Integer | 0 to 1048576 | 1024 | — | clearplane.proxy.compression.minimum-length-bytes | Container label | Service resource | Public | Immediate | — | Minimum identity response body length in bytes before compression is applied. | | clearplane.proxy.compression.policy | String | One policy system name | — | — | clearplane.proxy.compression.policy | Container label | Service resource | Public | Immediate | — | One existing Route-scoped compression policy using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.compression is On. Without it, the route's labels create an inline policy; the reference cannot be mixed with inline compression fields. | | clearplane.proxy.cors | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.cors | Container label | Service resource | Public | Immediate | — | Inherit the Global CORS policy, turn on this proxy route's own CORS policy, or turn the feature off for this route. | | clearplane.proxy.cors.allow-any-header | Boolean | — | true | — | clearplane.proxy.cors.allow-any-header | Container label | Service resource | Public | Immediate | — | Allow any request header. | | clearplane.proxy.cors.allow-any-method | Boolean | — | true | — | clearplane.proxy.cors.allow-any-method | Container label | Service resource | Public | Immediate | — | Allow any request method. | | clearplane.proxy.cors.allow-credentials | Boolean | — | false | — | clearplane.proxy.cors.allow-credentials | Container label | Service resource | Public | Immediate | — | Allow credentialed cross-origin requests. Cannot be combined with the wildcard origin. | | clearplane.proxy.cors.allowed-headers | Whitespace list of string values | Unique HTTP header names up to 200 characters; non-empty when allow-any-header is false | (empty) | — | clearplane.proxy.cors.allowed-headers | Container label | Service resource | Public | Immediate | — | Request headers allowed when allow-any-header is false. | | clearplane.proxy.cors.allowed-methods | Whitespace list of string values | Unique non-empty whitespace-delimited HTTP method tokens when allow-any-method is false | (empty) | — | clearplane.proxy.cors.allowed-methods | Container label | Service resource | Public | Immediate | — | Methods allowed when allow-any-method is false. | | clearplane.proxy.cors.allowed-origins | Whitespace list of string values | Unique whitespace-delimited HTTP origins, or * by itself | (empty) | — | clearplane.proxy.cors.allowed-origins | Container label | Service resource | Public | Immediate | — | Origins allowed by the generated inline CORS policy. Credentials cannot be enabled with the wildcard origin. | | clearplane.proxy.cors.exposed-headers | Whitespace list of string values | Unique whitespace-delimited HTTP header names, each up to 200 characters | (empty) | — | clearplane.proxy.cors.exposed-headers | Container label | Service resource | Public | Immediate | — | Response headers exposed to the browser. | | clearplane.proxy.cors.policy | String | One policy system name | — | — | clearplane.proxy.cors.policy | Container label | Service resource | Public | Immediate | — | One existing Route-scoped CORS policy using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.cors is On. Without it, the route's labels create an inline policy; the reference cannot be mixed with inline CORS fields. | | clearplane.proxy.cors.preflight-max-age-seconds | Integer | 0 to 86400 | 0 | — | clearplane.proxy.cors.preflight-max-age-seconds | Container label | Service resource | Public | Immediate | — | Preflight cache lifetime in seconds. | | clearplane.proxy.cors.upstream-header-mode | CorsUpstreamHeaderMode | Override, Preserve | Override | — | clearplane.proxy.cors.upstream-header-mode | Container label | Service resource | Public | Immediate | — | Override replaces the proxied service's CORS headers with this policy's. Preserve forwards preflights and applies this policy only when the service returned no Access-Control-Allow-Origin, so it cannot deny an origin the service allows — the service's own headers win whenever it sends them. If the service does not answer OPTIONS, Preserve forwards the preflight and the service's 404/405 reaches the browser, failing every non-simple cross-origin request to that route. | | clearplane.proxy.enabled | Boolean | — | false | — | clearplane.proxy.enabled | Container label | Service resource | Public | Immediate | — | Publish this container through Clearplane. | | clearplane.proxy.error-page.enabled | Boolean | — | true | — | clearplane.proxy.error-page.enabled | Container label | Service resource | Public | Immediate | — | Replace selected error responses with Clearplane's branded HTML page for clients that accept HTML. | | clearplane.proxy.error-page.status-codes | Whitespace list of integer values | Whitespace-delimited HTTP status codes and inclusive ranges from 400 through 599; prefix exclusions with ! (for example, 400-599 !404) | 502 503 504 | — | clearplane.proxy.error-page.status-codes | Container label | Service resource | Public | Immediate | — | Error response status codes eligible for branded replacement. At least one inclusion is required, included codes and ranges cannot overlap, and exclusions must leave a non-empty result. | | clearplane.proxy.group.collapsed-by-default | Boolean | — | false | — | clearplane.proxy.group.collapsed-by-default | Container label | Service resource | Public | Immediate | — | Collapse this resource group by default in route and cluster overviews. Ignored when group.name is absent. | | clearplane.proxy.group.name | String | Trimmed non-blank name, up to 200 characters | — | — | clearplane.proxy.group.name | Container label | Service resource | Public | Immediate | — | Optional resource group assigned to the generated route and cluster. The order and collapsed fields are ignored with a warning when this name label is absent. | | clearplane.proxy.group.order | Integer | — | 0 | — | clearplane.proxy.group.order | Container label | Service resource | Public | Immediate | — | Resource group display order. Any signed integer is accepted and lower values appear first. Ignored when group.name is absent. | | clearplane.proxy.host | String | Exact DNS host (maximum 253 characters) or single-label wildcard with a base up to 253 characters | — | — | clearplane.proxy.host | Container label | Service resource | Public | Immediate | — | Required public host matched by the generated route. A wildcard such as '*.example.com' excludes its base domain; canonical host redirects require an exact host. | | clearplane.proxy.methods | Whitespace list of string values | Unique whitespace-delimited HTTP method tokens | (empty) | — | clearplane.proxy.methods | Container label | Service resource | Public | Immediate | — | HTTP methods matched by the generated route. Values are normalized to uppercase; duplicates after normalization are rejected. Empty matches every method. | | clearplane.proxy.name | String | Non-blank name within the generated resource limits | — | — | clearplane.proxy.name | Container label | Service resource | Public | Immediate | — | Optional base name for the generated route, cluster, and inline access control, authentication, auto-ban, cache, compression, CORS, rate limit, request headers, response headers and WAF policies. Defaults to the container discovery key. The maximum depends on which generated resources are enabled, and an overlong name reports the exact applicable limit. | | clearplane.proxy.order | Integer | Signed integer from -2147483638 to 2147483647 | 0 | — | clearplane.proxy.order | Container label | Service resource | Public | Immediate | — | Route match order. Lower values are evaluated first; the ten lowest signed integers are reserved for Clearplane management and guard routes. | | clearplane.proxy.path | String | Non-empty complete route path pattern other than /_clearplane/challenge, up to 2000 characters | /{**catch-all} | — | clearplane.proxy.path | Container label | Service resource | Public | Immediate | — | Complete public path pattern matched by the generated route, using the same route-template syntax as the UI and REST API. Use '/api/{**catch-all}' to match /api and every path below it; use '/api' to match only that literal path. | | clearplane.proxy.path-rewrite | String | Valid route path pattern, up to 500 characters | — | — | clearplane.proxy.path-rewrite | Container label | Service resource | Public | Immediate | — | Optional ASP.NET route pattern written before forwarding to the upstream service. Relative and slash-prefixed patterns are accepted; empty or whitespace disables rewriting. | | clearplane.proxy.port | Integer | 1-65535 | — | — | clearplane.proxy.port | Container label | Service resource | Public | Immediate | — | Container port reached by Edge. | | clearplane.proxy.preserve-host-header | Boolean | true, false | false | — | clearplane.proxy.preserve-host-header | Container label | Service resource | Public | Immediate | — | Forward the incoming Host header, including its port, to the upstream service. Enable for upstreams that validate the public hostname. Independent of X-Forwarded-Host. | | clearplane.proxy.rate-limit | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.rate-limit | Container label | Service resource | Public | Immediate | — | Inherit the Global rate limit policies, turn on this proxy route's own rate limit policies, or turn the feature off for this route. | | clearplane.proxy.rate-limit.action | RateLimitAction | Reject, Challenge | Reject | — | clearplane.proxy.rate-limit.action | Container label | Service resource | Public | Immediate | — | What the generated inline rate limit policy does when a client exceeds the limit. Reject returns 429. Challenge asks eligible browsers to complete proof of work and returns 429 to other clients; the route must enable bot challenges. | | clearplane.proxy.rate-limit.header-name | String | Non-empty header name, up to 200 characters | — | — | clearplane.proxy.rate-limit.header-name | Container label | Service resource | Public | Immediate | — | Required partition header when the generated rate limit policy key type is Header; otherwise it is optional and unused. | | clearplane.proxy.rate-limit.key-type | RateLimitKeyType | Ip, Path, Header | Ip | — | clearplane.proxy.rate-limit.key-type | Container label | Service resource | Public | Immediate | — | Partition key for the generated inline rate limit policy. | | clearplane.proxy.rate-limit.policy | String | Unique whitespace-delimited policy system names | — | — | clearplane.proxy.rate-limit.policy | Container label | Service resource | Public | Immediate | — | Existing Route-scoped rate limit policies, each using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.rate-limit is On. Without it, the route's labels create an inline policy; references cannot be mixed with inline rate-limit fields. | | clearplane.proxy.rate-limit.request-limit | Integer | Positive integer | 100 | — | clearplane.proxy.rate-limit.request-limit | Container label | Service resource | Public | Immediate | — | Requests permitted in each generated rate-limit window. | | clearplane.proxy.rate-limit.window-seconds | Integer | Positive integer | 60 | — | clearplane.proxy.rate-limit.window-seconds | Container label | Service resource | Public | Immediate | — | Window length in seconds for the generated rate limit policy. | | clearplane.proxy.redirect.from-hosts | Whitespace list of string values | Case-insensitively unique whitespace-delimited exact DNS hosts, each up to 253 characters | (empty) | — | clearplane.proxy.redirect.from-hosts | Container label | Service resource | Public | Immediate | — | Exact source hosts redirected to the route host. The primary route host must be exact rather than wildcard, and these sources must differ from it and not overlap any additional forwarding host. | | clearplane.proxy.redirect.http-to-https | Boolean (optional) | — | — | — | clearplane.proxy.redirect.http-to-https | Container label | Service resource | Public | Immediate | — | Redirect HTTP requests to HTTPS after the canonical host certificate is ready. Defaults to certificate.enabled. | | clearplane.proxy.redirect.status-code | RedirectStatusCode | 301, 302, 307, 308 | 308 | — | clearplane.proxy.redirect.status-code | Container label | Service resource | Public | Immediate | — | Status code used by host and scheme redirects on this route. | | clearplane.proxy.request-headers | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.request-headers | Container label | Service resource | Public | Immediate | — | Inherit the Global request headers policy, turn on this proxy route's own request headers policy, or turn the feature off for this route. | | clearplane.proxy.request-headers.add-x-request-id | Boolean | — | true | — | clearplane.proxy.request-headers.add-x-request-id | Container label | Service resource | Public | Immediate | — | Add X-Request-ID when absent in the generated inline policy. | | clearplane.proxy.request-headers.forward-x-forwarded-for | Boolean | — | true | — | clearplane.proxy.request-headers.forward-x-forwarded-for | Container label | Service resource | Public | Immediate | — | Forward X-Forwarded-For in the generated inline policy. | | clearplane.proxy.request-headers.forward-x-forwarded-host | Boolean | — | true | — | clearplane.proxy.request-headers.forward-x-forwarded-host | Container label | Service resource | Public | Immediate | — | Forward X-Forwarded-Host in the generated inline policy. | | clearplane.proxy.request-headers.forward-x-forwarded-proto | Boolean | — | true | — | clearplane.proxy.request-headers.forward-x-forwarded-proto | Container label | Service resource | Public | Immediate | — | Forward X-Forwarded-Proto in the generated inline policy. | | clearplane.proxy.request-headers.forward-x-real-ip | Boolean | — | true | — | clearplane.proxy.request-headers.forward-x-real-ip | Container label | Service resource | Public | Immediate | — | Forward X-Real-IP in the generated inline policy. | | clearplane.proxy.request-headers.policy | String | One policy system name | — | — | clearplane.proxy.request-headers.policy | Container label | Service resource | Public | Immediate | — | One existing Route-scoped request headers policy using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.request-headers is On. Without it, the route's labels create an inline policy; the reference cannot be mixed with inline request-header fields. | | clearplane.proxy.response-headers | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.response-headers | Container label | Service resource | Public | Immediate | — | Inherit the Global response headers policy, turn on this proxy route's own response headers policy, or turn the feature off for this route. | | clearplane.proxy.response-headers.content-security-policy | String | Value without CR/LF, up to 4000 characters; or empty | (empty) | — | clearplane.proxy.response-headers.content-security-policy | Container label | Service resource | Public | Immediate | — | Content-Security-Policy value for the generated inline policy. Empty keeps the upstream service's own header. | | clearplane.proxy.response-headers.permissions-policy | String | Value without CR/LF, up to 2000 characters; or empty | camera=(), microphone=(), geolocation=() | — | clearplane.proxy.response-headers.permissions-policy | Container label | Service resource | Public | Immediate | — | Permissions-Policy value for the generated inline policy. Empty leaves the header unset. | | clearplane.proxy.response-headers.policy | String | One policy system name | — | — | clearplane.proxy.response-headers.policy | Container label | Service resource | Public | Immediate | — | One existing Route-scoped response headers policy using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.response-headers is On. Without it, the route's labels create an inline policy; the reference cannot be mixed with inline response-header fields. | | clearplane.proxy.response-headers.referrer-policy | String | no-referrer, no-referrer-when-downgrade, origin, origin-when-cross-origin, same-origin, strict-origin, strict-origin-when-cross-origin, unsafe-url, or empty | strict-origin-when-cross-origin | — | clearplane.proxy.response-headers.referrer-policy | Container label | Service resource | Public | Immediate | — | Referrer-Policy value for the generated inline policy, up to 200 characters. Empty leaves the header unset. | | clearplane.proxy.response-headers.strict-transport-security | String | One numeric max-age plus optional unique includeSubDomains and preload directives, up to 4000 characters; or empty | max-age=31536000; includeSubDomains | — | clearplane.proxy.response-headers.strict-transport-security | Container label | Service resource | Public | Immediate | — | Strict-Transport-Security value for the generated inline policy. Directives are semicolon-delimited, CR/LF is forbidden, and empty leaves the header unset. | | clearplane.proxy.response-headers.strip-server-header | Boolean | — | true | — | clearplane.proxy.response-headers.strip-server-header | Container label | Service resource | Public | Immediate | — | Remove the Server response header in the generated inline policy. | | clearplane.proxy.response-headers.strip-x-asp-net-version-header | Boolean | — | true | — | clearplane.proxy.response-headers.strip-x-asp-net-version-header | Container label | Service resource | Public | Immediate | — | Remove the X-AspNet-Version response header in the generated inline policy. | | clearplane.proxy.response-headers.strip-x-powered-by-header | Boolean | — | true | — | clearplane.proxy.response-headers.strip-x-powered-by-header | Container label | Service resource | Public | Immediate | — | Remove the X-Powered-By response header in the generated inline policy. | | clearplane.proxy.response-headers.x-content-type-options-no-sniff | Boolean | — | true | — | clearplane.proxy.response-headers.x-content-type-options-no-sniff | Container label | Service resource | Public | Immediate | — | Set X-Content-Type-Options to nosniff in the generated inline policy. | | clearplane.proxy.response-headers.x-frame-options | String | DENY, SAMEORIGIN, or empty | DENY | — | clearplane.proxy.response-headers.x-frame-options | Container label | Service resource | Public | Immediate | — | X-Frame-Options value for the generated inline policy. Empty leaves the header unset. | | clearplane.proxy.strip-prefix | String | Path prefix beginning with /, up to 500 characters | — | — | clearplane.proxy.strip-prefix | Container label | Service resource | Public | Immediate | — | Optional path prefix removed before forwarding to the upstream service. Empty or whitespace disables stripping. | | clearplane.proxy.upstream.activity-timeout-seconds | Integer (optional) | 1-86400 | 60 | — | clearplane.proxy.upstream.activity-timeout-seconds | Container label | Service resource | Public | Immediate | — | Maximum upstream inactivity in seconds while sending the request or reading the response. Resets whenever data moves. | | clearplane.proxy.upstream.protocol | UpstreamProtocol | Auto, Http2 | Auto | — | clearplane.proxy.upstream.protocol | Container label | Service resource | Public | Immediate | — | Protocol Edge uses to reach the upstream. Http2 forces HTTP/2 exactly, including prior-knowledge h2c to plain-HTTP upstreams, as gRPC requires; Auto negotiates. | | clearplane.proxy.waf | PolicyState | Inherit, On, Off | Inherit | — | clearplane.proxy.waf | Container label | Service resource | Public | Immediate | — | Inherit the Global WAF policy, turn on this proxy route's own WAF policy, or turn the feature off for this route. | | clearplane.proxy.waf.allowed-methods | Whitespace list of string values | Up to 32 unique uppercase HTTP method names, each up to 32 characters | (empty) | — | clearplane.proxy.waf.allowed-methods | Container label | Service resource | Public | Immediate | — | Methods the route's inline policy allows in addition to the WAF rulesets' defaults (GET, HEAD, POST, OPTIONS, PUT, PATCH, DELETE), such as PROPFIND MKCOL. Values start with A-Z and then use A-Z, digits, underscore or dash. | | clearplane.proxy.waf.allowed-request-content-types | Whitespace list of string values | Up to 32 unique lowercase media types without parameters, each up to 255 characters | (empty) | — | clearplane.proxy.waf.allowed-request-content-types | Container label | Service resource | Public | Immediate | — | Request body media types the route's inline policy allows in addition to the WAF rulesets' defaults, such as text/plain. Bodies are still inspected as raw text. | | clearplane.proxy.waf.challenge.clearance-minutes | Integer | 5 to 1440 | 30 | — | clearplane.proxy.waf.challenge.clearance-minutes | Container label | Service resource | Public | Immediate | — | How long a passed challenge lasts. | | clearplane.proxy.waf.challenge.difficulty | Integer | 12 to 24 | 18 | — | clearplane.proxy.waf.challenge.difficulty | Container label | Service resource | Public | Immediate | — | Proof-of-work difficulty in leading zero bits. | | clearplane.proxy.waf.challenge.mode | WafChallengeMode | Off, ProofOfWork | Off | — | clearplane.proxy.waf.challenge.mode | Container label | Service resource | Public | Immediate | — | Serve proof-of-work bot challenges on the route. Requires Prevention; routes without redirect.http-to-https never challenge. Eligible browser requests can be challenged by WAF rules, Combined scores or Challenge rate limits. | | clearplane.proxy.waf.challenge.threshold | Integer | 1 to threshold - 1 | 3 | — | clearplane.proxy.waf.challenge.threshold | Container label | Service resource | Public | Immediate | — | Combined anomaly score at which an eligible browser is challenged. Must stay below threshold. | | clearplane.proxy.waf.detection-paranoia-level | Integer (optional) | Paranoia level through 4, or empty | — | — | clearplane.proxy.waf.detection-paranoia-level | Container label | Service resource | Public | Immediate | — | Rules above the blocking paranoia level, up to and including this level, score in Detection only. It may equal the blocking level; empty disables the additional detection-only band. | | clearplane.proxy.waf.exclusion-rulesets | Whitespace list of string values | Up to 256 unique whitespace-delimited ruleset IDs, each up to 200 characters | (empty) | — | clearplane.proxy.waf.exclusion-rulesets | Container label | Service resource | Public | Immediate | — | Exclusion rulesets the route's inline policy opts into. IDs start with a lowercase letter or digit and then contain lowercase letters, digits, dots or dashes. Exclusion rulesets never apply without opting in. | | clearplane.proxy.waf.grpc.maximum-message-bytes | Integer | 1024 to 16777216 | 4194304 | — | clearplane.proxy.waf.grpc.maximum-message-bytes | Container label | Service resource | Public | Immediate | — | Largest gRPC message the route's inline policy inspects. | | clearplane.proxy.waf.grpc.maximum-messages | Integer | 1 to 1024 | 16 | — | clearplane.proxy.waf.grpc.maximum-messages | Container label | Service resource | Public | Immediate | — | gRPC messages inspected per stream by the route's inline policy. | | clearplane.proxy.waf.mode | WafMode | Detection, Prevention | Detection | — | clearplane.proxy.waf.mode | Container label | Service resource | Public | Immediate | — | WAF mode of the route's inline policy. Detection records findings without blocking; Prevention blocks when the policy reaches its blocking decision. | | clearplane.proxy.waf.opt-out-rulesets | Whitespace list of string values | Up to 256 unique whitespace-delimited ruleset IDs, each up to 200 characters | (empty) | — | clearplane.proxy.waf.opt-out-rulesets | Container label | Service resource | Public | Immediate | — | Active WAF rulesets the route's inline policy does not use. IDs start with a lowercase letter or digit and then contain lowercase letters, digits, dots or dashes. | | clearplane.proxy.waf.paranoia-level | Integer | 1 to 4 | 1 | — | clearplane.proxy.waf.paranoia-level | Container label | Service resource | Public | Immediate | — | Paranoia level. Rules at or below this level can block. | | clearplane.proxy.waf.policy | String | One policy system name | — | — | clearplane.proxy.waf.policy | Container label | Service resource | Public | Immediate | — | One existing Route-scoped WAF policy using lowercase letters, digits, and single dashes between words with a 200-character maximum. Used only when clearplane.proxy.waf is On. Without it, the route's labels create an inline policy; the reference cannot be mixed with inline WAF fields. | | clearplane.proxy.waf.profile | WafProfile | Standard, Management | Standard | — | clearplane.proxy.waf.profile | Container label | Service resource | Public | Immediate | — | WAF profile of the route's inline policy. | | clearplane.proxy.waf.request-body.inspection-mode | WafBodyInspectionMode | MetadataOnly, MemoryBuffered, DiskSpool | MemoryBuffered | — | clearplane.proxy.waf.request-body.inspection-mode | Container label | Service resource | Public | Immediate | — | How the route's inline policy reads ordinary request bodies. MetadataOnly skips them; MemoryBuffered buffers up to request-body.maximum-bytes; DiskSpool spools larger bodies to disk. WebSocket and gRPC use their own limits. | | clearplane.proxy.waf.request-body.maximum-bytes | Long integer (optional) | 1 to 104857600 | — | — | clearplane.proxy.waf.request-body.maximum-bytes | Container label | Service resource | Public | Immediate | — | Request body bytes the route's inline policy inspects. Defaults to 1048576, or 262144 with the Management profile. With Block, active ruleset profiles can lower this limit. | | clearplane.proxy.waf.request-body.maximum-spooled-bytes | Long integer | request-body.maximum-bytes to 1073741824 | 104857600 | — | clearplane.proxy.waf.request-body.maximum-spooled-bytes | Container label | Service resource | Public | Immediate | — | Raw request body bytes inspected from disk under DiskSpool with InspectPrefix. | | clearplane.proxy.waf.request-body.oversize-action | WafOversizeBodyAction | Block, InspectPrefix | Block | — | clearplane.proxy.waf.request-body.oversize-action | Container label | Service resource | Public | Immediate | — | What happens to a request body above the inspection limit. Block rejects it in Prevention; InspectPrefix inspects its first bytes, and with disk spooling its raw content up to request-body.maximum-spooled-bytes, then forwards it. | | clearplane.proxy.waf.request-context.enabled | Boolean | — | true | — | clearplane.proxy.waf.request-context.enabled | Container label | Service resource | Public | Immediate | — | Record the redacted query string, request headers and matched values of the route's WAF detections. Settings → Firewall defines what is redacted and can turn capture off everywhere. | | clearplane.proxy.waf.request-context.header-capture-mode | WafHeaderCaptureMode | Allowlist, RedactSensitive | Allowlist | — | clearplane.proxy.waf.request-context.header-capture-mode | Container label | Service resource | Public | Immediate | — | Which request header values a detection records. Allowlist records only the values of the headers listed under Settings → Firewall and redacts the rest; RedactSensitive records every value except the sensitive headers listed there. | | clearplane.proxy.waf.response.inspection | WafResponseInspection | Off, Headers, HeadersAndBody | Off | — | clearplane.proxy.waf.response.inspection | Container label | Service resource | Public | Immediate | — | Inspect upstream responses under the route's inline policy. Headers inspects status and headers before any byte is sent; HeadersAndBody also buffers text, JSON, XML and JavaScript bodies up to response.maximum-body-bytes, which adds latency. Streaming responses are never held. | | clearplane.proxy.waf.response.maximum-body-bytes | Integer | 1024 to 16777216 | 1048576 | — | clearplane.proxy.waf.response.maximum-body-bytes | Container label | Service resource | Public | Immediate | — | Response body bytes buffered for inspection under HeadersAndBody. | | clearplane.proxy.waf.response.threshold | Integer | 1 to 100 | 4 | — | clearplane.proxy.waf.response.threshold | Container label | Service resource | Public | Immediate | — | Response anomaly score at which the route's inline policy blocks in Prevention. | | clearplane.proxy.waf.scoring-mode | WafScoringMode | Combined, PerRuleset | Combined | — | clearplane.proxy.waf.scoring-mode | Container label | Service resource | Public | Immediate | — | Scoring mode of the route's inline policy. Combined adds the Prevention rulesets' scores against one threshold; PerRuleset gives each ruleset its own threshold. | | clearplane.proxy.waf.threshold | Integer | 5 to 100 | 5 | — | clearplane.proxy.waf.threshold | Container label | Service resource | Public | Immediate | — | Combined anomaly score at which the route's inline policy blocks in Prevention. | | clearplane.proxy.waf.websocket.enabled | Boolean | — | true | — | clearplane.proxy.waf.websocket.enabled | Container label | Service resource | Public | Immediate | — | Inspect client-to-server WebSocket messages under the route's inline policy. Each message is scored on its own; in Prevention a blocking message closes the connection with status 1008. | | clearplane.proxy.waf.websocket.maximum-message-bytes | Integer | 1024 to 16777216 | 1048576 | — | clearplane.proxy.waf.websocket.maximum-message-bytes | Container label | Service resource | Public | Immediate | — | Largest WebSocket message the route's inline policy inspects. | | clearplane.proxy.authentication.basic.credentials.<index>.password | String | Non-empty string up to 400 characters | — | — | clearplane.proxy.authentication.basic.credentials.<index>.password | Container label | Service resource | Secret | Immediate | — | Required plaintext credential password. Clearplane hashes the value before persistence. | | clearplane.proxy.authentication.basic.credentials.<index>.username | String | Non-empty string up to 200 characters | — | — | clearplane.proxy.authentication.basic.credentials.<index>.username | Container label | Service resource | Public | Immediate | — | Required credential username. Usernames must be unique across the indexed entries. | | clearplane.proxy.authentication.jwt.required-claims.<index>.claim | String | Non-empty string up to 200 characters | — | — | clearplane.proxy.authentication.jwt.required-claims.<index>.claim | Container label | Service resource | Public | Immediate | — | JWT claim name required on accepted tokens. A claim/value pair cannot duplicate an earlier entry. | | clearplane.proxy.authentication.jwt.required-claims.<index>.value | String | Non-empty string up to 200 characters | — | — | clearplane.proxy.authentication.jwt.required-claims.<index>.value | Container label | Service resource | Public | Immediate | — | Required value for the indexed JWT claim. A claim/value pair cannot duplicate an earlier entry. | | clearplane.proxy.authentication.jwt.signing-keys.<index>.kind | JwtKeyKind | Symmetric, RsaPublic, EcPublic | — | — | clearplane.proxy.authentication.jwt.signing-keys.<index>.kind | Container label | Service resource | Public | Immediate | — | JWT signing-key kind. | | clearplane.proxy.authentication.jwt.signing-keys.<index>.material | String | Symmetric secret of 32-8192 characters or valid RSA/EC public-key PEM up to 8192 characters | — | — | clearplane.proxy.authentication.jwt.signing-keys.<index>.material | Container label | Service resource | Secret | Immediate | — | Required JWT signing-key material valid for the indexed kind. Symmetric values are encrypted before persistence. | | clearplane.proxy.request-headers.entries.<index>.action | HeaderTransformAction | Set, Append, Remove | — | — | clearplane.proxy.request-headers.entries.<index>.action | Container label | Service resource | Public | Immediate | — | Transformation action for the indexed request header entry. | | clearplane.proxy.request-headers.entries.<index>.header-name | String | Valid non-reserved HTTP header name up to 200 characters | — | — | clearplane.proxy.request-headers.entries.<index>.header-name | Container label | Service resource | Public | Immediate | — | Required request header transformed by the indexed entry. | | clearplane.proxy.request-headers.entries.<index>.value | String | Header value without CR or LF, up to 4000 characters | — | — | clearplane.proxy.request-headers.entries.<index>.value | Container label | Service resource | Public | Immediate | — | Value required by Set or Append and forbidden by Remove. | | clearplane.proxy.response-headers.entries.<index>.action | HeaderTransformAction | Set, Append, Remove | — | — | clearplane.proxy.response-headers.entries.<index>.action | Container label | Service resource | Public | Immediate | — | Transformation action for the indexed response header entry. | | clearplane.proxy.response-headers.entries.<index>.condition | ResponseHeaderCondition | Always, Success, Failure | Always | — | clearplane.proxy.response-headers.entries.<index>.condition | Container label | Service resource | Public | Immediate | — | Response condition for the indexed entry. | | clearplane.proxy.response-headers.entries.<index>.header-name | String | Valid non-reserved HTTP header name up to 200 characters | — | — | clearplane.proxy.response-headers.entries.<index>.header-name | Container label | Service resource | Public | Immediate | — | Required response header transformed by the indexed entry. | | clearplane.proxy.response-headers.entries.<index>.value | String | Header value without CR or LF, up to 4000 characters | — | — | clearplane.proxy.response-headers.entries.<index>.value | Container label | Service resource | Public | Immediate | — | Value required by Set or Append and forbidden by Remove. | ## Redirect directives | Directive | Type | Accepted values | Built-in default | Environment variable | Docker label | Sources | Lifecycle | Sensitivity | Apply | UI location | Description | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | clearplane.redirect.additional-source-hosts | Whitespace list of string values | Unique whitespace-delimited exact DNS hosts, each up to 253 characters | (empty) | — | clearplane.redirect.additional-source-hosts | Container label | Service resource | Public | Immediate | — | Additional public hosts matched by the generated redirect route. Values are normalized to lowercase and must not repeat the primary source host. | | clearplane.redirect.certificate.additional-domains | Whitespace list of string values | Unique whitespace-delimited exact DNS hosts (max 253 characters) or single-label wildcards whose base is max 253 characters | (empty) | — | clearplane.redirect.certificate.additional-domains | Container label | Service resource | Public | Immediate | — | Extra certificate domains beyond the redirect's source hosts. The final certificate may have at most 99 subject alternative names. Wildcards require a DNS profile or inline credentials. | | clearplane.redirect.certificate.dns.api-token | String | Non-empty single-line value, up to 4096 characters | — | — | clearplane.redirect.certificate.dns.api-token | Container label | Service resource | Secret | Immediate | — | Required whenever any inline DNS field is present. Core encrypts the token before persistence. Inline DNS fields cannot be combined with dns.profile. | | clearplane.redirect.certificate.dns.profile | String | Trimmed non-empty profile name, up to 200 characters | — | — | clearplane.redirect.certificate.dns.profile | Container label | Service resource | Public | Immediate | — | Named DNS profile used for DNS-01 validation. Cannot be combined with the dns.provider, dns.api-token, or dns.propagation-seconds fields. Without either form of DNS configuration, HTTP-01 is used. | | clearplane.redirect.certificate.dns.propagation-seconds | Integer (optional) | 1-3600, or empty for the provider default | — | — | clearplane.redirect.certificate.dns.propagation-seconds | Container label | Service resource | Public | Immediate | — | Optional propagation delay in seconds for this route's inline DNS credentials. Requires dns.api-token. | | clearplane.redirect.certificate.dns.provider | AcmeDnsProvider | Cloudflare | Cloudflare | — | clearplane.redirect.certificate.dns.provider | Container label | Service resource | Public | Immediate | — | Provider for this route's inline DNS credentials. Requires dns.api-token and cannot be combined with the dns.profile field. | | clearplane.redirect.certificate.domain | String | Exact DNS host, up to 253 characters | — | — | clearplane.redirect.certificate.domain | Container label | Service resource | Public | Immediate | — | Primary certificate domain. Defaults to the redirect source host and must not be covered by a requested wildcard. | | clearplane.redirect.certificate.enabled | Boolean | — | false | — | clearplane.redirect.certificate.enabled | Container label | Service resource | Public | Immediate | — | Request and renew an ACME certificate for this redirect. | | clearplane.redirect.certificate.wildcard | Boolean | — | false | — | clearplane.redirect.certificate.wildcard | Container label | Service resource | Public | Immediate | — | Include a one-label wildcard for the primary certificate domain. Enabling it requires a named DNS profile or inline DNS credentials. | | clearplane.redirect.enabled | Boolean | — | false | — | clearplane.redirect.enabled | Container label | Service resource | Public | Immediate | — | Publish a standalone external redirect from this container. | | clearplane.redirect.group.collapsed-by-default | Boolean | — | false | — | clearplane.redirect.group.collapsed-by-default | Container label | Service resource | Public | Immediate | — | Collapse this resource group by default in redirect overviews. Ignored when group.name is absent. | | clearplane.redirect.group.name | String | Trimmed non-blank name, up to 200 characters | — | — | clearplane.redirect.group.name | Container label | Service resource | Public | Immediate | — | Optional resource group assigned to the generated redirect route. The order and collapsed fields are ignored with a warning when this name label is absent. | | clearplane.redirect.group.order | Integer | — | 0 | — | clearplane.redirect.group.order | Container label | Service resource | Public | Immediate | — | Resource group display order. Any signed integer is accepted and lower values appear first. Ignored when group.name is absent. | | clearplane.redirect.methods | Whitespace list of string values | Unique whitespace-delimited HTTP method tokens | (empty) | — | clearplane.redirect.methods | Container label | Service resource | Public | Immediate | — | Optional HTTP methods matched by the generated redirect route. Values are normalized to uppercase; duplicates after normalization are rejected. Empty matches every method. | | clearplane.redirect.name | String | Non-blank name, up to 200 characters; up to 191 with inline DNS credentials | — | — | clearplane.redirect.name | Container label | Service resource | Public | Immediate | — | Optional name for the generated redirect route. Defaults to the container discovery key. Inline DNS credentials append '-acme-dns' to create a credential-profile name, reducing the maximum base name to 191 characters. | | clearplane.redirect.order | Integer | Signed integer from -2147483638 to 2147483647 | 0 | — | clearplane.redirect.order | Container label | Service resource | Public | Immediate | — | Route match order. Lower values are evaluated first; the ten lowest signed integers are reserved for Clearplane management and guard routes. | | clearplane.redirect.path | String | Non-empty complete route path pattern, up to 2000 characters | /{**catch-all} | — | clearplane.redirect.path | Container label | Service resource | Public | Immediate | — | Complete public path pattern matched by the generated redirect route, using the same route-template syntax as the UI and REST API. Use '/api/{**catch-all}' to match /api and every path below it; use '/api' to match only that literal path. | | clearplane.redirect.preserve-path-and-query | Boolean | — | false | — | clearplane.redirect.preserve-path-and-query | Container label | Service resource | Public | Immediate | — | Append the matched request path and query string to the target URI. | | clearplane.redirect.source-host | String | Exact DNS host, up to 253 characters | — | — | clearplane.redirect.source-host | Container label | Service resource | Public | Immediate | — | Required primary public host matched by the generated redirect route. Schemes, ports, paths, wildcards and IP literals are rejected. | | clearplane.redirect.status-code | RedirectStatusCode | 301, 302, 307, or 308 | 308 | — | clearplane.redirect.status-code | Container label | Service resource | Public | Immediate | — | HTTP status code returned by the redirect. | | clearplane.redirect.target-uri | String | Absolute HTTP/HTTPS URI, up to 2000 characters | — | — | clearplane.redirect.target-uri | Container label | Service resource | Public | Immediate | — | Required redirect target. User information, fragments, control characters, backslashes, and a target that loops to a source host are rejected; preserving the path also restricts the target path and query shape. | ## Compose-only and framework settings These values are outside Clearplane's typed application catalog because Docker Compose or ASP.NET Core consumes them before Clearplane configuration binding. Set Compose inputs in the invoking shell, a sibling `.env` file, or a file passed with `--env-file`. | Key | Consumer | Default | Purpose | | --- | --- | --- | --- | | `COMPOSE_PROJECT_NAME` | Docker Compose | `clearplane` | Compose project name. The shipped Compose file passes the effective value to Core so first-party container ownership can be verified. | | `CLEARPLANE_IMAGE_TAG` | Docker Compose | the release version | Image tag for all four services. This does not provide database rollback. | | `CLEARPLANE_CONTAINER_PROXY_SOCKET_PATH` | Docker Compose | `/var/run/docker.sock` | Container-runtime socket bind source, mount target and Container proxy socket setting. | | `CLEARPLANE_MANAGEMENT_ALLOW_ADDRESSES` | Docker Compose | empty | Whitespace-delimited IP addresses and CIDR ranges allowed to reach the management UI and API routes. Empty blocks every address. | | `ASPNETCORE_ENVIRONMENT` | ASP.NET Core host | `Production` | Selects the hosting environment. Clearplane permits development-only credentials and relaxed local behavior only in `Development`. | ## Clearplane UI and API proxy routes Core and UI are ordinary discovered services. The shipped Compose file gives both containers one YAML anchor, `x-clearplane-management-labels`, with ordinary route policy labels: access control that blocks every address except `CLEARPLANE_MANAGEMENT_ALLOW_ADDRESSES`, a 600-request rate limit, automatic bans, request and response headers with the management Content-Security-Policy, the WAF in Detection with the Management profile, branded 403/502/503/504 error pages, and caching off. Each route owns its inline policies, placed in the `System` resource group. The routes ship disabled. A deployment override enables them and supplies the public host: ```yaml services: clearplane-core: labels: clearplane.proxy.enabled: "true" clearplane.proxy.host: "waf.example.com" clearplane-ui: labels: clearplane.proxy.enabled: "true" clearplane.proxy.host: "waf.example.com" ``` Change any management policy by overriding its label on both containers; these are secure defaults, not immutable behavior. ## Examples ### Core configuration Runtime Core settings use validated labels on the Core container or the UI. The MaxMind license key is the only runtime setting that also accepts an environment variable and `_FILE` twin: ```dotenv CLEARPLANE_CORE_GEO_IP_LICENSE_KEY=replace-with-your-key ``` The non-secret MaxMind settings can be labels on the Core container: ```yaml services: clearplane-core: labels: clearplane.core.geo-ip.enabled: "true" clearplane.core.geo-ip.provider: "MaxMind" ``` ### Edge configuration Edge bootstrap settings are environment-only. Runtime Edge settings use validated labels on the Edge container or the UI: ```dotenv CLEARPLANE_EDGE_BOOTSTRAP_CORE_URI=https://clearplane-core:8443 ``` ```yaml services: clearplane-edge: labels: clearplane.edge.connections.maximum-per-ip: "100" ``` HTTP/1.1, HTTP/2, and HTTP/3 default to enabled on public HTTPS, with HTTP/3 available when QUIC is supported. Select any nonempty combination through System / Settings / Edge, or set it with labels on the Edge container, which lock the UI fields. This example disables HTTP/1.1 on HTTPS while allowing HTTP/2 and HTTP/3. The plain HTTP listener retains HTTP/1.1 for redirects, ACME, and health checks. Changes require an Edge restart; HTTP/3 also requires UDP port 443. HTTP/3 alone requires a QUIC-capable runtime and clients that can discover or directly request it, because the usual HTTP/1.1 or HTTP/2 discovery response is unavailable. ```yaml services: clearplane-edge: labels: clearplane.edge.http1.enabled: "false" clearplane.edge.http2.enabled: "true" clearplane.edge.http3.enabled: "true" ``` Upstream destination restrictions are opt-in. This label blocks selected address classes globally while preserving Docker's ordinary private-network upstreams: ```yaml services: clearplane-edge: labels: clearplane.edge.upstream.restricted-destination-classes: "Loopback LinkLocal CloudMetadata ControlPlaneNetwork" ``` A proxy policy family takes effect on a route only with its root label set to `On`. Set `policy` to the SystemName of an existing policy (lowercase ASCII letters, digits, and single internal dashes); the multi-policy families accept a space-separated list. Without `policy`, the family creates an inline policy. Set the root label to `Off` to opt the route out of a Global policy while retaining the family's other labels. Generated names use `clearplane.proxy.name` (or the discovery key) plus the family suffix: ```yaml services: app: labels: clearplane.proxy.response-headers: "On" clearplane.proxy.response-headers.policy: "shared-security-headers" clearplane.proxy.cors: "Off" api: labels: clearplane.proxy.name: "api" clearplane.proxy.response-headers: "On" clearplane.proxy.response-headers.content-security-policy: "default-src 'self'" ``` ### UI configuration UI settings are bootstrap settings and are supplied to the UI container as environment variables: ```dotenv CLEARPLANE_UI_BOOTSTRAP_LOGS_PATH=/app/logs ``` ### ContainerProxy configuration ContainerProxy settings are bootstrap settings and are supplied to the ContainerProxy container as environment variables: ```dotenv CLEARPLANE_CONTAINER_PROXY_BOOTSTRAP_SOCKET_PATH=/var/run/docker.sock ``` ### Standalone external redirect A container can declare a redirect without publishing an upstream port or joining the proxy network. Set `clearplane.redirect.certificate.enabled` to request a certificate whose domain defaults to the source host. Additional source hosts become certificate identifiers. A container must not enable both `clearplane.proxy.enabled` and `clearplane.redirect.enabled`. ```yaml services: drive-redirect: image: alpine:latest command: ["sleep", "infinity"] labels: clearplane.redirect.enabled: "true" clearplane.redirect.name: "sharepoint-drive" clearplane.redirect.source-host: "drive.example.com" clearplane.redirect.certificate.enabled: "true" clearplane.redirect.target-uri: "https://target.example.com" clearplane.redirect.status-code: "308" ``` ### Inline access control With `clearplane.proxy.access-control: "On"` and no `policy`, the access-control labels create an inline policy. Country codes are normalized to uppercase. `default-action: Block` blocks everything the allow-lists do not name, so this example permits only the listed address and countries: ```yaml services: app: image: example/app labels: clearplane.proxy.enabled: "true" clearplane.proxy.name: "sample-app" clearplane.proxy.host: "app.example.com" clearplane.proxy.port: "8080" clearplane.proxy.access-control: "On" clearplane.proxy.access-control.default-action: "Block" clearplane.proxy.access-control.allow-addresses: "203.0.113.10" clearplane.proxy.access-control.allow-countries: "NL CW" ``` Whitespace lists may also use YAML's folded form. Line breaks become spaces, so this is equivalent to one quoted whitespace-delimited value: ```yaml services: app: labels: clearplane.proxy.access-control: "On" clearplane.proxy.access-control.allow-countries: >- NL CW clearplane.proxy.cache: "On" clearplane.proxy.cache.key.headers: >- Accept-Language X-Tenant ``` Inline policy labels are reconciled transactionally with the discovered route. The container owns its inline policies: their labelled settings are read-only in the API and UI, and discovery recreates a deleted inline policy on its next pass. Invalid labels leave the last accepted configuration in place. Set the family's `policy` label instead of inline fields to reference an existing policy. ### Inline Basic authentication Basic authentication uses complete indexed credential entries. Password label values are hashed before persistence and never rendered by APIs, diagnostics, logs, or this reference: ```yaml services: app: labels: clearplane.proxy.authentication: "On" clearplane.proxy.authentication.type: "Basic" clearplane.proxy.authentication.key-location: "Edge" clearplane.proxy.authentication.basic.realm: "Restricted" clearplane.proxy.authentication.basic.credentials.1.username: "alice" clearplane.proxy.authentication.basic.credentials.1.password: "replace-with-a-password" ``` ### Inline JWT bearer authentication JWT signing-key material is always treated as secret metadata. Symmetric material is encrypted before persistence; RSA and EC public keys use PEM block values: ```yaml services: api: labels: clearplane.proxy.authentication: "On" clearplane.proxy.authentication.type: "JwtBearer" clearplane.proxy.authentication.jwt.issuer: "https://identity.example.com" clearplane.proxy.authentication.jwt.audiences: "clearplane-api account-api" clearplane.proxy.authentication.jwt.signing-keys.1.kind: "Symmetric" clearplane.proxy.authentication.jwt.signing-keys.1.material: "a-secret-signing-key-at-least-32-characters" clearplane.proxy.authentication.jwt.required-claims.1.claim: "scope" clearplane.proxy.authentication.jwt.required-claims.1.value: "clearplane.read" ``` > [!WARNING] > Docker labels remain visible through container inspection and Compose source. If credentials cannot be stored in Docker metadata, create the authentication policy through the UI/API and reference it with `clearplane.proxy.authentication.policy`. The shipped bootstrap environment values live under each service's `environment:` block in `docker-compose.yml`. Deployment overrides belong in `docker-compose.override.yml`. Runtime settings use validated labels or the UI; only documented secret runtime settings have environment-variable twins. Container-resource labels are label-only. ================================================================================ DOCUMENT: Docker label reference Human URL: /docs/configuration/docker-labels/ ================================================================================ Clearplane discovers proxied services and standalone redirects from Docker labels. Clearplane-owned containers can also read validated runtime settings from labels. See the [environment variable reference](/docs/configuration/environment-variables/) for bootstrap settings and secrets. > Using an LLM or coding agent? Open the [plain-text Docker label reference](/llms/configuration/docker-labels.txt), the [LLM documentation index](/llms.txt), or the [complete documentation file](/llms/llms-full.txt). The [complete configuration catalog](/docs/configuration/catalog/) lists every label with its type, accepted values, default, and apply behavior. Four labels are required to publish a container over HTTPS. The example also includes the optional `clearplane.proxy.path` label to make its catch-all route explicit. ```yaml services: app: image: example/app:latest labels: clearplane.proxy.enabled: "true" clearplane.proxy.host: "app.example.com" clearplane.proxy.port: "8080" clearplane.proxy.path: "/{**catch-all}" clearplane.proxy.certificate.enabled: "true" ``` The example publishes the container on `app.example.com`, forwards requests to port `8080`, and requests an ACME certificate. ## How labels apply {#how-labels-are-resolved} The shipped Compose file passes its effective project name to Core. When that setting is omitted, Core resolves the project from the running Core container. Clearplane accepts labels on its own containers only when they belong to the verified project. Label names mirror the API concepts in kebab-case under their documented hierarchy, and label values keep the same meaning as the corresponding API/UI field. The transport syntax differs only where labels cannot represent the JSON shape directly: lists are whitespace-delimited, nested policy fields use dotted groups such as `cache.key`, and repeated object entries use indexed labels. The [catalog](/docs/configuration/catalog/) is the canonical name map. Every label value follows these rules: - **Enumerations** are written like the REST API and the UI: `On`, `Prevention`, `MemoryOnly`. Matching ignores case; numeric backing values are not accepted. Fields documented with literal numeric choices, such as redirect status codes, accept those listed numbers instead. - **Booleans** are `true` or `false`, ignoring case. Anything else, such as `yes` or `1`, is invalid. - **Lists** are whitespace-delimited. When the catalog marks a list as unique, duplicate tokens are invalid; labels do not silently collapse them. - **An invalid runtime-setting value** on a Clearplane-owned container is reported as a warning. The setting retains its previous valid label value; when none exists, the invalid label supplies no value and normal source resolution applies. - **An invalid service-resource value** rejects the discovered container and keeps its previous route. An unrecognized owner label on a Clearplane container (`clearplane.core.*`, `clearplane.edge.*`, `clearplane.ui.*`, or `clearplane.container-proxy.*`) is ignored and reported as a warning. It does not replace or preserve the known runtime label it may have been intended to spell: removing a known label removes its override, so the setting resumes the next source in the documented resolution order. An unrecognized `clearplane.*` service-resource key on a discovered application or redirect container rejects that container and keeps its previous route. Unrecognized keys under `clearplane.proxy.cache.*`, `compression.*`, `error-page.*`, `group.*`, `redirect.*`, and `clearplane.redirect.group.*` cannot weaken protection. Clearplane ignores them, builds the route from the remaining labels, and reports each ignored key as a warning in the container's status dialog and in Logs. Cache-key labels (`clearplane.proxy.cache.key.*`) are the exception: a lost `key.headers` entry could share responses between users, so an unknown cache-key label rejects the container. The [catalog](/docs/configuration/catalog/#resolution-and-ownership) gives the resolution order. [Configuration ownership](/docs/concepts/configuration-ownership/#docker-label-ownership) describes what label changes and removal do to discovered resources, and [Policies and scope](/docs/concepts/policies-and-scope/#route-policy-state) describes how a route's policy state selects its policies. ## Proxy route labels {#proxy-route-labels} Apply these labels to an application container that Clearplane should publish. ### Match paths {#proxy-route-paths} `clearplane.proxy.path` is the same `path` field stored in the database and shown by the route UI and REST API. Clearplane preserves the complete route pattern; it does not append or remove segments. The default is `/{**catch-all}`. | Value | Matches | |---|---| | `/api` | Only the literal `/api` path | | `/api/{**catch-all}` | `/api`, `/api/orders`, and everything below `/api` | | `/{**catch-all}` | Every path on the route's host | For example: ```yaml labels: clearplane.proxy.path: "/api/{**catch-all}" ``` The equivalent REST request uses `"path": "/api/{**catch-all}"`, the UI field displays `/api/{**catch-all}`, and the `ProxyRoutes.Path` database field stores `/api/{**catch-all}`. ### Policy labels {#policy-labels} Every policy family has one root label that sets the route's state for that family: ```yaml clearplane.proxy.: Inherit | On | Off # default: Inherit ``` | Root label | Policies applied to the route | Other `clearplane.proxy..*` labels | |---|---|---| | missing | Same as `Inherit` | Present: the container is rejected. Add `clearplane.proxy.: On`. | | `Inherit` | The family's enabled Global policy or policies, if any | Kept and ignored | | `On` | The route's own policies, from `.policy` or from inline settings. They replace the Global ones. | Used | | `Off` | None, even when a Global policy exists | Kept and ignored | The families are `access-control`, `authentication`, `auto-ban`, `cache`, `compression`, `cors`, `rate-limit`, `request-headers`, `response-headers` and `waf`. - `.policy` references existing route-scoped policies by system name. Cache, CORS, compression, request headers, response headers and WAF accept one name. Access control, authentication, automatic bans and rate limit accept a space-separated list. - Inline settings create a policy for this route alone. A setting you leave out takes its documented default; values are never copied from the Global policy. - `On` without `policy` or inline settings creates an inline policy with every setting at its default. Authentication is the exception: it has no meaningful defaults, so an inline authentication policy needs `type` and its credentials or signing keys. - `clearplane.proxy.authentication.combine-mode` (`Or` or `And`) is a route setting, not part of a policy, so it can be combined with `authentication.policy`. - Combining `policy` with inline settings rejects the container, and so does naming a policy twice. - A referenced policy that is disabled stops applying to the route, and discovery reports a warning. The route never falls back to the Global policy. Reference existing policies: ```yaml labels: clearplane.proxy.access-control: "On" clearplane.proxy.access-control.policy: "office-only" clearplane.proxy.authentication: "On" clearplane.proxy.authentication.policy: "partner-api-keys" clearplane.proxy.auto-ban: "On" clearplane.proxy.auto-ban.policy: "scanner-bans" clearplane.proxy.cache: "On" clearplane.proxy.cache.policy: "static-assets" clearplane.proxy.compression: "On" clearplane.proxy.compression.policy: "web-responses" clearplane.proxy.cors: "On" clearplane.proxy.cors.policy: "app-origins" clearplane.proxy.rate-limit: "On" clearplane.proxy.rate-limit.policy: "login-throttle api-burst" clearplane.proxy.request-headers: "On" clearplane.proxy.request-headers.policy: "tenant-headers" clearplane.proxy.response-headers: "On" clearplane.proxy.response-headers.policy: "security-headers" clearplane.proxy.waf: "On" clearplane.proxy.waf.policy: "strict-api" ``` Define a policy inline, or turn a family off for one route: ```yaml labels: clearplane.proxy.cors: "On" clearplane.proxy.cors.allowed-origins: "https://app.example.com" clearplane.proxy.rate-limit: "On" clearplane.proxy.rate-limit.request-limit: "300" clearplane.proxy.rate-limit.window-seconds: "60" clearplane.proxy.waf: "Off" ``` ### Preserve the original hostname {#preserve-host-header} For applications that strictly validate their public hostname, add this label to the application container: ```yaml labels: clearplane.proxy.preserve-host-header: "true" ``` Additional hosts and wildcard routes preserve the actual requested hostname. For example, a request for `api.example.com:8443` reaches the container with `Host: api.example.com:8443`. The label does not change the destination address or disable upstream certificate validation. For routes managed through the UI, enable **Preserve host header** in the route form. ### Upstream activity timeout {#activity-timeout} To allow up to five minutes of inactivity for one application, add this label to its container: ```yaml labels: clearplane.proxy.upstream.activity-timeout-seconds: "300" ``` The value is a whole number from `1` through `86400`, matching the UI/API `activityTimeoutSeconds` field. Omitting it uses the documented 60-second default. ### Web application firewall — `clearplane.proxy.waf.*` {#proxy-waf} > **Experimental:** These settings expose the experimental web application firewall. Use [service automatic bans](/docs/guides/protect-service/) for behavior-based protection. WAF settings live in [WAF policies](/docs/security/waf-rulesets/#waf-policies). A container without `clearplane.proxy.waf` inherits the enabled Global policy, which is **Default WAF** in Detection on a new installation, and `clearplane.proxy.waf: "Off"` opts the route out. With `clearplane.proxy.waf: "On"`, `clearplane.proxy.waf.policy` assigns an existing Route policy by system name. Otherwise the WAF labels create an inline policy named `-waf` that the container owns. `waf.mode` defaults to `Detection`, which records findings; `Prevention` blocks. ```yaml labels: clearplane.proxy.waf: "On" clearplane.proxy.waf.mode: "Prevention" clearplane.proxy.waf.opt-out-rulesets: "clearplane-scanners" clearplane.proxy.waf.request-body.maximum-bytes: "4194304" clearplane.proxy.waf.request-context.header-capture-mode: "RedactSensitive" ``` The inline policy's labels mirror the policy form, grouped by section: | Section | Labels | |---|---| | Scoring | `mode`, `profile`, `scoring-mode`, `threshold`, `paranoia-level`, `detection-paranoia-level` | | Rulesets | `opt-out-rulesets`, `exclusion-rulesets`, `allowed-methods`, `allowed-request-content-types` | | `request-body.*` | `inspection-mode`, `maximum-bytes`, `oversize-action`, `maximum-spooled-bytes` | | `websocket.*`, `grpc.*` | `websocket.enabled`, `websocket.maximum-message-bytes`, `grpc.maximum-message-bytes`, `grpc.maximum-messages` | | `response.*` | `inspection`, `threshold`, `maximum-body-bytes` | | `challenge.*` | `mode`, `threshold`, `difficulty`, `clearance-minutes` | | `request-context.*` | `enabled` and `header-capture-mode`, which choose what the route's [detections record](/docs/security/waf-detections/#request-context-and-redaction) | The [catalog](/docs/configuration/catalog/#proxy-directives) lists each label's accepted values and default. Disabled rules, target exclusions and per-ruleset thresholds have no labels, because labels cannot address an individual rule. Set them on the inline policy under **Firewall → WAF policies**; saving there changes only those three, and discovery keeps them when it updates the policy. Every labelled setting stays owned by the container. Opting a whole ruleset out stays a label (`clearplane.proxy.waf.opt-out-rulesets`). ### Caching — `clearplane.proxy.cache.*` {#proxy-caching} Caching is a reusable policy. Create Global or Route policies in **Performance → Cache policies**. One enabled Global policy caches every proxied route that inherits caching; a route's own policy replaces it. A discovered proxy route can select an existing Route policy by system name: ```yaml labels: clearplane.proxy.cache: "On" clearplane.proxy.cache.policy: "static-assets" ``` Omit `policy` to create an inline policy named `-cache` from the route's other `clearplane.proxy.cache.*` labels. A label you leave out takes its [catalog](/docs/configuration/catalog/#proxy-directives) default, and an invalid value rejects the container. A policy with no other settings caches like a CDN. With `eligibility: StaticFiles`, only paths ending in one of the `file-extensions` use the cache; the catalog lists the default set, which includes `wasm` but not `html` or `json`. Every other request reaches the upstream and is reported as `DYNAMIC`. Set `eligibility: Everything` to cache HTML, API and extensionless paths as well. Under `StaticFiles`, a response is not stored when its `Content-Type` is HTML, JSON, XML or plain text and the extension does not name that format, so an application that answers `/account/profile.css` with the profile page cannot have that page cached (`BYPASS / ContentTypeMismatch`). `path-rules` gives parts of an application their own caching. It is an ordered, whitespace-separated list of `pattern=action` rules, and the first rule whose pattern matches the request path applies. A pattern starts with `/`, and `*` matches any run of characters, including `/`: `/api/*` matches `/api/` and `/api/v1/orders` but not `/api`, and `/` matches only the root. `cache` caches the path whatever the eligibility and extensions say, and skips the extension/content-type check. `bypass` never caches it (`DYNAMIC`). A `cache` rule can add `ttl=` to replace the default lifetime and `ignore-upstream-cache-control` to discard the upstream's lifetime and `no-cache`. Any rule can add `browser-ttl=` to send `Cache-Control: max-age=` to the client. Per-status lifetimes, bypass cookies, `Authorization` handling and the `private`, `no-store` and `Set-Cookie` stops still apply. ```yaml labels: clearplane.proxy.cache: "On" clearplane.proxy.cache.path-rules: "/_framework/*=cache,ttl=31536000,ignore-upstream-cache-control /api/*=bypass /=cache" ``` Every route that uses a policy shares its storage pool. `maximum-total-size-megabytes` sizes that pool for all of those routes together, and eviction removes the least recently used entries across the pool. Entries stay separate per route, so one route never serves another route's response. The global per-tier cache limit counts each enabled policy once, however many routes use it. If an inline policy would exceed that limit, Clearplane saves it disabled, keeps the route's cache state On, and reports a warning in the container's status dialog. The route is not cached until capacity is available on a later discovery pass. A response that declares its own lifetime through `Cache-Control`, `CDN-Cache-Control`, `Clearplane-CDN-Cache-Control` or `Expires` is clamped into the range between the minimum and maximum lifetimes. A response that declares none is held for the default lifetime, or for a matching `status-codes-time-to-live` entry. Precedence follows HTTP: `s-maxage` wins over `max-age`, which wins over `Expires`. Following RFC 9213, an upstream can address Clearplane alone with `Clearplane-CDN-Cache-Control`. When it is present and valid, its directives replace `Cache-Control` for Clearplane's lifetime, `no-cache`, revalidation, stale windows and `Authorization` consent. `CDN-Cache-Control` does the same with lower precedence while `honor-cdn-cache-control` is on. `Clearplane-CDN-Cache-Control` never reaches the client; `CDN-Cache-Control` is passed through. `private` or `no-store` in `Cache-Control` still stops storage. The browser-only pattern is `Cache-Control: no-cache` with `Clearplane-CDN-Cache-Control: max-age=3600`: Clearplane caches for an hour and answers the browser's revalidations from cache. An upstream `stale-while-revalidate` or `stale-if-error` directive replaces the policy's window for that response. `must-revalidate`, `proxy-revalidate` and `s-maxage` forbid serving a stale copy unless the response also carries one of those stale directives. `ignore-upstream-cache-control` keeps the policy's windows. `ignore-upstream-cache-control` discards a declared lifetime; `require-upstream-cache-control` caches only responses that declare one. The two cannot both be set. Neither overrides `no-store`, `private` or `Set-Cookie`, which are never stored. Request cookies neither skip the cache nor enter the cache key, and they still reach the upstream. List cookie names in `bypass-cookies` to send requests carrying them straight to the upstream; a trailing `*` matches a name prefix and `*` alone matches any cookie. A request with `Authorization` uses and stores only responses the upstream marked `public`, `s-maxage` or `must-revalidate`. A stored response is served to every request that passes the route's access checks, so an upstream that protects static files with its own login cookie must send `Cache-Control: private` or have that cookie listed in `bypass-cookies`. A visitor's `Cache-Control: no-cache` or `no-store` does not skip the cache unless `ignore-request-no-cache` or `ignore-request-no-store` is turned off. Clearplane answers `If-None-Match` and `If-Modified-Since` from the cache with `304 Not Modified` and never forwards them when it fills the cache. It revalidates a stale entry, or one stored with `no-cache`, by sending the entry's `ETag` and `Last-Modified` to the upstream; a `304` renews the entry without downloading the body and is reported as `REVALIDATED`. Requests with `If-Match` or `If-Unmodified-Since` bypass the cache, and so do requests carrying `X-Original-URL`, `X-Rewrite-URL`, `X-HTTP-Method-Override`, `X-HTTP-Method`, `X-Method-Override` or `X-Host`, which some frameworks use to serve a different resource than the URL names. Byte ranges are answered from cache. A GET with a single `bytes` range receives `206 Partial Content` from a stored `200` response, or `416` when the range lies beyond it; a request for several ranges receives the full response. `If-Range` must match the stored `ETag` by strong comparison, or equal the stored `Last-Modified`. When nothing is stored yet, the range request goes to the upstream unchanged (`BYPASS / Range`), so a video player never waits for the whole file. If the upstream answers `206` with a complete length within `maximum-response-size-megabytes`, Clearplane fetches the full object in the background, and later ranges are hits. Clearplane records the tags the upstream lists in `Cache-Tag` (comma-separated) and `Surrogate-Key` (space-separated), ignoring case, and removes both headers from client responses. A deploy can then purge every entry carrying a tag, from the cache page, `POST /api/cache/purge` or [`clearplane cache purge tag`](/docs/cli/#purge-the-cache). A response with a tag longer than 1,024 characters or more than 16 KB of tags is not stored (`BYPASS / CacheTagLimit`), because a partial tag list would let a purge miss it. With `purge-on-redeploy` (on by default), Clearplane purges a discovered route's cached responses when discovery sees its container recreated, for example after `docker compose up` with a new image. A restart of the same container does not purge. With `vary-handling: Honor`, Clearplane stores a separate copy for each combination of the request headers the upstream lists in `Vary`, up to 32 per URL; further combinations reach the upstream without being stored. `Ignore` stores one copy regardless of `Vary`. `Vary: *`, `Cookie` or `Authorization` is never stored in either mode. `Accept-Encoding` and the headers in `key.headers` are already part of the cache key. For an image that varies on `Accept`, Clearplane stores one copy per image-format bucket instead of per `Accept` value: the set of AVIF, WebP and JPEG XL the browser accepts, so at most eight copies. The upstream still receives the browser's own `Accept`. Add `Accept` to `key.headers` to key on the raw value instead. A cacheable request reaches the upstream with `Accept-Encoding` reduced to `br`, `gzip`, or `identity`, and Clearplane caches the Brotli, gzip, and plain responses separately, so precompressed assets are fetched once per encoding. When the upstream answers a Brotli or gzip request with a plain body, that plain copy serves every client until it expires. Without a compression policy, requests that bypass the cache keep the client's `Accept-Encoding`. [Compression](#proxy-compression) adds Clearplane's own compression on top. ### Compression — `clearplane.proxy.compression.*` {#proxy-compression} Compression is a reusable policy, independent from response caching. Create Global or Route policies in **Performance → Compression policies**. One enabled Global policy can provide the default for every proxied route that inherits compression; a route's own policy replaces it. A discovered proxy route can select an existing Route policy by system name. A route without `clearplane.proxy.compression` inherits the Global policy: ```yaml labels: clearplane.proxy.compression: "On" clearplane.proxy.compression.policy: "web-responses" ``` In `content-types`, exclusions always win, regardless of order, and response parameters such as `charset=utf-8` are ignored while matching. With an effective policy, Clearplane reduces the client's `Accept-Encoding` to the one representation it selected — `br`, `gzip`, or `identity` — and forwards that value upstream. A Brotli or gzip response that matches the forwarded value is served as the upstream sent it, and on a cache-enabled route it is cached under that encoding, so precompressed assets are fetched once per encoding and never compressed again. A plain response is compressed by Clearplane; on a cache-enabled route Clearplane derives compressed copies from the cached plain copy only after the upstream has answered a Brotli or gzip request with it. A plain copy fetched for a client that accepts neither never stands in for the upstream's own compressed file. Clients that accept neither Brotli nor gzip never receive a cached compressed copy; Clearplane asks the upstream for a plain one. A response in any other encoding, including one Clearplane does not support, passes through unchanged and is never cached. `HEAD`, bodyless and partial responses, `Cache-Control: no-transform`, missing or excluded content types, and bodies below the minimum length remain uncompressed. If an effective policy exists and a non-empty body-bearing upstream response is known, Clearplane returns `406 Not Acceptable` when the client rejects Brotli, gzip, and identity. When no compression policy applies, Clearplane leaves compression to the upstream service; on a cache-enabled route, cacheable requests still use the reduced `Accept-Encoding` described under [Caching](#proxy-caching). ### Request headers — `clearplane.proxy.request-headers.*` {#proxy-request-headers} Each header transform is a complete indexed entry. `Set` and `Append` require `value`; `Remove` requires it to be omitted: ```yaml labels: clearplane.proxy.request-headers: "On" clearplane.proxy.request-headers.entries.1.header-name: "X-Tenant" clearplane.proxy.request-headers.entries.1.action: "Set" clearplane.proxy.request-headers.entries.1.value: "example" clearplane.proxy.request-headers.entries.3.header-name: "X-Legacy" clearplane.proxy.request-headers.entries.3.action: "Remove" ``` ## Standalone redirect labels {#standalone-redirect-labels} Apply these labels to a container that declares an external redirect. The container needs no published port and does not have to join the proxy network. Clearplane answers HTTP-01 challenges before applying the redirect. ```yaml services: old-domain: image: alpine:latest command: ["sleep", "infinity"] labels: clearplane.redirect.enabled: "true" clearplane.redirect.source-host: "old.example.com" clearplane.redirect.additional-source-hosts: "www.old.example.com" clearplane.redirect.path: "/{**catch-all}" clearplane.redirect.target-uri: "https://new.example.com" clearplane.redirect.preserve-path-and-query: "true" clearplane.redirect.certificate.enabled: "true" ``` `clearplane.redirect.path` has the same exact-pattern contract and `/{**catch-all}` default as `clearplane.proxy.path`. `methods` limits the redirect to the listed HTTP methods, and `status-code` chooses 301, 302, 307 or 308 (default 308). A container cannot enable both `clearplane.proxy.enabled` and `clearplane.redirect.enabled`. ## Gateway runtime labels {#gateway-runtime-labels} Clearplane's own containers accept runtime settings as labels. A label locks the matching field in **System → Settings** until you remove it. - **Core container:** `clearplane.core.*`, for example the Let's Encrypt account, retention periods and country geolocation. - **Edge container:** `clearplane.edge.*`, for example trusted proxies, connection and request limits, cache capacity and the HTTPS protocols (`clearplane.edge.http1.enabled`, `http2.enabled`, `http3.enabled`). ```yaml services: clearplane-edge: labels: clearplane.edge.trusted-proxies: "203.0.113.0/24" clearplane.edge.http1.enabled: "false" ``` The management UI and API routes are ordinary proxy routes on the Core and UI containers. The shipped Compose file gives both one YAML anchor with their policy labels; set `CLEARPLANE_MANAGEMENT_ALLOW_ADDRESSES` to the addresses that may reach them. See [Exposure and networks](/docs/security/exposure-and-networks/#management-route-defaults). ================================================================================ DOCUMENT: Environment variable reference Human URL: /docs/configuration/environment-variables/ ================================================================================ Clearplane uses environment variables for bootstrap settings and secrets only. Every other runtime setting uses a container label or the UI. Bootstrap settings are read once at startup; an invalid value stops the service with a message naming the variable. The [complete configuration catalog](/docs/configuration/catalog/) lists every supported variable with its accepted values, default, resolution order, and apply behavior. Service and redirect resources are label-only; Clearplane never reads environment variables from discovered application containers. `CLEARPLANE_EDGE_BOOTSTRAP_CORE_URI` must be an HTTPS origin such as `https://clearplane-core:8443`. Edge uses it for the mutually authenticated control-plane connection; HTTP, credentials, paths, queries, and fragments are rejected. > Using an LLM or coding agent? Open the [plain-text environment variable reference](/llms/configuration/environment-variables.txt), the [LLM documentation index](/llms.txt), or the [complete documentation file](/llms/llms-full.txt). ## DNS-profile secret files An individual numbered profile can read its token from a mounted file instead of a scalar environment value: ```yaml services: clearplane-core: environment: CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_1_NAME: cloudflare-production CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_1_API_TOKEN_FILE: /run/secrets/cloudflare-api-token secrets: - cloudflare-api-token secrets: cloudflare-api-token: file: ./secrets/cloudflare-api-token ``` To mount a JSON file: ```yaml services: clearplane-core: environment: CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILES_FILE: /run/secrets/acme-dns-profiles.json secrets: - acme-dns-profiles secrets: acme-dns-profiles: file: ./secrets/acme-dns-profiles.json ``` Example file content: ```json {"profiles":[{"name":"cloudflare-production","provider":"Cloudflare","apiToken":"replace-with-a-scoped-token","propagationSeconds":30}]} ``` Each JSON profile accepts `name`, `provider`, `apiToken` and the optional `propagationSeconds` (1–3600, omitted for the provider default); any other property is an error. Keep both example secret files outside source control. Numbered and JSON profiles can coexist when their names are unique. When a numbered profile is invalid, startup reports the exact expanded variable, for example `CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_2_API_TOKEN`, rather than the `` template. Secret values are never included in the error. ## Docker Compose inputs Set these values in the invoking shell, a sibling `.env` file, or a file passed with Compose `--env-file`. Service environment blocks do not participate in Compose interpolation. | Environment variable | What it does | | --- | --- | | COMPOSE_PROJECT_NAME | Overrides the Compose project name, which defaults to clearplane. The shipped Compose file passes the effective value to Core so first-party container ownership can be verified. | | CLEARPLANE_IMAGE_TAG | Overrides the image tag for all four services. This does not provide database rollback. | | CLEARPLANE_CONTAINER_PROXY_SOCKET_PATH | Selects the local Unix socket bind source, mount target, and Container proxy socket setting. | | CLEARPLANE_MANAGEMENT_ALLOW_ADDRESSES | Whitespace-delimited IP addresses and CIDR ranges allowed to reach the management UI and API routes. Empty blocks every address. | ================================================================================ DOCUMENT: Reference Human URL: /docs/configuration/ ================================================================================ The [complete configuration catalog](catalog/) is generated from the validated application metadata and lists every setting's accepted values, default, supported sources, lifecycle, sensitivity, apply behavior, and UI location, with configuration examples. The [Docker label reference](docker-labels/), [environment variable reference](environment-variables/), and [REST API guide](rest-api/) add worked examples and the rules the catalog does not cover. Language models and coding agents can start at [`/llms.txt`](/llms.txt). ================================================================================ DOCUMENT: REST API Human URL: /docs/configuration/rest-api/ ================================================================================ Clearplane exposes its public management API below `https:///api/`. The generated OpenAPI 3.1 contract is available to users with `Settings.Read` at: ```text GET https:///api/openapi ``` The contract is generated from the running controllers and shared JSON configuration. It is the source of truth for paths, methods, request and response shapes, nullability, and enum values. Schema descriptions state conditional requirements that cannot be expressed as a single required-property list; the API applies those rules with FluentValidation and returns `400` for violations. ## Authentication and permissions Sign in with a cookie jar, then reuse that jar for API requests: ```bash base='https://clearplane.example.com/api' curl --fail-with-body \ --cookie-jar clearplane.cookies \ --header 'Content-Type: application/json' \ --data '{"userName":"Administrator","password":"replace-me"}' \ "$base/authentication/sign-in" curl --fail-with-body \ --cookie clearplane.cookies \ "$base/openapi" ``` The sign-in response's `nextStep` is `SessionCreated` when authentication is complete. `MultiFactorChallengeRequired` means the client must complete the `authentication/multi-factor-authentication` operation described by the contract before using protected operations. For `POST`, `PUT`, `PATCH`, or `DELETE` with the session cookie, also send the browser-session CSRF header: ```text X-Clearplane-CSRF: Clearplane.Browser ``` Each operation enforces its own permission. A missing or invalid session returns `401`; an authenticated account without the required permission returns `403`. Every protected OpenAPI operation declares the `clearplaneSession` security scheme and its exact permission in `x-clearplane-permissions`; unsafe operations also declare `clearplaneCsrf`. The OpenAPI document itself requires `Settings.Read`. ## JSON and updates - Property names use camel case. - Route `path` values are complete route patterns on every surface. `/api` matches only that literal path, while `/api/{**catch-all}` matches `/api`, `/api/orders`, and everything below it. Docker labels use the same value under `clearplane.proxy.path` or `clearplane.redirect.path`; Clearplane does not rewrite it. - Optional `stripPrefix` and `pathRewrite` values treat an empty or whitespace-only string as unset, matching blank label and UI values. - Durations use integer fields whose names state the unit, such as `activityTimeoutSeconds`, `windowSeconds`, `banDurationSeconds`, `preflightMaxAgeSeconds`, and `defaultTimeToLiveSeconds`. The API does not expose the internal `TimeSpan` property names without a unit. - Enum values use the canonical member names listed by the contract, such as `MaxMind` or `Detection`. Input matching is case-insensitive, but numeric enum backing values are rejected. - Treat `PUT` request models as complete replacements. Read the current resource first and preserve fields that should not change. - Authentication-policy passwords and JWT signing-key material are write-only and are returned as empty strings. On update, leave an existing credential password or signing key blank to preserve its stored value. A blank value cannot create a new credential or key, change its identity or kind, or survive an authentication-type change; supply new material in those cases. - Validation and malformed JSON return `400`. Missing resources return `404`. Ownership, stale state, or another in-progress mutation can return `409`; read the response body for the specific conflict. - Setting responses distinguish saved and effective values and report their effective source where applicable. The [configuration catalog](/docs/configuration/catalog/) states whether a change is immediate, validated, staged until Edge apply, or restart-required. Automatic-apply settings are read with `GET /api/edge/automatic-apply` under `Settings.Read` and changed with `PUT /api/edge/automatic-apply` under `Settings.Write`. Operational Edge statistics remain under `Services.Read` and do not expose configuration settings. For example, a rate-limit request uses a numeric seconds field: ```json { "name": "login-burst", "windowSeconds": 60, "requestLimit": 20 } ``` Core converts `windowSeconds: 60` to its typed duration and persists that duration in the `Window` database field. Responses convert it back to `windowSeconds: 60`; clients never need to know the database representation. ## Configuration ownership The API updates the same saved value that the UI edits. Resolution remains **environment variable → validated Clearplane container label → saved UI value → built-in default**. A runtime label on a Clearplane-owned container overrides the matching saved field. The UI presents that field as read-only, and the API response reports the effective source. Removing the label reveals the saved UI value again. Resources discovered from application-container labels are container-managed. Change their labels instead of trying to mutate the generated route or inline policies through the API; conflicting mutations return `409`. UI/API-created resources remain editable through the API subject to permissions and normal reference checks. Use the [Docker label reference](/docs/configuration/docker-labels/) for label parsing and ownership rules, and the [environment variable reference](/docs/configuration/environment-variables/) for bootstrap and secret handling. ================================================================================ DOCUMENT: Installation Human URL: /docs/get-started/ ================================================================================ Clearplane runs from a release's `docker-compose.yml` and four published container images. Docker Compose owns installation, updates, and the container lifecycle. Application commands run through the [CLI embedded in Core](../cli/). > **Alpha release:** The supported target is one Linux Docker host. High availability, multi-host orchestration, rolling upgrades, and supported matched backup and restore are not included. ## Host requirements - Linux on `x86_64` or `arm64`, with Docker Engine and Docker Compose 2.24.0 or newer. - A local Unix Docker socket accessible under the host's permission and SELinux policy. - At least 8 GiB RAM for Clearplane and 10 GiB free on Docker's data filesystem. Reserve additional memory for other applications on the host. - Available TCP ports 80 and 443, UDP port 443 for HTTP/3, registry access, and DNS for the hostnames you will publish. Images include the runtime; the host needs no .NET installation or source build. Operators configure Docker, DNS, firewalls, and host permissions. Publish HTTPS on the same public TCP and UDP port and allow both through the host firewall when using HTTP/3. ## Download the release Download `docker-compose.yml` from the Clearplane release into a deployment directory. Run every Compose command below from that directory. During the private alpha, sign in to GitHub Container Registry with an authorized GitHub account and a personal access token with `read:packages`. Enter the token at the password prompt: ```bash docker login ghcr.io -u ``` An optional `.env` file can set `CLEARPLANE_IMAGE_TAG` to another published version or `CLEARPLANE_CONTAINER_PROXY_SOCKET_PATH` to a nondefault local socket path. `CLEARPLANE_MANAGEMENT_ALLOW_ADDRESSES` is described below. See the [environment variable reference](../configuration/environment-variables/). ## Configure browser access The shipped UI and API routes are disabled, and their access control blocks every address you have not allowed. Add your administrator address to the `.env` file beside `docker-compose.yml`: ```dotenv CLEARPLANE_MANAGEMENT_ALLOW_ADDRESSES=203.0.113.10/32 ``` Then create `docker-compose.override.yml`, replacing the hostname and email: ```yaml services: clearplane-core: labels: clearplane.core.acme.email-address: "admin@example.com" clearplane.core.acme.terms-of-service-agreed: "true" clearplane.proxy.enabled: "true" clearplane.proxy.host: "waf.example.com" clearplane.proxy.certificate.enabled: "true" clearplane.proxy.redirect.http-to-https: "true" clearplane-ui: labels: clearplane.proxy.enabled: "true" clearplane.proxy.host: "waf.example.com" clearplane.proxy.certificate.enabled: "true" clearplane.proxy.redirect.http-to-https: "true" ``` The UI and API must share a hostname because the browser calls same-origin `/api/` and `/api/ws/`. The management access control blocks by default; allow your administrator address or a narrow VPN CIDR, separating several with spaces. Avoid broad private-network ranges that could also admit application containers. For HTTP-01 certificates, point the public A/AAAA records at Edge and keep public TCP port 80 reachable for issuance and renewal. See [Enable HTTPS](../guides/enable-https/) for DNS-01 and other certificate options. All four services run regardless of route exposure. You can enable only the Core route for API access or leave both management routes disabled. Examples use the shipped service keys. If you rename services, use your keys in commands, overrides, and dependency references. Preserve the canonical `clearplane-core`, `clearplane-edge`, `clearplane-ui`, and `clearplane-container-proxy` aliases on `clearplane-internal`. ## Start and complete setup ```bash docker compose config --quiet && docker compose pull && docker compose up -d --wait ``` Once the management hostname has trusted HTTPS, issue a setup code: ```bash docker compose exec clearplane-core clearplane setup-code ``` Open `https://waf.example.com/setup` and create the first administrator. Never submit setup codes or passwords over public plaintext HTTP. After creating the first administrator, browser setup offers authenticator-app MFA. Enroll now or choose **Skip for now** to continue without MFA. You can enable it later in your account security settings. MFA is also optional for the first administrator created through the terminal. Users added later still default to requiring MFA, which an administrator can change per user. Setup offers **Cloud integration**, off by default. Enabling it connects this installation to Clearplane Cloud and reveals separate feature choices: - **Health reporting** sends host and service health. It is off by default. - **Error reporting** sends bounded diagnostic metadata. It is off by default. - **WAF ruleset updates** downloads signed WAF rulesets from Cloud and activates new releases in Detection. It is off by default. Without active compatible rulesets, the WAF has no rules to inspect. - **Cloud Protection** is coming later for Community, Business and Enterprise and remains unavailable. You can complete setup with Cloud off and change these choices later in **Settings → Cloud**. Local protection works without Cloud. Every route starts under the Global WAF policy **Default WAF** in Detection, which records findings without blocking; the shipped management routes keep their own Management-profile policies. Until a WAF ruleset is active, the dashboard warns that nothing is inspected. Clear the warning in one of three ways: turn on Cloud integration and WAF ruleset updates, publish a [custom ruleset](../guides/write-custom-waf-rules/), or set **Default WAF** and every other enabled WAF policy to **Off**. See [WAF policies](../security/waf-rulesets/#waf-policies). Read the [Cloud data and consent details](/docs/operations/change-apply-configuration/#cloud-integration-error-reporting-and-installation-id) before enabling reports. To complete setup through an attached terminal when the UI route is disabled: ```bash docker compose exec clearplane-core clearplane administrator create ``` Terminal-only setup leaves Cloud integration, health reporting, error reporting and WAF ruleset updates off. Operators with settings write permission can change them later in the UI or through the authenticated privacy configuration API. ## Operate and update | Task | Command | | --- | --- | | Container status | `docker compose ps` | | Recent Core logs | `docker compose logs --tail 200 clearplane-core` | | Follow Edge logs | `docker compose logs --follow clearplane-edge` | | Stop and keep containers | `docker compose stop` | | Start or apply changes | `docker compose up -d --wait` | | Restart existing containers | `docker compose restart` | | Remove containers and project networks, keeping named volumes | `docker compose down` | For an update, replace `docker-compose.yml` with the newer release's file, preserve your overrides, and review any `CLEARPLANE_IMAGE_TAG` override. Then run: ```bash docker compose pull && docker compose up -d --wait ``` An image-tag change does not provide database rollback; a version that cannot recognize the stored migration history refuses startup. Use `up -d --wait` to apply image or Compose changes; `restart` only restarts existing containers. **Alpha upgrades:** alpha releases migrate databases but never older secrets, settings, labels or other persisted state. When a release changes them, Core refuses the old state: remove it with `docker compose down --volumes`, start again with `docker compose up -d --wait` and complete setup. Upgrading from 1.0.0-alpha4 or earlier requires this. Edge retains its previous valid configuration while Core is unavailable. The [CLI reference](../cli/) covers installation status, setup, administrator recovery, ban removal, database maintenance, and secret rotation. [Operations](../operations/) covers application monitoring and troubleshooting. ## Data and removal The shipped volumes are: | Volume | Contents | | --- | --- | | `clearplane-core-data` | Application database, data-protection keys, administrator signing key, internal CA/private key, Core identity, and generation manifest. | | `clearplane-edge-data` | Stored certificates and password, GeoIP data, CA copy, and Edge identity; Edge mounts it read-only. | | `clearplane-ui-data` | UI CA copy and identity; UI mounts it read-only. | | `clearplane-container-proxy-data` | ContainerProxy CA copy and identity; ContainerProxy mounts it read-only. | | `clearplane-analytics` | Analytics database and ingestion checkpoints. | | `clearplane-logs` | Raw application/audit logs and Core's indexed log catalog. | | `clearplane-cache` | Disposable Edge response cache. | Core requires all six durable mounts. Preserve them together as one matched generation. Partial state after interrupted provisioning or migration requires diagnosis and recovery; startup never treats remaining artifacts as disposable. See [database maintenance](../cli/#database-maintenance) for the validation rules. The shipped networks and volumes have fixed names; changing the directory or Compose project name does not isolate a second installation on the same host. **`docker compose down --volumes` permanently removes all seven named volumes**, including databases, keys, certificates, analytics, logs, and cache. Use it only when complete deletion is intended. ================================================================================ DOCUMENT: Configure access, traffic, and delivery Human URL: /docs/guides/access-traffic-delivery/ ================================================================================ Choose the smallest control that matches the problem, apply it to one test route first, and verify the result before broadening its scope. ## Choose a control | Goal | UI area | Docker-label family | | --- | --- | --- | | Allow or block clients | **Access → Access control policies** | `clearplane.proxy.access-control` | | Require route credentials | **Access → Authentication policies** | `clearplane.proxy.authentication` | | Limit request rates | **Abuse → Rate limit policies** | `clearplane.proxy.rate-limit` | | Ban repeated abuse | **Abuse → Auto-ban policies** | `clearplane.proxy.auto-ban` | | Control cross-origin browser access | **Access → CORS policies** | `clearplane.proxy.cors` | | Change request or response headers | **Rules → Request headers policies** / **Response headers policies** | `clearplane.proxy.request-headers` / `clearplane.proxy.response-headers` | | Compress eligible responses | **Performance → Compression policies** | `clearplane.proxy.compression` | | Cache eligible responses | **Performance → Cache policies** | `clearplane.proxy.cache` | ## UI Create a named policy in the relevant UI area, choose Global or Route scope deliberately, and assign Route policies to the intended proxy route. Assigning a policy sets the route's state for that family to **On**, so it replaces the Global policies. The route dialog's **Policies** section shows every family's state; set a family to **Off** to opt the route out of a Global policy. Start with one route when a control can reject, rewrite, or cache traffic. The Name is free text shown in lists. The System name is generated from it while creating the policy and can be edited; copy that value into `*.policy` labels. Renaming a saved policy preserves its System name. The UI is the source of truth for UI-created policies. Use Logs and Analytics to verify the policy's effect. ## Docker labels For a discovered service, set the family's root label to `on`, then either select existing named Route policies by System name with its `*.policy` label or omit `policy` and use inline labels. Access control, authentication, auto-ban, cache, compression, CORS, rate limit, request headers, response headers and WAF all use this shape. Inline policies belong only to that discovered service and cannot be edited as shared UI policies. Without the root label, the route inherits the family's Global policies, and any other label of that family rejects the container. Set the root label to `Off` to opt the route out, or to `Inherit` to return to the Global policies. Under `Inherit` and `Off`, the family's other labels are kept but ignored, so you can switch a policy off for testing without removing them. Do not combine a named-policy label with that family's inline labels. The [Docker label reference](/docs/configuration/docker-labels/#policy-labels) shows every family. Repeatable credentials, JWT keys and claims, and header transforms use `..`. Indices may have gaps and are processed in numeric order, but each entry must be complete. Use the [proxy directives](/docs/configuration/catalog/#proxy-directives) for exact combinations, defaults, and accepted values. ### Basic authentication Omit `authentication.policy` to create an inline Basic policy. Each credential is one complete indexed entry: ```yaml services: app: labels: clearplane.proxy.authentication: "On" clearplane.proxy.authentication.type: "Basic" clearplane.proxy.authentication.key-location: "Edge" clearplane.proxy.authentication.basic.realm: "Restricted" clearplane.proxy.authentication.basic.credentials.1.username: "alice" clearplane.proxy.authentication.basic.credentials.1.password: "replace-with-a-password" ``` ### JWT bearer authentication JWT signing keys and required claims use the same indexed-entry contract: ```yaml services: api: labels: clearplane.proxy.authentication: "On" clearplane.proxy.authentication.type: "JwtBearer" clearplane.proxy.authentication.jwt.issuer: "https://identity.example.com" clearplane.proxy.authentication.jwt.audiences: "clearplane-api account-api" clearplane.proxy.authentication.jwt.signing-keys.1.kind: "Symmetric" clearplane.proxy.authentication.jwt.signing-keys.1.material: "a-secret-signing-key-at-least-32-characters" clearplane.proxy.authentication.jwt.required-claims.1.claim: "scope" clearplane.proxy.authentication.jwt.required-claims.1.value: "clearplane.read" ``` Docker labels are visible through container inspection and Compose source. Basic passwords and JWT signing-key material are secret metadata. If they cannot be stored safely there, create a named authentication policy in the UI or API and select it with `clearplane.proxy.authentication.policy`, together with `clearplane.proxy.authentication: "On"`. ### Restricted service baseline Use this starting point for a service that should accept traffic only from one client address and temporarily ban repeated bad behavior: ```yaml services: app: image: example/app:latest labels: clearplane.proxy.enabled: "true" clearplane.proxy.host: "app.example.com" clearplane.proxy.port: "8080" clearplane.proxy.access-control: "On" clearplane.proxy.access-control.default-action: "Block" clearplane.proxy.access-control.allow-addresses: "123.123.123.123" clearplane.proxy.auto-ban: "On" clearplane.proxy.auto-ban.rate-limit-violation.enabled: "false" clearplane.proxy.auto-ban.error-response.enabled: "true" clearplane.proxy.auto-ban.error-response.threshold: "30" clearplane.proxy.auto-ban.error-response.window-seconds: "60" clearplane.proxy.auto-ban.ban-duration-seconds: "600" ``` Only `123.123.123.123` can reach the application. If that client produces 30 proxied 4xx responses within 60 seconds, Clearplane bans it across every route for 10 minutes; access-control rejections, rate-limit rejections, and ban responses do not count toward the threshold. Edge's own 401 does count when a client presents credentials that fail an authentication policy. ## Cache policies and shared pools Create cache policies in **Performance → Cache policies**. A policy holds the eligibility, storage mode, lifetimes, cache-key settings and a pool size. A new policy caches static files by extension, ignores request cookies unless they are listed as bypass cookies, and answers `If-None-Match` from the cache; [Docker labels → Caching](/docs/configuration/docker-labels/#proxy-caching) describes each rule. Every route that uses the policy shares that pool, and eviction removes the least recently used entries across all of them. Entries stay separate per route, and purges still apply to one route. **Path rules** in the policy editor give parts of an application their own caching, for example `/_framework/*` for a year, `/api/*` never and `/` as HTML. The first matching rule applies; each rule either caches the path, with an optional lifetime and browser lifetime, or bypasses it. [Docker labels → Caching](/docs/configuration/docker-labels/#proxy-caching) describes the pattern syntax and the equivalent `path-rules` label. The list shows each policy's storage mode and **Pool usage**, the space its routes currently use against the pool size. Assigning more routes to a policy does not use more of the global per-tier cache limit; each enabled policy counts once. Creating or enlarging a policy that would exceed the limit is rejected. ## Browse cached responses Open **Performance → Cache** and choose **Browse** beside a route to inspect its cache in a full-width dialog. If a route is already selected, the overview shows only that route. The dialog contains the bin summary, searchable and sortable entries, freshness and storage filters, and pagination. Open an entry for response metadata, sanitized headers and the request headers it **Varies on**; cached response bodies are not exposed. **Purge resource** removes every cached variant of that URI only from the browsed route. ## Understand cache activity On **Performance → Cache**, each completed request on a cache-enabled route counts once: - **Hits** are fresh responses served from cache, including disk fallback, responses compressed from a cached identity representation, and entries the upstream confirmed unchanged (`REVALIDATED`). - **Misses** need an upstream response because no reusable entry is available or revalidation is required. - **Stale responses** are cached responses served during the configured stale-while-revalidate or stale-if-error window; they count separately from hits and misses. - **Bypasses** are requests or responses excluded by cache safety rules, response-size limits, or response inspection. For example, bypass cookies, private responses, and upstream responses in an encoding Clearplane did not request bypass caching. - **Dynamic** requests are not eligible under the route's policy, such as HTML pages under static-file eligibility. **Hit ratio** is the share of eligible requests (hits, stale responses, misses and bypasses) answered from cache, and **Served from cache** totals the response bytes Edge sent from cache instead of fetching them. Request counters live in Edge memory and reset when Edge restarts. Purging entries preserves activity counters. The route table lists active cache-enabled routes; global totals can also include activity from routes that have since been disabled or removed. **Disk files** counts persistent entries, so memory-only caching can use memory while showing zero disk files. **Evictions** count entries removed for policy pool or global capacity limits, separately for each storage tier. **Storage errors** count failed persistent-cache operations and corrupt entries. Normal expiration, removed routes, and entries skipped for response-size limits are not errors. Route-specific failures appear in that route's row even when it has no stored entries; shared index or directory failures appear only in the global total. Edge application logs include the operation, route when known, and exception for storage failures. To investigate a high miss rate, filter **Observability → Logs** by cache result and cache reason, or open a request log entry for the affected route and check its **Cache** (`HIT`, `MISS`, `STALE`, `REVALIDATED`, `BYPASS` or `DYNAMIC`) and **Cache reason** fields; hits, revalidations and dynamic requests have no reason. Miss reasons distinguish `NotFound`, `Expired`, `RequestNoCache`, and `ResponseNoCache`; bypass reasons identify exclusions such as `Cookie`, `Authorization`, `ResponsePrivate`, `VaryCredentialHeader`, `VariantLimit`, `ContentTypeMismatch`, `OverrideHeader`, `Range`, `ConditionalRequest`, `CacheTagLimit`, `EncodedUpstreamResponse`, or `ResponseTooLarge`. Check the route's lifetime, upstream cache directives, key settings, and eviction activity alongside these reasons. Different included query-string values or headers create separate entries. ## Purge cached responses Choose **Purge cache** on **Performance → Cache** to remove entries from every connected Edge and both storage tiers. Purge one exact URI, a URI prefix, a proxy route, everything, or **Cache tags**. A tag purge removes every entry whose upstream response listed one of the tags in `Cache-Tag` or `Surrogate-Key`, so a deploy can clear the pages that show one product without purging the site. The same purges are available through `POST /api/cache/purge` and [`clearplane cache purge`](/docs/cli/#purge-the-cache). The cache browser shows each entry's tags. ## Cache isolation With the path included in the cache key, encoded paths that reach different upstream resources remain separate cache entries. For example, `/p%2561y` and `/pay` do not share a response. Exact-URI and URI-prefix purges preserve that distinction. ## Verify Test an allowed request and the condition the policy should change. Confirm the response, then check Logs or Analytics for the same route before expanding the policy's scope. ================================================================================ DOCUMENT: Challenge suspicious browser requests Human URL: /docs/guides/bot-challenges/ ================================================================================ Edge can return a proof-of-work page when a browser request meets a configured WAF or rate-limit trigger. The browser searches for a SHA-256 value with the required number of leading zero bits, then receives a clearance cookie. The page loads no external resources and contacts no third-party service. ## Enable challenges Open the route's [WAF policy](/docs/security/waf-rulesets/#waf-policies) under **Firewall → WAF policies**, set it to **Prevention**, then select **Proof of work** under **Bot challenges**. Challenges run only on the policy's routes that also redirect HTTP to HTTPS; the attention list names routes where they cannot. Ordinary `GET` and `HEAD` requests must use HTTPS and accept `text/html` or `*/*`. WebSocket upgrades, gRPC traffic and requests that cannot accept HTML keep their protocol behavior. For a discovered route, add `clearplane.proxy.waf.challenge.mode: ProofOfWork` alongside `clearplane.proxy.waf: "On"`, `clearplane.proxy.waf.mode: Prevention` and its HTTPS redirect or certificate configuration. `challenge.threshold`, `challenge.difficulty` and `challenge.clearance-minutes` set the rest of the inline policy's challenge settings. An invalid value rejects the container; without an HTTPS redirect the route never challenges, and discovery records a warning. ## Choose a trigger - **Combined score:** a request reaches the challenge threshold without reaching its block threshold. - **Challenge rule:** a matching request-stage rule uses `action: Challenge`, belongs to an effective Prevention ruleset and falls within the policy's blocking paranoia level. Challenge rules add no score. - **Rate limit:** an applicable policy has **Challenge browsers** selected as its action and exhausts its limit. Detection evaluations never trigger challenges. Under **Per ruleset** scoring, only explicit Challenge rules and Challenge rate limits trigger. The attention panel warns when a configured route has no trigger that can fire. ## Blocking and clearance A WAF block takes precedence over a WAF challenge. Ineligible requests are scored by the other rules as usual; an ineligible request that exceeds a Challenge rate limit receives `429`. A valid clearance prevents another challenge, but the WAF still inspects the request and may block it. Clearance bypasses only Challenge rate limit policies: a separate rejecting policy still applies. The proof form posts to the reserved `/_clearplane/challenge` path. Verification retains the original ban, access-control and authentication requirements. The token binds the original route and return path; malformed, stale or mismatched submissions terminate locally. The original application receives no proof form. ## Privacy and token lifetime The `__Host-clearplane_clearance` cookie is **Secure**, **HttpOnly**, **SameSite=Lax**, host-only, and uses `Path=/`. Its signature binds the client's IPv4 /24 or IPv6 /64 address prefix, the user-agent hash, the hostname and an expiry. A clearance can apply to other challenge-enabled routes on the same host; their WAF and rejecting rate policies still apply. Pending challenge tokens expire after **300 seconds** and bind the same client information plus the return path and original route. They are stateless; this does not provide single-use replay tracking. Changing the bound client information requires a new proof. ## Operations Analytics attributes challenge pages to the **Challenge** block source. WAF-triggered challenges appear in Detections with decision **Challenged**. A rate-limit challenge is a rate-limit outcome and does not create a WAF evaluation or an auto-ban violation. Rotate the challenge clearance key with the stack stopped, using the [secret maintenance procedure](/docs/cli/#secret-status-and-rotation). Replace service keys if your Compose file uses different ones: ```bash docker compose down && docker compose run --rm --no-deps clearplane-core secrets rotate challenge-clearance && docker compose up -d --wait ``` Starting Edge again loads the new key and invalidates all existing clearances and pending challenges. Do not delete or replace individual machine-secret files. See [Challenge actions and scoring](/docs/waf-reference/scoring-and-integrity-tests/#challenge-actions) and the [login-path example](/docs/waf-reference/examples/#challenge-a-login-path) when writing a custom challenge rule. ================================================================================ DOCUMENT: Enable HTTPS Human URL: /docs/guides/enable-https/ ================================================================================ Serve a published hostname over trusted HTTPS, then redirect HTTP only after the certificate is active. ## Before you start - Publish the service first. - Point each public route hostname at Clearplane; include wildcard DNS records for wildcard routes. - Choose HTTP validation, DNS validation, or an uploaded certificate. - Ensure any upstream proxy passes validation traffic unchanged. HTTP-01 requires public TCP port 80 to reach Edge for issuance and renewal. Compose health cannot prove public DNS, firewall/NAT reachability, or certificate trust; verify those separately and correct DNS and ingress before retrying rate-limited production issuance. Use DNS-01 for wildcard certificates or when public port 80 is unavailable. An internal-only name requires an uploaded private-CA certificate trusted by its clients. ## UI 1. Open **Certificates** and request a certificate for the hostname, or upload one that already covers it. 2. Wait until the certificate status is **Active**. 3. Open **Proxy routes**, edit the route, and enable **Redirect HTTP to HTTPS**. 4. Save and apply the change when required. ## Select HTTPS protocols Open **System → Settings → Edge → HTTPS protocols** and independently enable HTTP/1.1, HTTP/2, and HTTP/3. You can select any nonempty combination, such as HTTP/2 only or HTTP/2 plus HTTP/3. Save the settings and restart Edge; applying configuration alone does not change its listeners. To select HTTP/2 and HTTP/3 through Compose instead, add these labels to Edge: ```yaml services: clearplane-edge: labels: clearplane.edge.http1.enabled: "false" clearplane.edge.http2.enabled: "true" clearplane.edge.http3.enabled: "true" ``` A label overrides and locks the matching UI switch. Omit a label to use its saved UI value. Recreate Edge after changing its labels; if the Dashboard still reports that Edge needs a restart, restart it once more so it starts with the new selection. The selection controls public HTTPS. The plain HTTP listener keeps HTTP/1.1 for HTTP-to-HTTPS redirects, ACME HTTP-01 challenges, and health checks. Disabling HTTP/1.1 on HTTPS does not disable that listener or alter route-level redirects. For HTTP/3, allow UDP port 443 through the host firewall, NAT, and any upstream network boundary. TCP 443 is still needed when HTTP/1.1 or HTTP/2 is selected. HTTP/3-only needs a QUIC-capable runtime and clients that can discover or directly request it. Browsers normally discover HTTP/3 through an `Alt-Svc` response over HTTP/1.1 or HTTP/2, which is unavailable when both are disabled. Edge reports a startup error if HTTP/3 is the only selection and QUIC is unavailable; it never silently re-enables a disabled protocol. ## Docker labels Enable certificate management and the HTTPS redirect on the application container: ```yaml labels: clearplane.proxy.certificate.enabled: "true" clearplane.proxy.redirect.http-to-https: "true" ``` For DNS validation, either reference a shared credential profile with `clearplane.proxy.certificate.dns.profile` or supply inline DNS settings on the application. See the [proxy directives](/docs/configuration/catalog/#proxy-directives) for every certificate and HTTPS label. ## DNS credentials in the UI Create a shared Cloudflare DNS-01 credential profile in the UI and select it when requesting a DNS-01 certificate. Core encrypts UI-managed tokens with its Data Protection keys. Tokens are write-only: supply a token on creation or rotation; the API never returns it. Scope the Cloudflare API token to the required zones with DNS record edit and zone read access. Keep deployment secret files out of source control and readable only by the deployment account. ## Inline DNS profiles Define the provider and token directly on an application's labels when its credentials should stay with that app: ```yaml labels: clearplane.proxy.enabled: "true" clearplane.proxy.host: "*.example.com" clearplane.proxy.port: "8080" clearplane.proxy.certificate.enabled: "true" clearplane.proxy.certificate.dns.provider: "Cloudflare" clearplane.proxy.certificate.dns.api-token: "${CLOUDFLARE_API_TOKEN:?Set CLOUDFLARE_API_TOKEN}" clearplane.proxy.certificate.dns.propagation-seconds: "30" clearplane.proxy.redirect.http-to-https: "true" ``` Inject the token through GitHub Actions secrets using the `env` example below. No JSON or separate profile setup is needed. For a standalone redirect, use the same fields under `clearplane.redirect.certificate.dns.*`. Choose either inline DNS fields or `certificate.dns.profile`; combining them rejects the app configuration and retains its previous valid settings. Omitting both selects HTTP-01. DNS fields are ignored with a warning when certificate management is disabled. Core creates a read-only `{resource-name}-acme-dns` profile, encrypts the token, and updates it when the app's labels change. Container recreation and route renaming keep the same profile. Other apps and manual certificate requests cannot reference it by name; use a shared profile for credentials or certificates used by several apps. Generated names are reserved and cannot be replaced by a later Core profile of the same name. Stopping or removing an app retains credentials needed to renew its existing certificates. The generated profile is removed when no app requests it and no ACME certificate references it. Tokens are never returned by the API or discovery diagnostics, but Docker inspection can reveal secret labels. Avoid printing rendered Compose configuration in Actions logs. ## Shared profiles on Core Add numbered environment variables to the Core service in `docker-compose.override.yml`. Each number creates a named profile at startup. This example defines two profiles with separate scalar tokens: ```yaml services: clearplane-core: environment: CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_1_NAME: cloudflare-test CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_1_PROVIDER: Cloudflare CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_1_API_TOKEN: ${CLOUDFLARE_API_TOKEN:?Set CLOUDFLARE_API_TOKEN} CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_1_PROPAGATION_SECONDS: "30" CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_2_NAME: cloudflare-other-zone CLEARPLANE_CORE_BOOTSTRAP_ACME_DNS_PROFILE_2_API_TOKEN: ${SECOND_CLOUDFLARE_API_TOKEN:?Set SECOND_CLOUDFLARE_API_TOKEN} ``` Remove the `_2_` entries for one profile, or add `_3_` and higher numbers for more. No JSON encoding or UI setup is needed. A GitHub Actions step that runs Compose can receive the tokens through `env`: ```yaml env: CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }} SECOND_CLOUDFLARE_API_TOKEN: ${{ secrets.SECOND_CLOUDFLARE_API_TOKEN }} ``` Compose resolves these variables on the machine running Compose. When Actions deploys to another host, use the deployment's existing secret-injection step to supply them there; the runner's environment is not automatically forwarded. See [GitHub Actions secrets](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets) and [Compose interpolation](https://docs.docker.com/compose/how-tos/environment-variables/variable-interpolation/). Use a Cloudflare token with DNS record edit and zone read access for the required zones. Shared profiles keep it in Core's environment or a mounted secret file. Avoid printing the rendered Compose configuration in Actions logs. To use a mounted token, replace `_API_TOKEN` with `_API_TOKEN_FILE` and set its value to the container's secret-file path; setting both is an error. Core environment profiles are read-only in the UI and take precedence over UI-managed profiles with the same name. Recreate Core after changing these profiles or rotating their tokens. For inline app credentials, recreate the application instead so discovery receives the changed labels. Shared profiles can also read tokens from mounted files or a JSON bootstrap document. See the [environment variable reference](/docs/configuration/environment-variables/#dns-profile-secret-files) for both formats. ## Wildcard routing and certificates Let's Encrypt wildcard certificates require [DNS-01 validation](https://letsencrypt.org/docs/challenge-types/#dns-01-challenge). The inline example above publishes tenant hosts. To publish the apex and tenant hosts using a shared profile instead: ```yaml labels: clearplane.proxy.enabled: "true" clearplane.proxy.host: "example.com" clearplane.proxy.additional-hosts: "*.example.com" clearplane.proxy.port: "8080" clearplane.proxy.certificate.enabled: "true" clearplane.proxy.certificate.dns.profile: "cloudflare-test" clearplane.proxy.redirect.http-to-https: "true" ``` This route accepts `example.com` and one subdomain level, such as `tenant.example.com`. The wildcard alone does not match the apex or `deep.tenant.example.com`. You can instead set `clearplane.proxy.host: "*.example.com"` and omit `additional-hosts` to publish only tenant hosts. Certificate automation includes wildcard route hosts in the certificate request. The example requests `example.com` and `*.example.com`; `clearplane.proxy.certificate.wildcard` is not needed because the wildcard is already a route host. Exact names already covered by a wildcard are omitted from the additional certificate names. Keep the DNS profile available for automatic renewal. Edge selects an exact certificate for the requested hostname first, then a valid wildcard certificate covering one subdomain level. Wildcard certificate coverage does not create routes: configure the route hosts separately. ## Upstream proxies HTTP validation requires `/.well-known/acme-challenge/*` to reach Clearplane without caching, redirecting, or rewriting the host or path. Use DNS validation when an upstream proxy cannot preserve that request. ## Verify Open the HTTPS URL and confirm the browser trusts the certificate for the exact hostname. Request the HTTP URL and confirm it redirects only after HTTPS is working. ================================================================================ DOCUMENT: Export metrics and WAF events Human URL: /docs/guides/export-metrics-and-waf-events/ ================================================================================ ## Before you start Open **System → Settings → Observability** with `Observability.Manage`. Reading metrics requires the separate `Metrics.Read` permission or a scrape token. Administrators have both permissions automatically. Only Core makes outbound exporter connections. Export is optional and works without a Cloud account. The management route's access controls and rate limits also apply to metric scrapes. ## Export metrics over OTLP Set **OTLP endpoint** to an absolute `http` or `https` URL without embedded credentials or a fragment. An empty or `/` path becomes `/v1/metrics`; a custom path is kept. Core sends OTLP/HTTP protobuf with `service.name=clearplane-core` and `service.version`. Saving applies the endpoint immediately after the settings commit. Clearing it stops OTLP export. Neither action requires an Edge apply or restart. ## Scrape with Prometheus Create a named scrape token in **Scrape tokens** and copy it before closing the dialog. Only its SHA-256 hash is stored; the secret cannot be retrieved later. The list shows creation and last-use times. Revoking a token prevents later scrapes with it. Send the token as a bearer credential to `GET /api/metrics` on the public management API route. A ready browser session or API session with `Metrics.Read` can also read it. Scrape tokens authorize only this endpoint. ```yaml scrape_configs: - job_name: clearplane scheme: https metrics_path: /api/metrics authorization: type: Bearer credentials_file: /etc/prometheus/clearplane-token static_configs: - targets: ['clearplane.example.com'] ``` The credentials file contains the complete `cpst_…` token. Requests without valid operator credentials receive 401; an authenticated session without `Metrics.Read` receives 403. ## Metric reference Counters keep their cumulative totals across Edge restarts while Core remains running. Cross-boot accumulated history is held in Core memory; restarting Core starts from the current Edge counters. Select the `clearplane.edge.online` gauge when deciding whether the WAF data is current. While Edge is offline, WAF series stop reporting; the online gauge remains at zero. | OpenTelemetry name | Prometheus name | Type | Labels | Meaning | |---|---|---|---|---| | `clearplane.waf.evaluations` | `clearplane_waf_evaluations_total` | counter | stage | WAF transactions evaluated, including WebSocket messages by stage. | | `clearplane.waf.decisions` | `clearplane_waf_decisions_total` | counter | stage, decision | Completed WAF decisions. | | `clearplane.waf.ruleset.matches` | `clearplane_waf_ruleset_matches_total` | counter | ruleset, effective_mode | Evaluations with at least one match for that ruleset; clean evaluations do not count. | | `clearplane.waf.budget_exhausted` | `clearplane_waf_budget_exhausted_total` | counter | — | Transactions that exhausted their work budget. | | `clearplane.waf.challenges` | `clearplane_waf_challenges_total` | counter | — | Requests answered with a WAF bot challenge. | | `clearplane.waf.connections_closed` | `clearplane_waf_connections_closed_total` | counter | — | WebSocket connections closed by the WAF. | | `clearplane.waf.body_truncated` | `clearplane_waf_body_truncated_total` | counter | — | Request bodies inspected only up to the configured limit. | | `clearplane.waf.grpc_messages` | `clearplane_waf_grpc_messages_total` | counter | — | gRPC messages inspected. | | `clearplane.waf.audit_events_dropped` | `clearplane_waf_audit_events_dropped_total` | counter | — | Audit events dropped under back-pressure. | | `clearplane.waf.rulesets.active` | `clearplane_waf_rulesets_active` | gauge | ruleset, version, stage | One for each currently active ruleset version and stage. | | `clearplane.waf.rulesets.skipped` | `clearplane_waf_rulesets_skipped` | gauge | ruleset, version | One for a current release Edge skipped because it requires a newer engine. | | `clearplane.edge.online` | `clearplane_edge_online` | gauge | — | One while Edge statistics are available, zero while unavailable. | The Prometheus exporter also adds `otel_scope_name="Clearplane.Core"` and a `target_info` series containing SDK and service metadata. Labels never contain rule IDs, request paths, host names, route names or addresses. For decision, score and ruleset meanings, see [WAF detections](/docs/security/waf-detections/) and [WAF rulesets](/docs/security/waf-rulesets/). ## Stream WAF events Under **Destinations**, add syslog, webhook or OTLP log destinations. Choose decision filters, or leave them empty for all decisions, and set a minimum combined blocking score. Filter changes apply to the remaining backlog. The minimum uses the actual blocking contribution, not the sum of configured finding scores: Detection-only matches and Challenge actions contribute zero. Keep the minimum at 0 when exporting those events. See [Scoring and integrity tests](/docs/waf-reference/scoring-and-integrity-tests/) for the score definitions. Export includes events newer than the destination's creation time. Delivery is at least once: deduplicate retries using `event.id`. The list shows the last successful delivery, consecutive failures and a fixed error such as **Destination address is restricted**, **TLS handshake failed**, **Connection failed**, **Timed out**, **Client certificate is unreadable**, **HTTP 503**, or **Delivery failed**. Correcting destination settings clears the old retry delay. Disabling pauses export. Re-enabling sends the backlog that remains on disk. Raw log retention bounds the backlog; deleted source files cannot be recovered by the exporter. Changing a destination's kind requires creating a new destination. ## Event fields The ECS document contains sanitized WAF audit metadata. Request and response bodies, header values and query values are never exported. | Field | Content | |---|---| | `@timestamp` | Audit event time in UTC. | | `event.id` | Stable identifier for the destination’s source-file generation and byte offset, used for retry deduplication. | | `event.kind`, `event.module`, `event.dataset` | `event`, `clearplane`, and `clearplane.waf`. | | `event.category`, `event.type`, `event.action` | Web/intrusion-detection categories, denied or informational type, and WAF decision. | | `observer.*` | Clearplane vendor, product, WAF type and version. | | `http.request.method`, `http.response.status_code` | Request method and response status. | | `url.domain`, `url.path`, `source.ip` | Host, path without query values, and source address. | | `rule.id`, `rule.ruleset` | Rule IDs and ruleset IDs represented by audit findings. | | `clearplane.waf.*` | Route, stage, mode, scoring mode, decision, failure code, correlation ID and combined scores. | | `clearplane.waf.evaluations[]` | Ruleset/version, effective mode, blocking/detection scores, threshold and threshold result. | | `clearplane.waf.findings[]` | Ruleset/rule IDs, revision, severity, target, field name and reason code. | ## Webhook A webhook requires HTTPS. Core posts a JSON array with an `X-Clearplane-Signature` header in the form `t=,v1=`. The signing key is shown once when the destination is created or its key is rotated. A normal save does not reveal it. Rotation replaces the old key for later batches. Verify the raw request bytes before processing the array. Use the UTF-8 bytes of the displayed key directly; do not decode it as Base64. This example allows a five-minute timestamp window: ```python import hashlib import hmac import time def verify(body: bytes, header: str, key: str, tolerance: int = 300) -> bool: try: parts = dict(item.split("=", 1) for item in header.split(",")) timestamp = int(parts["t"]) signed = f"{timestamp}.".encode() + body expected = hmac.new(key.encode(), signed, hashlib.sha256).hexdigest() return abs(time.time() - timestamp) <= tolerance and hmac.compare_digest(expected, parts["v1"]) except (KeyError, ValueError): return False ``` ## Syslog over TLS Use `host:port`, usually port 6514; bracket IPv6 addresses, for example `[2001:db8::1]:6514`. Messages use RFC 5424 with RFC 5425 octet counting over TLS/TCP, facility `local0`. Denied events, including challenges, use warning severity; others use informational severity. By default the destination uses system certificate trust. An optional CA PEM replaces that trust for this destination. The server host name is always validated. The CA field accepts public certificates only. To use mutual TLS, put the client certificate and its private key together in the separate **Client certificate PEM** field. ## OTLP logs OTLP log destinations accept an absolute HTTP or HTTPS URL. An empty or `/` path becomes `/v1/logs`; custom paths are kept. Core sends OTLP/HTTP JSON, using the ECS JSON as each log record's string body. Records carry `event.id`, `event.action`, `source.ip` and `url.domain` attributes, with `service.name=clearplane-core` and `service.version` on the resource. An optional single-line Authorization header is supported. When editing, leave a replacement secret blank to keep it, or use the explicit remove control to clear it. ## Egress and secrets Every new exporter connection checks resolved destination addresses against the global restricted destination classes. The control-plane network is always refused, even if the operator has not selected that class. Core connects only to an allowed resolved address; HTTP redirects and system proxy routing are disabled. Webhook signing keys, client certificate PEMs and Authorization headers are encrypted at rest. List and ordinary update responses expose presence flags. Only newly generated webhook keys and scrape tokens are shown once. Keep them with the receiving system's secrets. See [Exposure and network boundaries](/docs/security/exposure-and-networks/) for management access and network wiring. ================================================================================ DOCUMENT: Guides Human URL: /docs/guides/ ================================================================================ Use these guides to reach an operator outcome without reading the full configuration tables. - [Publish a service](publish-service/) connects a hostname to an upstream application. - [Enable HTTPS](enable-https/) adds a trusted certificate and redirects HTTP after the certificate is active. - [Ban abusive clients automatically](protect-service/) uses route-scoped behavior triggers to apply temporary IP bans. - [Configure access, traffic, and delivery](access-traffic-delivery/) maps common goals to UI areas and Docker-label families. - [Write custom WAF rules](write-custom-waf-rules/) writes, tests and publishes your own rulesets without Cloud. - [Validate requests against an API schema](validate-api-schemas/) turns requests that do not match a route's OpenAPI document into scored WAF findings. - [Challenge suspicious browser requests](bot-challenges/) combines WAF and rate-limit signals with a proof-of-work page served by Edge. - [Export metrics and WAF events](export-metrics-and-waf-events/) sends WAF metrics to OTLP or Prometheus and streams WAF events to a SIEM. Each configuration guide gives UI and Docker-label paths equal prominence, then links to [Reference](../configuration/) for exact settings. ================================================================================ DOCUMENT: Ban abusive clients automatically Human URL: /docs/guides/protect-service/ ================================================================================ Protect a service from repeated bad behavior with a route-scoped trigger policy that applies temporary IP bans. Automatic bans respond to observed behavior; they do not classify one request as an attack. The trigger observes only the selected routes. After it fires, the IP ban applies to that client address across Clearplane until it expires or an operator lifts it. ## Before you start - Publish the service and verify normal requests. - Identify which upstream 4xx responses represent repeated bad behavior for this application. - Choose a threshold, rolling window, and temporary ban duration. - Start with one route and account for clients that may share a public IP address. The resulting ban affects every route for that address. ## UI 1. Open **Abuse → Auto-ban policies** and create a policy. 2. Choose **Route** scope and assign only the service being protected. 3. Enable **Ban on repeated 4xx responses**. Leave **Counted status codes** empty to count every upstream 400–499 response, or enter only the codes that represent bad behavior for this service. Upstream 5xx failures never count. Edge's own 401 counts when a client presents credentials that fail an authentication policy on the route. 4. Set **Responses before ban**, **Window**, and **Ban duration**. Start with a high threshold and a short ban while observing real traffic. 5. Leave **Ban on repeated rate limit violations** off unless an enabled IP-keyed rate limit policy covers the same route. 6. Enable and save the policy. ## Docker labels Create an inline auto-ban policy on the discovered service: ```yaml labels: clearplane.proxy.auto-ban: "On" clearplane.proxy.auto-ban.rate-limit-violation.enabled: "false" clearplane.proxy.auto-ban.error-response.enabled: "true" clearplane.proxy.auto-ban.error-response.threshold: "100" clearplane.proxy.auto-ban.error-response.window-seconds: "60" clearplane.proxy.auto-ban.ban-duration-seconds: "600" ``` This example bans a client after 100 proxied 4xx responses within 60 seconds and lifts the ban after 600 seconds. Add `clearplane.proxy.auto-ban.error-response.status-codes` to count only selected 4xx responses. Leave escalation disabled until the initial policy has been observed in normal traffic. See the [proxy directives](/docs/configuration/catalog/#proxy-directives) for accepted values and optional escalation settings. ## Verify Send normal requests and confirm they still reach the application. In a controlled test, reach the configured threshold from one client, confirm the next request receives a ban response, inspect the record under **Bans**, then confirm traffic resumes after the ban expires or is lifted. ================================================================================ DOCUMENT: Publish a service Human URL: /docs/guides/publish-service/ ================================================================================ Publish one hostname through Clearplane and confirm that requests reach the intended upstream. ## Before you start - Use a working Clearplane deployment. - Point the hostname at the deployment. - Make the application reachable from Clearplane. - Know the application's scheme and listening port. Choose UI ownership or Docker-label ownership for the route. Keep later changes in the same source. ## UI 1. Open **Upstream destinations** and create the application destination with its reachable address, scheme, and port. 2. Open **Upstream clusters** and create a cluster that contains the destination. 3. Open **Proxy routes** and create a route for the public hostname using that cluster. 4. Save the route and apply configuration if the UI reports that an apply is required. UI-created resources remain UI-owned. ## Docker labels Add labels to the application container: ```yaml services: app: image: example/app:latest labels: clearplane.proxy.enabled: "true" clearplane.proxy.host: "app.example.com" clearplane.proxy.port: "8080" ``` Clearplane creates the destination, cluster, and route from the discovered container. Change label-owned resources at the container definition, not in the UI. See the [proxy directives](/docs/configuration/catalog/#proxy-directives) for paths, path rewrites, alternate hosts, route order, and the upstream activity timeout. ## Verify Open the public hostname and confirm the expected application responds. In Clearplane, confirm the route names the intended cluster and destination. If the request fails, filter Logs to that route before changing configuration. ================================================================================ DOCUMENT: Validate requests against an API schema Human URL: /docs/guides/validate-api-schemas/ ================================================================================ Attach one OpenAPI **3.0 or 3.1** document to a [WAF policy](/docs/security/waf-rulesets/#waf-policies) to check requests on the routes it reaches: operations, path/query/header parameters, request content types and JSON bodies. Upload JSON or YAML. Swagger 2.0 and OpenAPI 3.2 are not supported. ## How violations become decisions Validation adds `SchemaViolation` fields to the normal request inspection stages. Each field has a violation kind as its name and a JSON pointer as its value. Rules in `clearplane-api-schema`, or [your own custom rules](/docs/guides/write-custom-waf-rules/), assign scores. Policy mode, ruleset mode, scoring mode, paranoia levels, disabled rules and exclusions apply as usual. | Kind | Pointer examples | |---|---| | `unknown-operation` | `/paths/~1admin/get` | | `unknown-parameter` | `/query/debug` | | `invalid-type` | `/path/id`, `/body/items/0/price` | | `missing-required` | `/header/X-Tenant`, `/requestBody`, `/body` | | `unknown-property` | `/body`, `/body/customer` | | `invalid-content-type` | `/requestBody`, `/requestBody/content` | Unknown query parameters are flagged. Unknown headers are allowed because browsers and proxies add headers. Use `additionalProperties: false` on JSON objects that should reject extra properties, such as fields that could otherwise enable mass assignment. JSON bodies use the schema declared for their matching `application/json` or `+json` media type. OpenAPI request schemas honor `readOnly` properties when determining required input; `writeOnly` properties remain valid request fields. ## Upload a document Open **Firewall → WAF policies**, edit a policy, and use **API schema** to select and upload a file. You need **WAF policies: Write**. Policies defined by container labels cannot attach or remove documents. The upload is a separate operation from saving other policy fields. Give an API its own Route policy: a document on the Global policy applies to every route that inherits it. A successful upload displays the original document hash, format, upload time and operation count. Upload another file to replace it, or remove the attached document to stop schema validation. Failed uploads retain the selected file for correction or retry and preserve the previous schema. References must stay inside the document's `components`. External URLs and files are refused, and the compiler performs no network resolution. Recursive references, dynamic references, custom schema identifiers and unsupported parameter serialization are refused with an upload error. Path/header arrays use comma-separated values; query arrays use repeated parameters. Object parameters and non-default serialization styles are not supported. ## Start in Detection Use Detection while comparing normal application traffic with the document. Review schema findings, correct the document or apply narrow exclusions, and then consider Prevention. Attaching a document does not by itself block traffic. An active ruleset must score `SchemaViolation`, and its score must reach the policy's blocking threshold. The dashboard warns when an enabled route's policy has a schema but no active ruleset contains schema-violation rules. The handshake or request metadata can be checked for WebSocket and gRPC requests. Their streamed messages are inspected by the corresponding WAF protocol support; this feature does not treat those messages as OpenAPI JSON request bodies. ## Limits If validation cannot finish within its limits, the WAF emits `ParserFact` named `schema-validation-limit-exceeded` and continues normal inspection. That fact and any completed violations remain available to scoring rules. An incomplete validation is not a clean result. Pattern matching uses bounded non-backtracking regexes; unsupported constructs such as lookarounds and backreferences are rejected during compilation. The [SchemaViolation target](/docs/waf-reference/targets/) and [schema validation facts](/docs/waf-reference/facts-and-limits/) are part of the rule language; attaching a schema supplies facts for active rules to score. ================================================================================ DOCUMENT: Write custom WAF rules Human URL: /docs/guides/write-custom-waf-rules/ ================================================================================ Use **Firewall → Custom rules** to write your own rulesets. Drafts, testing and publishing work with Cloud integration off and need no Cloud account. ## Before you start You need `WafRulesets.Read` to open and test the draft, `WafRulesets.Write` to save changes, and `WafRulesets.Manage` to publish. Choose a route on which you can check both normal traffic and the behavior you want to detect. The first draft is a template with the required `standard` and `management` profiles, default work limits, one example rule and two integrity tests. Saving keeps your text even when it has validation issues. A saved draft does not change Edge's active rules. ## Several rulesets Custom rules are not limited to one ruleset. The **Rulesets** selector on the page lists every draft you have, and each one publishes, activates and rolls back independently, so a change to rules for one application cannot disturb another. Identifiers are reserved: a draft is either the original `local` or starts with `local-`, such as `local-wordpress`. Clearplane refuses any other identifier, because that prefix is what tells the gateway a ruleset is yours and may arrive unsigned. A signed Cloud ruleset can never take an identifier in that range, and an unsigned one can never take an identifier outside it. Deleting a draft removes only the draft. A release you already published from it keeps running until you deactivate it on the Rulesets page. ## Copy a rule as a starting point Rather than write a rule from nothing, copy one from an installed ruleset into a draft and edit it. The copy is appended with a fresh rule identifier and added to the draft's profiles, and it keeps the source rule's provenance and licence. Attribution follows the rule, not the ruleset it arrived in. A rule adapted from an upstream project keeps its upstream reference, so copying it through Clearplane does not obscure where the logic came from; a Clearplane-authored rule records the ruleset and version you copied it from. When a copy brings in material under a different licence, the draft's own licence is restated to name it, in the same form the shipped rulesets use — for example `Proprietary; includes Apache-2.0 material from OWASP CRS`. Publishing a draft therefore publishes an accurate licence for what it actually contains. Copying requires `WafRulesets.Manage`. It is the one way rule patterns become visible to an operator: browsing rulesets with `WafRulesets.Read` still never exposes rule patterns, signed envelopes or signatures. Treat a draft holding copied rules as carrying whatever licence the source rule carried, which may not be the same as the rest of the draft. ## Write a rule The template scores requests containing a `__debug` query parameter. Its rule targets `QueryName`, lowercases it, and compares it with `__debug`: ```json "conditions": [ { "targets": [{ "target": "QueryName" }], "transformations": ["Lowercase"], "operator": { "kind": "Equal", "value": "__debug" } } ] ``` Keep this condition inside the template's rule object. Rule `1` uses `RequestMetadata`, paranoia level `1` and score `5`, and both profiles include its ID. With the draft published, its ruleset and the route's WAF policy in Prevention, and a blocking threshold of `5`, `/?__debug=1` reaches the threshold. In Detection, it records a match while allowing the request. Change the rule's message and conditions for your application. Include each rule ID in the profiles that should run it. Save the draft to see compiler issue codes and locations. ## Test the draft Choose **Request**, **WebSocket message** or **Response**, then set the input, profile and paranoia levels. Scheme, host, method and path describe the originating request; a request input's `Host` header takes precedence over the host field. Response inputs also take a status code and response headers. Use base64 for byte-exact bodies or binary WebSocket messages. Run the template against `/?__debug=1`, then against `/?q=hello`. Review the parsed fields, matched rule IDs, reasons, fingerprints, blocking score and detection score. Rules above the blocking paranoia level can contribute to the detection score without raising the blocking score. **Token view** previews a detector defined in your draft, including its tokens, grammar classes, assigned classes and fingerprints. **Run integrity tests** reports every stored test's expected and actual rule IDs. **Save as test** inserts the tested fields and expected matches into the editor. Save the draft again to store them. The action is available only when the input can be replayed faithfully within integrity-test limits. Work-budget exhaustion, truncated findings, oversized fields or input that cannot be represented suppress the generated test and report an issue. Changing the editor after a run requires another run before inserting its results. The raw request tester does not support framed gRPC or gRPC-Web inputs; these return `unsupported-grpc-test-input`. Test those protocols against an isolated protected application. The tester evaluates the draft; route policy, other active rulesets, transport streaming and deployment behavior still need an application-level check. Testing, token preview and publishing first save any changed editor text. A failed save keeps the text and stops the action. If another operator changed the draft, reload and reconcile your changes before saving again. ## Publish Every integrity test must pass, and at least one must exist. Select **Publish**, review the draft revision and choose Detection or Prevention. Publication checks both the reviewed draft revision and the activation generation, so a stale dialog cannot silently publish newer draft text or overwrite an unseen activation. Follow the activation on **Firewall → Rulesets**, then verify normal and matching requests on the chosen application. Promotion, rollback and deactivation are available there. Update strategies never apply to `local`. See [WAF rulesets](/docs/security/waf-rulesets/) and [scoring and paranoia levels](/docs/security/waf-scoring-and-paranoia/). ## Limits Local rules use the same validated language and bounded engine as signed rulesets. ## Editing through a protected Core route Drafts and tester inputs can contain attack examples. If WAF inspection is enabled on Clearplane's own Core route, those inputs pass through it and may be scored or blocked before reaching the editor API. Keep that route's WAF policy in Detection while editing, or apply a narrowly scoped exclusion for the affected Core API input. Keep normal management access controls in place. Read [unsigned local rules](/docs/security/internal-service-trust/#unsigned-local-rules) for the Core-to-Edge trust boundary. Use the [WAF rule language reference](/docs/waf-reference/) for the document format, field scope, operators and tested examples. ================================================================================ DOCUMENT: Clearplane documentation Human URL: /docs/ ================================================================================ Clearplane is a self-hosted web security gateway for routing and protecting traffic in infrastructure you control. ## Start here [Installation](get-started/) covers Docker Compose installation, first setup, updates, and the container lifecycle. ## Understand the model [Concepts](concepts/) explains routes, clusters, destinations, policies, configuration ownership, and the revision lifecycle. ## Understand the trust boundaries [Security & Trust](security/) explains public exposure, network isolation, internal service identity, container-runtime access, and layered hardening. ## Complete a task [Guides](guides/) cover publishing, HTTPS, protection, access, traffic, and delivery through the UI or Docker labels. ## Operate and troubleshoot [Operations](operations/) covers status, traffic, security events, configuration changes, and service troubleshooting. ## Use the CLI [CLI](cli/) lists every embedded Core command for status, setup, administrator recovery, bans, database maintenance, and secret rotation. ## Look up a setting [Reference](configuration/) contains every supported Docker label and environment variable, including accepted values, defaults, and apply behavior. ## Write or review WAF rules [WAF rule language](waf-reference/) covers ruleset JSON, conditions, token detectors, scoring and tested examples. ================================================================================ DOCUMENT: Change and apply configuration Human URL: /docs/operations/change-apply-configuration/ ================================================================================ Change a setting in the source that owns it, follow its [apply mode](/docs/concepts/configuration-lifecycle/#apply-modes), then verify the effective behavior. ## Know the owner - Edit UI-created routes, policies, and saved settings in the UI. - Edit discovered services and their inline policies in Docker labels. - A source badge or locked field identifies a setting controlled outside the UI. - Do not recreate a label-owned resource in the UI to work around ownership. ## UI Save the change, read any validation result, and check its apply badge. If the change is staged and automatic apply is off, open **Services**, select the relevant service, and choose **Apply**. ## Cloud integration, error reporting, and installation ID Open **Settings → Cloud** to review the installation ID and connection status. **Cloud integration** is the master switch and defaults to off. Enabling it permits automatic enrollment and reveals **Health reporting**, **Error reporting**, **WAF ruleset updates**, and **Cloud Protection**. Each optional feature has its own choice; connecting does not enable health or error reporting. Cloud Protection is coming later for Community, Business and Enterprise and cannot yet be enabled. Cloud records the public IP address that each signed installation request arrives from, whatever the Telemetry choice. It keeps only the latest address and clears it 30 days after it was last seen. Behind NAT, that address belongs to your network rather than this host. Clearplane operators can see it, and so can the members of an organization the installation is linked to. While Cloud integration is on, Core sends a signed presence heartbeat about every 30 seconds. It contains the installation ID through the credential and the running Clearplane release; Cloud records its own receipt time. This small operational heartbeat is independent of Health reporting, so turning optional health off does not make a running gateway appear offline. **Health reporting** is off by default. When enabled locally and accepted by the linked organization, the gateway sends one attributable sample about every 30 seconds. Host fields are uptime, CPU, used/total memory and used/total space on the configured data volume. Core, Edge, UI and Container proxy each report availability, uptime, CPU and used/total memory. Clearplane does not send hostnames, local addresses, paths, process lists, arbitrary containers, routes, request or response data, traffic counts, WAF detections, credentials or free text. Cloud keeps Community and unlinked health for 7 days, Business for 30 days and Enterprise for 90 days. Health reporting does not create alerts. Turning **Health reporting** off stops new local collection and upload but keeps retained Cloud data until its plan retention deadline. Its confirmation offers **Also clear retained Cloud health data**, unchecked by default. **Clear health data** is also available as a separate destructive action in Settings. A clear request is saved locally before Cloud is contacted and is retried after failures or restarts until acknowledged, even if the same settings save turned Cloud integration off. An organization owner can independently stop or resume Cloud ingestion and clear retained data from the installation page. **Error reporting** sends diagnostic metadata from the Core, Edge, UI host and ContainerProxy server processes. Each report contains an event UUID, time, component, release, exception type, SHA-256 message-template hash and up to 16 type/method names. It excludes message text, exception messages, file paths, request properties, credentials and raw logs. Reports are associated with a persistent instance identity and are pseudonymous, not anonymous. Core collects only events that occurred after the current error-reporting opt-in. Local diagnostic metadata remains in ordinary local logs under the configured log-retention policy. Turning Error reporting off and saving discards its pending queue and prevents further uploads. Turning Cloud integration off also clears feature selections and stops Cloud connections. Already accepted Cloud reports follow the 30-day retention policy. A stale settings form is rejected; no Edge apply or restart is needed. **WAF ruleset updates** is off by default. [Cloud ruleset updates](/docs/security/waf-rulesets/#cloud-ruleset-updates) describes checks, verification and activation. The manifest request sends the running Clearplane version, even when Telemetry is off. No traffic, route or detection data is sent. **Default update strategy** decides what a new release does: **Manual** only installs it, **Detection** (the default) activates it in Detection, and **Prevention** activates it in Prevention. Under Prevention, a ruleset that Cloud adds later blocks immediately. Turning Cloud integration off also turns updates off; installed rulesets stay active. The **Installation ID** is a random UUID generated once per installation database. It stays unchanged across restarts, upgrades and consent changes. Settings readers can view and copy it; the API cannot change it. Its value grants no authority. Enabling Cloud creates an ECDSA P-256 private key under Core's persistent data directory at `secrets/cloud/.key`. Back up the database and keys together. A previously connected installation with a missing or invalid key fails closed; contact the Cloud operator for credential rotation rather than deleting the identity. Copying a database and key copies that identity and must not be used to provision independent installations. Core uses `https://cloud.clearplane.net/api/` for enrollment, token exchange, signed uploads and ruleset downloads. Access tokens carry `installation:read installation:claim errors:write rulesets:read telemetry:write`; release downloads stay under that HTTPS base and do not follow redirects. No internal mTLS client certificates are sent to Cloud. Enrollment stores the installation ID and public key; a hash of the observed IPv4 /24 or IPv6 /64 network is retained for 24 hours to enforce a five-new-instances-per-network quota. Contact the Cloud operator if this enrollment limit prevents connecting a fleet. Cloud outages leave local protection available. Cloud serves Community rulesets to enrolled installations without a customer account. Cloud stores the last successful manifest request time and the latest downloaded version and download time for each ruleset, associated with the installation ID. A download does not establish that the release was activated. These records remain with the installation; its deletion removes them. Cloud does not store the Clearplane version sent in the manifest query or any traffic, route or detection content from update requests. The operator API exposes `GET /api/privacy-configuration` with `Settings.Read` and `PUT /api/privacy-configuration` with `Settings.Write`, through the authenticated Edge boundary. Submit the returned `updatedAt`, feature flags and update strategy when saving. The PUT changes preferences only and never infers data deletion. `DELETE /api/cloud/telemetry` with `Settings.Write` explicitly requests clearing and returns the refreshed state. Identity, Cloud acceptance and connection status are read-only. ### Link an installation to your organization Enrollment works without a Cloud account. To view this gateway in your organization's Cloud workspace: 1. In the gateway's **Settings → Cloud**, enable and save Cloud integration, wait for a connection and copy the installation ID. 2. Sign in to Clearplane Cloud as an organization owner. Open **Installations → Connect an installation**, paste the installation ID and create a claim code. 3. Paste that code into **Claim code** under **Organization** in the gateway's Cloud settings. Select **Link**, verify the organization name and select **Confirm organization**. This requires local settings write permission. Once linked, the gateway shows the organization there instead of the claim code. 4. Return to Cloud's **Installations** page. Organization members can view linked installations, retained health samples and WAF delivery details. Customer error-report browsing remains in development. To unlink from the gateway, open **Settings → Cloud → Organization** and select **Unlink**. This requires local settings write permission. An organization owner can instead open the installation in Cloud and select **Remove installation**. Organization members lose access as soon as it is unlinked. The installation keeps its Cloud identity and can be linked again with a new claim code. A claim code expires after ten minutes and applies only to the specified installation and organization. Creating another code replaces the organization's previous one. The gateway signs the request with its existing private key; never paste that key into Cloud. If confirmation is interrupted, retry the same code or check the Cloud installation list before generating another. Linking preserves the installation identity, credentials and existing history. It does not change reporting choices or enable remote management. Turning Cloud off stops further gateway requests; it does not remove the organization link or erase previously accepted data. Ownership transfer and deletion are not available yet. Local operator endpoints are `POST /api/cloud/claim/preview` and `POST /api/cloud/claim`; both require `Settings.Write`, a completed installation, a prior Cloud connection and currently enabled Cloud integration. The confirmation includes the organization ID returned by the preview. ## Docker labels Change the application or Clearplane-container label at its source. Wait for discovery or settings reconciliation, then check the UI for the effective value and source. For discovered routes, the automatic-apply setting controls whether a valid change is published immediately. Use the [configuration catalog](/docs/configuration/catalog/) to check whether a setting is Immediate, Validated, Apply required, or Restart required. ## Verify Confirm the effective value and source in the UI. Then test the behavior the setting controls; a successful save alone does not prove that staged or restart-required work is active. ================================================================================ DOCUMENT: Operations Human URL: /docs/operations/ ================================================================================ Use these pages after a service is published: - [Review status, traffic, and security events](status-traffic-security/) connects the Dashboard, Analytics, Services, and Logs. - [Change and apply configuration](change-apply-configuration/) explains ownership, validation, apply modes, and verification. - [Troubleshoot a service](troubleshoot-service/) starts with the symptom and ends with an observable check. [Installation](../get-started/) covers the Docker Compose lifecycle and updates. The [CLI reference](../cli/) covers application status, setup, administrator recovery, bans, database maintenance, and secret rotation. ================================================================================ DOCUMENT: Review status, traffic, and security events Human URL: /docs/operations/status-traffic-security/ ================================================================================ Start broad, select the affected route, then move to detailed events. ## Dashboard Use the Dashboard for current service health, traffic totals, resource use, and items that need attention. A warning here identifies the next surface to inspect; it is not a replacement for Logs. ## Analytics Select the affected route and time range. Review traffic over time, request outcomes, latency, block sources, and targeted routes. Analytics shows the pattern; it does not contain every event detail. Bot-challenge pages use the **Challenge** block source. WAF-triggered challenges appear in Detections as **Challenged**; rate-limit challenges do not create WAF evaluations. Enter a local start and end date-time to query any interval for which data still exists. The Dashboard keeps its fixed 24-hour operational view. ### Analytics retention Configure retention in **System → Settings → Analytics** or with the Core labels in the [configuration catalog](/docs/configuration/catalog/#core-directives). Changes take effect on the next analytics retention job. Saving does not prune immediately. Decreasing retention permanently deletes data outside the new window when the job runs; increasing retention cannot restore already-pruned data. Longer retention can substantially increase disk use, especially for path and blocked-IP rollups whose distinct values can grow with incoming traffic. ## Services Use Services to confirm that the Clearplane components are online, inspect resource use, review pending restart settings, and apply staged configuration when required. Under **ContainerProxy**, check whether discovery is reconciling normally and open a container's status icon to inspect its accepted state, failures, every unrecognized label, and warnings. ## Logs Filter by route first, then narrow by service, type, level, host, source address, status, or elapsed time. Use live mode only after the historical filter identifies the event shape you need. When indexing is catching up, the page shows that status; recent events may appear after the next refresh. Use **Previous** and **Next** to move through results. **Refresh** returns to the newest matching entries. Choose **Count matching logs** when you need an exact total for the current filters. Counting is separate from browsing and can take longer for broad filters or millions of entries. Narrow the route and time range to reduce the work. ### Clear logs Choose **Clear logs**, select the cutoff, and submit to queue a background operation. The dialog shows its progress, deleted counts, and completion result. You can close it and reopen **Clear logs** to check the operation later; pending work resumes after a Core restart. Clearing permanently deletes entries covered by the selected cutoff across every route, service, and log type, regardless of the page filters. Detection records covered by the same cutoff are deleted with them. Today's and yesterday's raw files are kept because services may still be writing to them; their eligible indexed entries are still cleared. Disk space is reclaimed in the background. A large clear can take time to finish even though the request is accepted immediately. ### Scheduled retention Use **System settings → Logs** to review the effective retention settings and what controls them. Indexed retention covers detection records as well as log entries. Review the **Log retention** job's schedule and run history under **Observability → Background jobs**. ## Background jobs Open **Observability → Background jobs** to review run status, results, and logs. When a running Core process cancels a job, the run is marked **Done** with a **Failure** result and a cancellation message in its log. Check the message before retrying. A forced process termination can prevent that final update. ## Verify Confirm the same route and time window across Dashboard or Analytics and Logs. The high-level count and detailed events should describe the same behavior. ================================================================================ DOCUMENT: Troubleshoot a service Human URL: /docs/operations/troubleshoot-service/ ================================================================================ Select the affected route and reproduce one request before changing configuration. ## Symptom: the management UI reports System unreachable The UI opens **System unreachable** when a management API request cannot connect, times out, or returns an unavailable gateway response. It checks reachability automatically; use **Retry** to check sooner. Check the Core and Edge containers, their logs, and the network path to the management hostname. After the API responds again, the UI returns to the previous page. ## Symptom: the route is missing **Checks** - For a UI-owned route, open **Proxy routes** and confirm it was saved. - For a label-owned route, open **Services → ContainerProxy**, confirm discovery is reconciling normally, and select the container's status icon. - Fix every unrecognized label, warning, validation failure, or ownership conflict shown in the status dialog, then check Logs for the matching reconciliation event. **Resolution** Fix the route in its owning source. Do not create a second UI route for a label-owned service. **Verify** Confirm one route exists for the hostname and it names the expected cluster. ## Symptom: the route returns an upstream error **Checks** - Open **Upstream destinations** and **Upstream clusters** for the selected route. - Confirm the destination address, scheme, port, health, and cluster membership. - Filter Logs by route and status to separate connection failures, timeouts, and upstream responses. **Resolution** Correct the destination or restore upstream reachability. Keep proxy error handling enabled while diagnosing so clients receive a bounded response. **Verify** Send a normal request and confirm the expected upstream response appears in Logs. ## Symptom: HTTPS is unavailable or does not redirect **Checks** - Open **Certificates** and confirm an Active certificate covers the exact hostname. - Confirm the hostname resolves to Clearplane. - For HTTP validation, confirm upstream systems do not cache, redirect, or rewrite the validation path. - Confirm the route enables the HTTP-to-HTTPS redirect. **Resolution** Restore validation reachability or use DNS validation, wait for the certificate to become Active, then enable the redirect. **Verify** Confirm the browser trusts the HTTPS URL, then confirm the HTTP URL redirects to it. ## Symptom: an expected request is blocked **Checks** - Filter Logs by route, source address, and status. - Use Analytics to identify the block source. - Open **Bans** to inspect the active record, source policy, reason, and expiry. - Inspect the route's policy states and its auto-ban, access control, authentication and rate limit policies. **Resolution** Make the narrowest change in the owning policy. For an automatic ban, correct the counted status codes, threshold, window, duration, or route scope before lifting the active ban. Shared public addresses may require a higher threshold or a narrower policy. **Verify** Repeat one expected request and one request that should still be blocked. Confirm both outcomes in Logs. ================================================================================ DOCUMENT: Container runtime isolation Human URL: /docs/security/container-runtime-isolation/ ================================================================================ The container-runtime socket is a host-level security boundary. A process with unrestricted access to it can usually control containers and reach sensitive host resources. Clearplane therefore does not mount the socket into Edge, Core, or UI. ## The ContainerProxy boundary ContainerProxy is the only Clearplane container that receives the runtime socket. It exposes read-only container-runtime operations for connectivity checks, container listings, and events, plus bounded resource telemetry and self-restart operations. Core reaches those internal operations over `clearplane-internal` using the exact Core client identity; the health endpoint accepts only ContainerProxy's own identity. ContainerProxy does not decide what labels mean or write Clearplane configuration. Core validates labels, resolves ownership, rejects ambiguous discovery candidates, and reconciles accepted resources. Edge receives only the resulting configuration revision. An invalid label candidate is reported without replacing the previous valid discovered resource graph. A transient runtime or ContainerProxy failure also leaves the last valid graph in place. This split means a compromise of the public Edge or management Core process does not directly provide the Docker socket. It also keeps container-runtime-specific code out of the routing and management components. ## Socket permissions Set `CLEARPLANE_CONTAINER_PROXY_SOCKET_PATH` for a nondefault local Unix socket. No host group-ID setting is needed. Clearplane does not change socket ownership, permissions, user-namespace mappings, or SELinux policy. A read-only socket bind does not make Docker's API read-only; ContainerProxy's allowlisted API supplies that boundary. The health check calls Docker's `/_ping`; blocked socket access fails health validation. If you explicitly configure a non-root container user, supply its socket access yourself, for example with a matching `group_add`. A rootless Docker daemon reduces the impact of a compromised runtime boundary. ## What the boundary does not promise ContainerProxy remains a high-trust component because it holds the socket. Its narrow API, read-only filesystem, dropped capabilities, and private network reduce exposure but cannot turn a compromised Docker host or daemon into a trusted environment. Operators still own host patching, Docker daemon access, volume permissions, and administrator access. Do not expose ContainerProxy or the runtime socket outside `clearplane-internal`. ================================================================================ DOCUMENT: Exposure and network boundaries Human URL: /docs/security/exposure-and-networks/ ================================================================================ In the supported topology, Edge is the only Clearplane container with host port mappings. Public HTTP reaches Edge on TCP port 80. Public HTTPS uses TCP port 443 for HTTP/1.1 and HTTP/2 and UDP port 443 for HTTP/3; Core, UI, and ContainerProxy publish no host ports. This remains true only while the deployment keeps those boundaries intact. Publishing an application or control-plane port separately creates another public path that Clearplane cannot protect. ## Network wiring | Network | Members | Purpose | |---|---|---| | `clearplane-internal` | Edge, Core, UI, ContainerProxy | Private control-plane communication over exact-identity mTLS on HTTPS 8443. The bridge is marked internal. | | `clearplane-services` | Edge and proxied application containers | Edge-to-application traffic. Core, UI, and ContainerProxy are not members. | | `clearplane-egress` | Core | Outbound control-plane traffic, including metrics and WAF event export, without attaching Core to application containers. | Joining `clearplane-services` does not publish a host port. To keep Edge as the only public request path, application containers join this network and do not publish their application ports to the host. ## Management exposure Management access also enters through Edge. When enabled, ordinary protected routes expose the browser UI and management API on the selected public host: - `/` routes to UI over `clearplane-internal`. - `/api/{**catch-all}` routes to Core and rewrites to `/external/{**catch-all}`. - `/api/ws/*` uses the same API route for browser event connections. - `/api/metrics` serves Prometheus metrics to a session with `Metrics.Read` or a scrape token. - `/internal/*` is not part of the public route contract. The UI and API therefore use the same public ingress and route controls as other services without exposing their containers directly. Browser and API clients use the `HttpOnly`, `SameSite=Strict` session cookie issued by the external sign-in endpoint. API clients keep that cookie in a cookie jar and send the fixed CSRF header on unsafe requests; the sign-in response contains session status and expiry, not a bearer token. A sign-in session expires 24 hours after it is created; activity and dashboard refreshes do not extend it. Closing the browser can also end the browser session. ## Management route defaults Core and UI use ordinary `clearplane.proxy.*` labels and the same policy pipeline as application routes. The shipped routes and their configuration resources appear in the **System** resource group. The shipped Compose file gives both containers one YAML anchor, `x-clearplane-management-labels`, whose labels create each route's own access control, rate limit (600 requests per minute), automatic ban, request headers and response headers policies, a Detection WAF policy with the Management profile, and branded 403/502/503/504 error pages; caching is off. Access control defaults to **Block** and allows only `CLEARPLANE_MANAGEMENT_ALLOW_ADDRESSES`, so set it to your administrator address or narrow VPN CIDR before browser access. If the allow-list admits a private range broader than a /24, discovery warns that it can cover Docker's default address pools. To change another management policy, override its label on both containers. When an enabled management route accepts every address, the Dashboard and **Proxy routes** show **Management routes have no address restriction** and name the affected routes. A route's own policies replace global ones, so the warning clears only when a policy that applies to that route defaults to **Block**; a removed assignment, a disabled policy, or an allow-by-default policy leaves the route unrestricted. For a route mistake, inspect **Proxy routes**, **Upstream clusters**, **Certificates**, their policies, and discovery diagnostics. Edit Docker labels for label-owned resources and use the UI/API for API-owned resources. Management routes follow the ordinary [ownership rules](/docs/concepts/configuration-ownership/); there is no separate management-route reset command. Setup and account recovery are covered by [Installation](/docs/get-started/) and [CLI](/docs/cli/). ## Outbound exports Core can send optional WAF metrics over OTLP and WAF events to syslog over TLS, signed HTTPS webhooks and OTLP logs. Every new connection checks the resolved address against the global restricted destination classes and always refuses the control-plane network. Redirects and system proxy routing are disabled. Export credentials are encrypted at rest; list responses never expose them. Configure destinations with `Observability.Manage` in **System → Settings → Observability**. See [Export metrics and WAF events](/docs/guides/export-metrics-and-waf-events/) for token handling, formats, filters and retention limits. ## Preserve the boundary Apply the [hardening checklist](/docs/security/hardening-checklist/#public-exposure) to keep these boundaries intact. See [Architecture](/architecture/) for the full runtime topology. ================================================================================ DOCUMENT: Hardening checklist Human URL: /docs/security/hardening-checklist/ ================================================================================ Use layered controls. Configure them through the UI or Docker labels according to resource ownership; both paths are first-class and produce the same Edge behavior. ## Public exposure - Expose only Edge on the intended HTTP and HTTPS ports. - Keep application containers private on `clearplane-services` without host port mappings. - Keep Core, UI, ContainerProxy, and `/internal/*` private. - Do not attach control-plane containers to additional application or public networks. - Restrict host, Docker daemon, and deployment access to trusted administrators. ## Management access - Limit the management routes to trusted source addresses or countries with access control. - Apply a rate limit policy to slow repeated requests before they exhaust application capacity. - Enable automatic bans for repeated violations and abusive 4xx behavior. - Use strong administrator credentials and grant only the permissions each operator needs. Automatic bans complement access control and rate limiting. They react to observed behavior and apply a temporary IP ban across Clearplane; they are not a substitute for fixing an exposed application or leaked credential. ## Published services - Enable HTTPS and redirect HTTP only after the certificate is active. - Assign access control and rate limit policies based on the service's audience and capacity. - Configure auto-ban thresholds from observed normal traffic, then review security events for false positives. - Apply response headers policies that match the application, including transport, framing, content-type, referrer, permissions, and server-header controls. - Keep upstream applications authenticated, patched, and private even when Edge supplies the public route. Use [Configure access, traffic, and delivery](/docs/guides/access-traffic-delivery/) for equal UI and Docker-label workflows, [Ban abusive clients automatically](/docs/guides/protect-service/) for behavior-based protection, and [Reference](/docs/configuration/) for exact settings. ## Change safely - Start route-scoped when testing a new policy. For policy families that support global scope, move to global only when the same behavior belongs on every unassigned route. - Verify the effective source, apply state, and loaded configuration revision after a change. - Test allowed traffic, blocked traffic, and upstream failure behavior—not only a successful save. - Keep recovery material and operational data protected using your host platform's backup and access-control procedures. ================================================================================ DOCUMENT: Security & Trust Human URL: /docs/security/ ================================================================================ Clearplane narrows public exposure, separates control-plane and application traffic, and authenticates communication between its own services. These boundaries reduce the impact of a compromised component; they do not replace host, container-runtime, application, or operational security. - [Exposure and network boundaries](exposure-and-networks/) explains why Edge is the only public Clearplane container and how the three networks are wired. - [Internal service trust](internal-service-trust/) explains exact-identity mTLS between Edge, Core, UI, and ContainerProxy. - [Container runtime isolation](container-runtime-isolation/) explains why only ContainerProxy receives the runtime socket. - [Unsigned local rules](internal-service-trust/#unsigned-local-rules) explains how custom rules reach Edge over Core's authenticated channel. - [Review WAF detections](waf-detections/) explains how to read what the WAF matched, what Edge redacts before recording a detection, and how to narrow a noisy rule before enabling Prevention. - [Use WAF exclusion rulesets](waf-exclusion-rulesets/) explains how routes opt into an application's exclusions without per-route tuning. - [WAF inspected traffic](waf-inspected-traffic/) covers WebSocket messages, binary gRPC streams and bodies above the inspection limit. - [WAF rulesets](waf-rulesets/) explains WAF policies, signed releases, stages, opt-outs, and rollback. - [WAF scoring and paranoia levels](waf-scoring-and-paranoia/) explains combined thresholds, independent ruleset thresholds, and detection-only scores. - [Bot challenges](/docs/guides/bot-challenges/) explains what a challenge clearance binds and how rotating its key invalidates clearances. - [Hardening checklist](hardening-checklist/) turns the model into practical operator checks without treating one control as complete protection. - [WAF protection coverage](waf-coverage/) reports measured detection and false-positive rates for the tested category rulesets. - [WAF rule language](../waf-reference/) explains the format, targets, operators, detectors and integrity tests. - [Third-party notices](third-party-notices/) lists the third-party work Clearplane includes and reproduces its licence text. For suspected vulnerabilities in Clearplane itself, use the private [security reporting channel](/security/). ================================================================================ DOCUMENT: Internal service trust Human URL: /docs/security/internal-service-trust/ ================================================================================ Every Clearplane-to-Clearplane connection on `clearplane-internal` uses HTTPS 8443 with mutual TLS. Both sides authenticate the connection; network membership alone is not enough. ## Exact service identity Core generates a private root and a matched certificate generation for Edge, Core, UI, and ContainerProxy. Each service certificate carries an exact Clearplane service identity. A caller must present the identity allowed by the endpoint, and the server certificate must match the service the caller intended to reach. Clearplane validates this private chain without adding the root to the host operating system trust store. It has no plaintext, permissive-certificate, workload-password, or bearer-token fallback for internal service traffic. ## Certificate distribution Core writes the matched internal certificate material to the service data volumes. Edge, UI, and ContainerProxy each mount only their own service data volume read-only; Core retains the writer role. Missing, malformed, mismatched, symlinked, or incorrectly permissioned material fails closed instead of weakening validation. Treat these volumes as one certificate generation. Copying one service's certificate material into another service breaks the identity relationship rather than granting a generic internal credential. ## Separation from upstream traffic Internal client certificates stay on `clearplane-internal`. Edge does not forward its Clearplane service identity to applications on `clearplane-services`, and customer upstreams cannot become trusted internal peers by presenting a hostname or label. This separation protects the control-plane trust domain from the applications it proxies. It does not authenticate the application protocol itself; use the upstream application's own authentication and transport controls where needed. ## Unsigned local rules Only a ruleset in the reserved local namespace — the identifier `local`, or one starting with `local-` — may be unsigned. Edge accepts its definition from Core over the exact-identity mTLS channel, checks its content hash and compiles it before activation. An unsigned definition cannot replace a signed Cloud ruleset. Operators [write and test custom rules](/docs/guides/write-custom-waf-rules/) in a saved draft. Publishing requires the management permission and passing integrity tests; saving a draft alone never changes Edge's rules. ================================================================================ DOCUMENT: Third-party notices Human URL: /docs/security/third-party-notices/ ================================================================================ Clearplane includes the following third-party work. Each section names the source, what Clearplane uses, and the licence text the licence requires Clearplane to reproduce. ## OWASP Core Rule Set Clearplane's shipped WAF rulesets adapt OWASP CRS `v4.29.0`, commit `ab3ccd5fcd691424ba3f320d4040c61417270193`, for 517 of their rules and exclusions. Source: . Licence: Apache-2.0. Copyright (c) 2006–2020 Trustwave and contributors. All rights reserved. Copyright (c) 2021–2026 CRS project. All rights reserved. The candidate changes rule representation, splits some rules across stages, and records native-runtime policy adaptations and source identities in conversion provenance. Rules backed by unconfirmed GPL-derived shell lists are omitted and reported. Each derived rule records the upstream file and line it came from, and carries `Apache-2.0` as its own licence, so the attribution travels with the rule — including into an operator's custom ruleset when they copy a rule as a starting point. A draft that takes on such a rule restates its own licence to name the material it now includes. The CRS exclusion plugins below ship adapted the same way, under the same licence: | Plugin | Version | Commit | |---|---|---| | `wordpress-rule-exclusions-plugin` | 1.2.0 | `c97e42a088fbb85b3a59a2ecf686abd9752badf8` | | `nextcloud-rule-exclusions-plugin` | 1.7.1 | `d907a20c7ca9c27d5666185c8ffab58f859d4832` | | `phpmyadmin-rule-exclusions-plugin` | 1.1.0 | `9769ff0f2192137c2a9d715ad60cfacee9882edc` | The complete upstream licence is available at [OWASP CRS licence](/notices/owasp-crs-LICENSE.txt). ## libinjection Source: , tag `v4.0.0`, commit `211782219663f889f471650150df12b623c5766e`. Licence: BSD-3-Clause. Clearplane contains a C# port of libinjection's SQLi and HTML5/XSS algorithms in `Shared/Clearplane.Shared.Servers/src/Waf/Tokenizers/Libinjection/`. Its keyword table, fingerprint list and detection tables ship as WAF ruleset data rather than code. The upstream test vectors are vendored under `Tests/Unit/Clearplane.Tests.Unit.Waf/Fixtures/Libinjection/v4.0.0/`. The CRS converter carries the pinned keyword and fingerprint tables with source hashes and the upstream licence in `Tools/Clearplane.WafCrsConverter/Content/Libinjection/` to include them in generated ruleset drafts. ```text Copyright (c) 2012-2016, Nick Galbreath Copyright (c) 2017-2024, libinjection Contributors All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. https://github.com/libinjection/libinjection http://opensource.org/licenses/BSD-3-Clause ``` ## CodeMirror Clearplane bundles CodeMirror 6 and its runtime dependencies for the custom WAF rule editor. Source: . Licence: MIT. Exact package versions and dependency hashes are recorded in `Clearplane.UI/codemirror/package.json` and `package-lock.json`. Complete copyright and licence texts for every bundled package are included with the browser asset at `Clearplane.UI/wwwroot/lib/codemirror/LICENSE`. ## Corvus.JsonSchema Clearplane uses Corvus.Json.Validator and its code-generation packages, version `5.5.5`. Source: , commit `1a6b992ce6b77b209f4a9a6740f0e6a668e5cd15`. Copyright (c) Endjin Limited 2023. All rights reserved. Licence: Apache-2.0. The runtime adapter uses the public generator APIs with a local-only document resolver, bounded non-backtracking regex generation and collectible compilation assemblies. The complete licence is in `Shared/Clearplane.Shared.Servers/ThirdParty/Corvus.JsonSchema.LICENSE.txt`, copied into Core and Edge publish output. ## Microsoft.OpenApi Core uses Microsoft.OpenApi and Microsoft.OpenApi.YamlReader, version `3.10.2`. Source: , commit `c3e9fad2fb3191ca0cb96aa4265c65df38ebad67`. Copyright (c) Microsoft Corporation. All rights reserved. Licence: MIT. The complete licence is in `Clearplane.Core/ThirdParty/Microsoft.OpenApi.LICENSE.txt`, copied into Core publish output. ## OpenTelemetry Core uses OpenTelemetry.Extensions.Hosting and OpenTelemetry.Exporter.OpenTelemetryProtocol version `1.18.0`, plus OpenTelemetry.Exporter.Prometheus.AspNetCore version `1.18.0-beta.1`, for optional WAF metrics export. Copyright The OpenTelemetry Authors. Licence: Apache-2.0. Source: , stable commit `9db92a4e978b4ae432183c790259be48a475578f` and Prometheus commit `45349c1b2e0ba8e60105e664abf0d0d0c56b6324`. The complete licence is in `Clearplane.Core/ThirdParty/OpenTelemetry.LICENSE.txt`, copied into Core publish output. ================================================================================ DOCUMENT: API schema ruleset Human URL: /docs/security/waf-api-schema/ ================================================================================ `clearplane-api-schema` supplies a rule for each supported API-schema violation kind. Attach an API schema to the route's [WAF policy](/docs/guides/validate-api-schemas/) and enable validation: activating this ruleset alone does not select a schema. Validation results become scores; the policy mode and ruleset stages determine whether they can block. ## Paranoia levels and compatibility An outdated schema can reject a legitimate client. Check required parameters, types, formats, request media types and additional-property rules against actual API traffic. Start in Detection, review [detections](/docs/security/waf-detections/), and configure only the [exclusions](/docs/security/waf-exclusion-rulesets/) needed for the affected route and field. See the [measured coverage](/docs/security/waf-coverage/) for the exact tested payload hashes, missed detections and false-positive rates. [Ruleset operation](/docs/security/waf-rulesets/) explains activation, stages and rollback. ================================================================================ DOCUMENT: Command injection ruleset Human URL: /docs/security/waf-command-injection/ ================================================================================ `clearplane-command-injection` combines converted command signatures with level-2 checks for shell separators, substitutions, server-side include execution syntax and exact Unix shell interpreter references. ## Paranoia levels and compatibility Shell documentation, command editors and template authoring can legitimately contain these constructs. Review level-2 findings before promotion. The upstream shell word list still has unresolved licensing and is not included; see [third-party notices](/docs/security/third-party-notices/). Start in Detection, review [detections](/docs/security/waf-detections/), and configure only the [exclusions](/docs/security/waf-exclusion-rulesets/) needed for the affected route and field. See the [measured coverage](/docs/security/waf-coverage/) for the exact tested payload hashes, missed detections and false-positive rates. [Ruleset operation](/docs/security/waf-rulesets/) explains activation, stages and rollback. ================================================================================ DOCUMENT: WAF protection coverage Human URL: /docs/security/waf-coverage/ ================================================================================ Measured 2026-09-17 by the coverage library on Clearplane 1.0.0-alpha4. CRS source: OWASP CRS v4.29.0 (commit ab3ccd5fcd691424ba3f320d4040c61417270193). The report measures request replays and any explicitly configured response or API-schema traffic cases. It does not establish coverage for streamed WebSocket or gRPC messages, live application behavior, or browser challenges. It measures only the listed ruleset inputs; it does not establish which Cloud releases are available or which releases a gateway runs. ## Application exclusion policy The following route opt-ins apply to every attack and benign case from the named source. Other traffic sources and the generic CRS regression suite use the default policy. Source classifications, request bytes and denominators are preserved. | Vendored source | Opted-in exclusion rulesets | |---|---| | crs-plugin-nextcloud | clearplane-exclusions-nextcloud-core | | crs-plugin-phpmyadmin | clearplane-exclusions-phpmyadmin-core | | crs-plugin-wordpress | clearplane-exclusions-wordpress-core | The following route settings allow additional methods or request content types for every case from the named source, the way an operator configures the route that serves that application or harness. | Vendored source | Additional allowed methods | Additional request content types | |---|---|---| | crs-responses | — | text/plain, text/html | ## Adapted CRS expectations The following approved corrections for platform behavior and Clearplane default policy apply only to pinned requests and their original expectations. The cases are replayed and must satisfy the Clearplane expectation; they are not skipped. Numerical targets, request bytes and independent traffic classifications remain unchanged. Expected-ID and no-expect subtotals reflect the effective expectations. Original expectations and observed source-rule IDs remain recorded below and in the JSON report. | Test | Request SHA-256 | Original expected IDs | Original prohibited IDs | Clearplane expected IDs | Clearplane prohibited IDs | Observed IDs | Reason | |---|---|---|---|---|---|---|---| | 911100-6 | 56900fb52bc723a3d69e8eb4b9983e378f1d0d71aa071317939f74cacecdffad | 911100 | | | 911100 | | Clearplane's default method policy allows PUT, PATCH and DELETE in addition to the CRS defaults, as approved on 2026-09-16 for REST applications. This exact DELETE request must not match rule 911100; methods outside the default list still do. Request bytes and numerical targets are unchanged. | | 920620-1 | aa6a485905c86602489c4fda4af8b156699c5906e979accc6d42cb633261efe8 | | 920620 | 920620 | | 920620 | The pinned CRS fixture expects Apache httpd to combine two Content-Type headers. Clearplane preserves both headers and must detect the duplicate with rule 920620. Only this exact request and original expectation are adapted; request bytes, detection policy and numerical targets are unchanged. | | 953101-1 | 18bcab03e79330a236fbce3e4ee95ed5f171a489f74c3bf9291ceeb136c846de | 953101 | | | 953101 | | The pinned CRS fixture expects ordinary validation prose to match PHP data-leakage rule 953101. The same text is a benign response control. Clearplane reports a PHP leak only with PHP diagnostic context, as approved on 2026-09-16, so this exact response must not match. Response bytes and numerical targets are unchanged. | | 953101-2 | bce85898c40e3fcaf63e0dec397c028f97a0316c078c8eef78d93628c74aebe6 | 953101 | | | 953101 | | The pinned CRS fixture expects ordinary validation prose to match PHP data-leakage rule 953101. The same text is a benign response control. Clearplane reports a PHP leak only with PHP diagnostic context, as approved on 2026-09-16, so this exact response must not match. Response bytes and numerical targets are unchanged. | | 953101-3 | 74325df4202cb996c9555d5fe9ba68618743f244594cbf774c1162eb752b9ee9 | 953101 | | | 953101 | | The pinned CRS fixture expects ordinary validation prose to match PHP data-leakage rule 953101. The same text is a benign response control. Clearplane reports a PHP leak only with PHP diagnostic context, as approved on 2026-09-16, so this exact response must not match. Response bytes and numerical targets are unchanged. | | 953101-4 | 32dc0ed5b14f7a18167274c3fe673cebe21ada024935adc1a8dd2f75fa25b91a | 953101 | | | 953101 | | The pinned CRS fixture expects ordinary validation prose to match PHP data-leakage rule 953101. The same text is a benign response control. Clearplane reports a PHP leak only with PHP diagnostic context, as approved on 2026-09-16, so this exact response must not match. Response bytes and numerical targets are unchanged. | | 953101-5 | e693093d7808c40448ab453f6f598efc43ff896a7655e0502130b230fd3f40f8 | 953101 | | | 953101 | | The pinned CRS fixture expects ordinary validation prose to match PHP data-leakage rule 953101. The same text is a benign response control. Clearplane reports a PHP leak only with PHP diagnostic context, as approved on 2026-09-16, so this exact response must not match. Response bytes and numerical targets are unchanged. | ## Rulesets | Ruleset | Version | Payload SHA-256 | |---|---|---| | clearplane-api-schema | 1.0.0 | a75b066588c7bcc5c38f89857edf738f5cfbbbe3c48cff28b42fee0350b39ace | | clearplane-command-injection | 0.0.0 | 93d8a51abfbedc87c0d028651b75f9415bcc75b277e0783f45ea4c379af4e0e2 | | clearplane-data-leakage | 0.0.0 | a0f94b9b65c884d1590a95979531f3ae7da86764cd644b06688d62d390821d80 | | clearplane-exclusions-nextcloud-core | 1.0.0 | 229e667485a7d617cbdb3cad808b6137d20dbcc883e68a77d7b53163f8288d3d | | clearplane-exclusions-phpmyadmin-core | 1.0.0 | 3fe608ec0bb2f2765360613e63ab71cf7807ea3e98d47c909a34c6fc55099c58 | | clearplane-exclusions-wordpress-core | 1.0.0 | 259cf38678b35cbbd5889b96ec5487d070e1b37ebc98c1a93dc99a18f5a5e799 | | clearplane-path-traversal | 0.0.0 | 23a8e38cd274eec4d7d71e635628e418304e2ea7f19ec5fcb58125a4ec1dbb27 | | clearplane-protocol | 0.0.0 | 9d7901ad8eb68e530aeed29c636443e3fbcbd16b789a527fd0703c4502ff72d6 | | clearplane-scanners | 0.0.0 | a2f84dad83bde304c35d7397c3eeae8c14eedf1832c13e12324904974330ce5c | | clearplane-sql-injection | 0.0.0 | 835ee29f5bbf676e4eb8df8742499b40aa58c440a21a5e54aab1625e8e954f17 | | clearplane-xss | 0.0.0 | a61274f2a0285a78848090be478f9d084188d5973a95c5057eeef4f8966a3ede | ## Categories Targets apply to CRS source levels 1–2 and attack runs at levels 1–2. Levels 3–4 are reported without targets. “Met” requires measured CRS category or attack coverage, measured benign results at both levels 1 and 2, complete evaluation of that category's CRS/attack cases and every benign case at both targeted levels, and no failed target. CRS tests containing only prohibited-ID expectations are benign for this completeness check. Incomplete evidence is “Not measured” unless a measured target failed, which is “Not met”. Unmeasured targets remain unmeasured. Counts and percentages below are taken from the report. | Category | Status | CRS category PL1–2 | CRS strict PL1–2 | CRS no-expect PL1–2 | Attack traffic PL2 | Benign PL1 | Benign PL2 | |---|---|---|---|---|---|---|---| | api-schema | Met | not measured | not measured | not measured | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | command-injection | Met | 96.32 % (≥ 95.00 %) | 93.44 % (≥ 90.00 %) | 0 (≤ 0) | 95.65 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | data-leakage | Met | 100.00 % (≥ 95.00 %) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | deserialization | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | file-upload | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | generic-injection | Not met | 0.00 % (≥ 95.00 %) | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | not measured | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | graphql | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | java-injection | Not met | 0.00 % (≥ 95.00 %) | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | not measured | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | jwt | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | ldap-injection | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | nosql-injection | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | open-redirect | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | path-traversal | Met | 100.00 % (≥ 95.00 %) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | php-injection | Not met | 0.00 % (≥ 95.00 %) | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | protocol | Met | 95.56 % (≥ 95.00 %) | 94.81 % (≥ 90.00 %) | 0 (≤ 0) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | prototype-pollution | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | remote-file-inclusion | Not met | 0.00 % (≥ 95.00 %) | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | scanner | Met | 100.00 % (≥ 95.00 %) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | session-fixation | Not met | 0.00 % (≥ 95.00 %) | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | not measured | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | sql-injection | Met | 98.53 % (≥ 95.00 %) | 96.09 % (≥ 90.00 %) | 0 (≤ 0) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | ssrf | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | ssti | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | xpath-injection | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | xss | Met | 98.55 % (≥ 95.00 %) | 98.55 % (≥ 90.00 %) | 0 (≤ 0) | 100.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | | xxe | Not met | not measured | not measured | not measured | 0.00 % (≥ 90.00 %) | 0 (≤ 0) | 0.00 % (≤ 0.10 %) | CRS rows group and replay tests at the original CRS rule's paranoia level. Strict and category rates both divide by expected-ID tests, including unsupported expected IDs. Skipped tests are excluded. The platform-specific corrections above replace only their named expectations. Strict passes require the expected source rule IDs; category passes require a match in the expected category. No-expect false positives count tests that fired a prohibited source rule ID. Strict rates compare source rule identities, not just attack detection; a zero strict rate does not imply a zero category detection rate. Attack detection requires a match in the expected category. Category benign false positives require that category's request score to reach 5 or its response score to reach 4. Case totals count request cases, including placements of the same payload. Benign PL1 and CRS no-expect targets are counts; the other targets are rates. A dash means no denominator was measured. ### api-schema | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 259 | 259 | 100.00 % | 872 | 0 | 0.00 % | | 2 | 259 | 259 | 100.00 % | 872 | 0 | 0.00 % | | 3 | 259 | 259 | 100.00 % | 872 | 0 | 0.00 % | | 4 | 259 | 259 | 100.00 % | 872 | 0 | 0.00 % | ### command-injection | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 548 | 387 | 369 | 95.35 % | 376 | 97.16 % | 5 | 13 | 161 | 0 | | 2 | 335 | 238 | 215 | 90.34 % | 226 | 94.96 % | 6 | 17 | 97 | 0 | | 3 | 121 | 82 | 81 | 98.78 % | 82 | 100.00 % | 1 | 0 | 39 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 182 | 14 | 7.69 % | 872 | 0 | 0.00 % | | 2 | 184 | 176 | 95.65 % | 872 | 0 | 0.00 % | | 3 | 184 | 176 | 95.65 % | 872 | 59 | 6.77 % | | 4 | 184 | 176 | 95.65 % | 872 | 59 | 6.77 % | ### data-leakage | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 72 | 66 | 66 | 100.00 % | 66 | 100.00 % | 0 | 0 | 6 | 0 | | 2 | 11 | 5 | 5 | 100.00 % | 5 | 100.00 % | 0 | 0 | 6 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 71 | 66 | 92.96 % | 872 | 0 | 0.00 % | | 2 | 71 | 71 | 100.00 % | 872 | 0 | 0.00 % | | 3 | 71 | 71 | 100.00 % | 872 | 0 | 0.00 % | | 4 | 71 | 71 | 100.00 % | 872 | 0 | 0.00 % | ### deserialization | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 26 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 26 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 26 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 26 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### file-upload | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 29 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 29 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 29 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 29 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### generic-injection | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 132 | 117 | 0 | 0.00 % | 0 | 0.00 % | 0 | 117 | 15 | 0 | | 2 | 126 | 107 | 0 | 0.00 % | 0 | 0.00 % | 0 | 107 | 19 | 0 | | 3 | 13 | 9 | 0 | 0.00 % | 0 | 0.00 % | 0 | 9 | 4 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 0 | 0 | — | 872 | 0 | 0.00 % | | 2 | 0 | 0 | — | 872 | 0 | 0.00 % | | 3 | 0 | 0 | — | 872 | 0 | 0.00 % | | 4 | 0 | 0 | — | 872 | 0 | 0.00 % | ### graphql | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 5 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 5 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 5 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 5 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### java-injection | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 628 | 601 | 0 | 0.00 % | 0 | 0.00 % | 0 | 601 | 27 | 0 | | 2 | 189 | 183 | 0 | 0.00 % | 0 | 0.00 % | 0 | 183 | 6 | 0 | | 3 | 330 | 330 | 0 | 0.00 % | 0 | 0.00 % | 0 | 330 | 0 | 0 | | 4 | 26 | 26 | 0 | 0.00 % | 0 | 0.00 % | 0 | 26 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 0 | 0 | — | 872 | 0 | 0.00 % | | 2 | 0 | 0 | — | 872 | 0 | 0.00 % | | 3 | 0 | 0 | — | 872 | 0 | 0.00 % | | 4 | 0 | 0 | — | 872 | 0 | 0.00 % | ### jwt | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 2 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 2 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 2 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 2 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### ldap-injection | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 152 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 152 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 152 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 152 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### nosql-injection | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 93 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 93 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 93 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 93 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### open-redirect | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 271 | 0 | 0.00 % | 970 | 0 | 0.00 % | | 2 | 271 | 0 | 0.00 % | 970 | 0 | 0.00 % | | 3 | 271 | 0 | 0.00 % | 970 | 0 | 0.00 % | | 4 | 271 | 0 | 0.00 % | 970 | 0 | 0.00 % | ### path-traversal | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 72 | 57 | 57 | 100.00 % | 57 | 100.00 % | 0 | 0 | 15 | 0 | | 2 | 11 | 10 | 10 | 100.00 % | 10 | 100.00 % | 0 | 0 | 1 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 272 | 238 | 87.50 % | 872 | 0 | 0.00 % | | 2 | 272 | 272 | 100.00 % | 872 | 0 | 0.00 % | | 3 | 272 | 272 | 100.00 % | 872 | 0 | 0.00 % | | 4 | 272 | 272 | 100.00 % | 872 | 0 | 0.00 % | ### php-injection | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 349 | 261 | 0 | 0.00 % | 0 | 0.00 % | 0 | 261 | 88 | 0 | | 2 | 27 | 12 | 0 | 0.00 % | 0 | 0.00 % | 0 | 12 | 15 | 0 | | 3 | 49 | 39 | 0 | 0.00 % | 0 | 0.00 % | 0 | 39 | 10 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 9 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 9 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 9 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 9 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### protocol | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 388 | 218 | 205 | 94.04 % | 207 | 94.95 % | 2 | 11 | 170 | 0 | | 2 | 90 | 52 | 51 | 98.08 % | 51 | 98.08 % | 0 | 1 | 38 | 0 | | 3 | 32 | 15 | 13 | 86.67 % | 13 | 86.67 % | 0 | 2 | 17 | 0 | | 4 | 23 | 11 | 11 | 100.00 % | 11 | 100.00 % | 0 | 0 | 12 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 44 | 10 | 22.73 % | 872 | 0 | 0.00 % | | 2 | 45 | 45 | 100.00 % | 872 | 0 | 0.00 % | | 3 | 47 | 47 | 100.00 % | 872 | 97 | 11.12 % | | 4 | 48 | 48 | 100.00 % | 872 | 372 | 42.66 % | ### prototype-pollution | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 13 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 13 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 13 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 13 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### remote-file-inclusion | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 16 | 14 | 0 | 0.00 % | 0 | 0.00 % | 0 | 14 | 2 | 0 | | 2 | 25 | 22 | 0 | 0.00 % | 0 | 0.00 % | 0 | 22 | 3 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 0 | 0 | — | 872 | 0 | 0.00 % | | 2 | 1 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 1 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 1 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### scanner | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 7 | 5 | 5 | 100.00 % | 5 | 100.00 % | 0 | 0 | 2 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 8 | 8 | 100.00 % | 872 | 0 | 0.00 % | | 2 | 8 | 8 | 100.00 % | 872 | 0 | 0.00 % | | 3 | 8 | 8 | 100.00 % | 872 | 0 | 0.00 % | | 4 | 8 | 8 | 100.00 % | 872 | 0 | 0.00 % | ### session-fixation | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 47 | 42 | 0 | 0.00 % | 0 | 0.00 % | 0 | 42 | 5 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 0 | 0 | — | 872 | 0 | 0.00 % | | 2 | 0 | 0 | — | 872 | 0 | 0.00 % | | 3 | 0 | 0 | — | 872 | 0 | 0.00 % | | 4 | 0 | 0 | — | 872 | 0 | 0.00 % | ### sql-injection | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 373 | 322 | 320 | 99.38 % | 320 | 99.38 % | 2 | 0 | 51 | 0 | | 2 | 588 | 497 | 467 | 93.96 % | 487 | 97.99 % | 4 | 26 | 91 | 0 | | 3 | 50 | 39 | 38 | 97.44 % | 39 | 100.00 % | 1 | 0 | 11 | 0 | | 4 | 14 | 8 | 6 | 75.00 % | 6 | 75.00 % | 2 | 0 | 6 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 4 | 4 | 100.00 % | 872 | 0 | 0.00 % | | 2 | 4 | 4 | 100.00 % | 872 | 0 | 0.00 % | | 3 | 5 | 5 | 100.00 % | 872 | 15 | 1.72 % | | 4 | 5 | 5 | 100.00 % | 872 | 37 | 4.24 % | ### ssrf | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 53 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 53 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 53 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 53 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### ssti | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 214 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 214 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 214 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 214 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### xpath-injection | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 10 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 10 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 10 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 10 | 0 | 0.00 % | 872 | 0 | 0.00 % | ### xss | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 240 | 186 | 183 | 98.39 % | 183 | 98.39 % | 3 | 0 | 54 | 0 | | 2 | 21 | 21 | 21 | 100.00 % | 21 | 100.00 % | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 149 | 120 | 80.54 % | 872 | 0 | 0.00 % | | 2 | 149 | 149 | 100.00 % | 872 | 0 | 0.00 % | | 3 | 149 | 149 | 100.00 % | 872 | 0 | 0.00 % | | 4 | 149 | 149 | 100.00 % | 872 | 0 | 0.00 % | ### xxe | CRS source PL | Tests | Expected-ID tests | Strict passed | Strict rate | Category passed | Category rate | Failed | Unsupported | No-expect tests | False positives | |---|---|---|---|---|---|---|---|---|---|---| | 1 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 2 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 3 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | 4 | 0 | 0 | 0 | — | 0 | — | 0 | 0 | 0 | 0 | | Run PL | Attack cases | Detected | Detection rate | Benign cases | False positives | False-positive rate | |---|---|---|---|---|---|---| | 1 | 59 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 2 | 59 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 3 | 59 | 0 | 0.00 % | 872 | 0 | 0.00 % | | 4 | 59 | 0 | 0.00 % | 872 | 0 | 0.00 % | ## Combined benign results These results count benign cases whose combined request score reaches 5 or combined response score reaches 4 across all loaded rulesets. Request and response scores are evaluated separately. They differ from the per-category benign results above and are not summed across paranoia levels. | Paranoia level | Benign cases | Threshold reached | False-positive rate | |---|---|---|---| | 1 | 970 | 0 | 0.00 % | | 2 | 970 | 0 | 0.00 % | | 3 | 970 | 144 | 14.85 % | | 4 | 970 | 388 | 40.00 % | ## Application content Application content is attack-shaped input that specific applications accept, such as source code, markup, SQL statements, serialized data or control characters. It is neither an attack nor a benign control. The default rulesets are expected to block it; applications that accept it opt out with an exclusion ruleset or by disabling rulesets for their routes. | Paranoia level | Cases | Threshold reached | Block rate | |---|---|---|---| | 1 | 23 | 9 | 39.13 % | | 2 | 23 | 20 | 86.96 % | | 3 | 23 | 23 | 100.00 % | | 4 | 23 | 23 | 100.00 % | ## Vendored input classifications Classification uses the source payload and its request context before evaluating rules. Benign reclassifications remain in the benign regression traffic. A benign scope limits a case to the listed categories: it is a false positive only when those categories reach the threshold, because other categories may correctly flag the same attack-list payload. Placement corrections keep their attack classification. The JSON report records each case, source path and line, original payload SHA-256, original and effective categories and roles, benign scope, and reason. | Source | Original category | Effective category | Original role | Effective role | Benign scope | Request cases | Reason | |---|---|---|---|---|---|---|---| | crs-plugin-drupal | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 942430 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 84 | The pinned FTW stage prohibits CRS detection rule IDs 911100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920272, 920273, 920420, 921110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 3 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920272, 920273, 920420, 921110, 932240, 942200, 942340, 942370, 942430, 942431, 942432, 942490 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 4 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920272, 920273, 932236, 942430, 942431, 942432, 942440 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920272, 920273, 941100, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 5 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920273, 930120, 932240, 941110, 942200, 942370, 942340, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920273, 932350, 941100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920273, 941100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920273, 941110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920273, 942100, 942200, 942370, 942431, 942432, 942460, 942520 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 4 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920420, 920272, 920273, 920530, 921110, 942430, 942431, 942432, 942440 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920420, 941160 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 8 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 920440 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 921110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 3 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 932200, 933210, 941110, 942200, 942260, 942370, 942430, 942440 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 932236 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 932236, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 941100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 941150 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 911100, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920230, 920272, 920273 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 3 | The pinned FTW stage prohibits CRS detection rule IDs 920230, 920272, 920273, 921151, 931130, 932190, 932200, 932370, 942200, 942430, 942431, 942432, 942440 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 3 | The pinned FTW stage prohibits CRS detection rule IDs 920230, 920272, 920273, 931130, 932200, 932380, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920230, 920272, 920273, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920230, 920272, 920273, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 3 | The pinned FTW stage prohibits CRS detection rule IDs 920230, 920273, 931130, 932190, 932235, 932236, 932350, 942421, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 3 | The pinned FTW stage prohibits CRS detection rule IDs 920230, 932200, 932190, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920272 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 920420, 921110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 18 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 921110, 932236, 932250, 941100, 942120, 942210, 942340, 942390, 942432, 942450, 943120 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 921110, 941100, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 8 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 931100, 931130, 932200, 932240, 932220, 932236, 932240, 932260, 932350, 941170, 941210, 942200, 942430, 942431, 942432, 942440 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 931130, 932190, 932200, 932236, 932350, 932380, 942200, 942430, 942431, 942432, 942460 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 931130, 942430, 942431, 942432, 942440, 942460 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 932200, 932240, 942430, 942431, 942432, 942460 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 16 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 932236, 932350, 941100, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 911100, 932350, 911100, 941100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 920440, 930130 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 921150, 931130, 932240, 942200, 942330, 942340, 942370, 942430, 942431, 942432, 942450 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 4 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 931130, 932190, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 931130, 932200, 932240, 941120, 941330, 941340, 942200, 942300, 942330, 942340, 942370, 942430, 942431, 942432, 942460, 942520 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 931130, 932350, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932236, 932240, 932350, 942200, 942260, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 4 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932236, 932240, 942200, 942260, 942340, 942370, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932240 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932240, 942200, 942340, 942370, 942430, 942431, 942432, 942460 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932240, 942200, 942430, 942431, 942432, 942340, 942370, 942460, 942490 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932240, 942200, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932240, 942260, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 10 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 941100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 3 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 941100, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 6 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 941110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 941110, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 942290 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 942430, 942431, 942432, 942440, 942460 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920274, 920450 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 26 | The pinned FTW stage prohibits CRS detection rule IDs 920420 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920420, 920530 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920420, 921110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 7 | The pinned FTW stage prohibits CRS detection rule IDs 920440 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920450 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 930120, 932160 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 930120, 932260, 932236, 932350, 941100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | ApplicationContent | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 930120, 932260, 932236, 932350, 941100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. The upstream plugin permits installer fields on any path. Clearplane's Nextcloud pack scopes the installer exclusions to the installer route, so <script> in adminpass and dbpass on an arbitrary endpoint stays blocked as XSS-shaped input. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 9 | The pinned FTW stage prohibits CRS detection rule IDs 931130 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 931130, 932190, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 9 | The pinned FTW stage prohibits CRS detection rule IDs 932236 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 4 | The pinned FTW stage prohibits CRS detection rule IDs 932236, 941100, 941120, 942390, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 14 | The pinned FTW stage prohibits CRS detection rule IDs 941100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 7 | The pinned FTW stage prohibits CRS detection rule IDs 942450 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 956110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-nextcloud | command-injection | command-injection | Benign | Attack | — | 1 | The pinned FTW stage requires CRS detection rule IDs 920273, 920300, 932200, 932240. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. Its expected rules start at paranoia level 2, so it counts toward attack coverage from that level. | | crs-plugin-nextcloud | command-injection | command-injection | Benign | Attack | — | 1 | The pinned FTW stage requires CRS detection rule IDs 920273, 932200, 932240. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. Its expected rules start at paranoia level 2, so it counts toward attack coverage from that level. | | crs-plugin-nextcloud | command-injection | command-injection | Benign | Attack | — | 12 | The pinned FTW stage requires CRS detection rule IDs 932160. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. | | crs-plugin-nextcloud | protocol | protocol | Benign | Attack | — | 1 | The pinned FTW stage requires CRS detection rule IDs 920273, 920300, 932200, 932240. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. Its expected rules start at paranoia level 3, so it counts toward attack coverage from that level. | | crs-plugin-nextcloud | protocol | protocol | Benign | Attack | — | 1 | The pinned FTW stage requires CRS detection rule IDs 920273, 932200, 932240. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. Its expected rules start at paranoia level 4, so it counts toward attack coverage from that level. | | crs-plugin-nextcloud | protocol | protocol | Benign | Attack | — | 1 | The pinned FTW stage requires CRS detection rule IDs 920300, 942431, 942432, 942460. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. Its expected rules start at paranoia level 3, so it counts toward attack coverage from that level. | | crs-plugin-nextcloud | protocol | protocol | Benign | Attack | — | 1 | The pinned FTW stage requires CRS detection rule IDs 920320. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. Its expected rules start at paranoia level 2, so it counts toward attack coverage from that level. | | crs-plugin-nextcloud | protocol | protocol | Benign | Attack | — | 10 | The pinned FTW stage requires CRS detection rule IDs 920420. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. | | crs-plugin-nextcloud | sql-injection | sql-injection | Benign | Attack | — | 1 | The pinned FTW stage requires CRS detection rule IDs 920300, 942431, 942432, 942460. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. Its expected rules start at paranoia level 3, so it counts toward attack coverage from that level. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920540 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 921140 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 932110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 932125 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 932180 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 932230, 932250 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 932235 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 932236, 932260 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 932260 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 932380 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 933150 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 941160 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 3 | The pinned FTW stage prohibits CRS detection rule IDs 942100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 942140 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-phpmyadmin | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 942151 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 6 | The pinned FTW stage prohibits CRS detection rule IDs 920100, 920273, 921220, 921180, 932236, 932350, 942360, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 10 | The pinned FTW stage prohibits CRS detection rule IDs 920230, 932235, 932236, 942360, 942362, 942430, 942431, 942432, 942450 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 920650, 921180, 932200, 932240, 942370, 942430, 942431, 942432, 942520 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 921180, 932200, 932240, 942370, 942430, 942431, 942432, 942520 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 4 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 931130, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 5 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 932200, 932220, 932235, 932236, 942100, 942430, 942431, 942432, 942440 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 932200, 932236, 932240, 932370, 941150, 941180, 941181, 941320, 941330, 942130, 942131, 942200, 942210, 942260, 942330, 942340, 942370, 942430, 942431, 942432, 942440, 942460, 942520 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920272, 920273, 932200, 932240, 942370, 942430, 942431, 942432, 942520 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 920230, 932235, 932236, 942360, 942362, 942430, 942431, 942432, 942450 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 921220, 932100, 932130, 933210, 932231, 941100, 941160, 942432, 942460 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 930130, 932350, 932260, 932236, 941110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932235, 932236, 942120, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932236, 941110 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 4 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932236, 941110, 942430, 942431, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 920273, 932240, 931130, 941130, 942432 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 12 | The pinned FTW stage prohibits CRS detection rule IDs 920450 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 930121 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 930130 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 931130 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 932130 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 9 | The pinned FTW stage prohibits CRS detection rule IDs 932236 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 932240, 932236, 941100, 941150, 941160, 941180, 941181, 941320, 942210, 942330, 942340, 942370, 942430, 942431, 942432, 942440, 942520 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 942120 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 951240 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 1 | The pinned FTW stage prohibits CRS detection rule IDs 953100 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | — | — | Benign | Benign | — | 2 | The pinned FTW stage prohibits CRS detection rule IDs 953101 and requires no CRS detection ID; it is a benign control. Plugin exclusion-rule IDs do not change that classification. | | crs-plugin-wordpress | command-injection | command-injection | Benign | Attack | — | 2 | The pinned FTW stage requires CRS detection rule IDs 932160. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. | | crs-plugin-wordpress | remote-file-inclusion | remote-file-inclusion | Benign | Attack | — | 1 | The pinned FTW stage requires CRS detection rule IDs 931130. It is an attack control, including when the plugin source also contains benign exclusion tests. Multi-category controls retain one evaluation per expected category. Its expected rules start at paranoia level 2, so it counts toward attack coverage from that level. | | crs-responses | data-leakage | data-leakage | Attack | Benign | — | 5 | Pinned CRS 953101.yaml contains five ordinary prose probes explicitly described by upstream as false positives at PL1 (file size, invalid date, function, static function, empty field), plus one benign functionality control. All six backend bodies remain byte-for-byte unchanged. Treat these as benign disclosure controls independently of the PL2 detection expectation; the five upstream strict parity expectations remain failures in CRS replay. | | crs-responses | data-leakage | data-leakage | Benign | Benign | — | 1 | Pinned CRS 953101.yaml contains five ordinary prose probes explicitly described by upstream as false positives at PL1 (file size, invalid date, function, static function, empty field), plus one benign functionality control. All six backend bodies remain byte-for-byte unchanged. Treat these as benign disclosure controls independently of the PL2 detection expectation; the five upstream strict parity expectations remain failures in CRS replay. | | crs-responses | data-leakage | data-leakage | Benign | Benign | — | 7 | Pinned CRS no-expect response control supplies text/plain or text/html directly to Albedo /reflect, whose JSON contract rejects it. Preserve the intended benign text byte-for-byte as a direct response-body control; strict CRS replay remains skipped. | | crs-responses | data-leakage | data-leakage | Benign | Benign | — | 6 | Pinned CRS response stage prohibits a data-leakage detection. Backend bytes come from its explicit response or Albedo POST /reflect specification. | | crs-responses | data-leakage | data-leakage | Attack | Attack | — | 71 | Pinned CRS response stage requires a data-leakage detection. Backend bytes come from its explicit response or Albedo POST /reflect specification. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties are allowed by default; additional properties are allowed; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: additionalProperties being false does not allow other properties; an additional property is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties being false does not allow other properties; ignores arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties being false does not allow other properties; ignores other non-objects; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties being false does not allow other properties; ignores strings; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties being false does not allow other properties; no additional properties is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties being false does not allow other properties; patternProperties are not additional properties; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: additionalProperties can exist by itself; an additional invalid property is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties can exist by itself; an additional valid property is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: additionalProperties does not look in applicators; properties defined in allOf are not examined; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties with null valued instance properties; allows null values; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties with propertyNames; Valid against both keywords; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: additionalProperties with propertyNames; Valid against propertyNames, but not additionalProperties; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: additionalProperties with schema; an additional invalid property is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties with schema; an additional valid property is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: additionalProperties with schema; no additional properties is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf combined with anyOf, oneOf; allOf: false, anyOf: false, oneOf: false; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf combined with anyOf, oneOf; allOf: false, anyOf: false, oneOf: true; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf combined with anyOf, oneOf; allOf: false, anyOf: true, oneOf: false; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf combined with anyOf, oneOf; allOf: false, anyOf: true, oneOf: true; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf combined with anyOf, oneOf; allOf: true, anyOf: false, oneOf: false; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf combined with anyOf, oneOf; allOf: true, anyOf: false, oneOf: true; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf combined with anyOf, oneOf; allOf: true, anyOf: true, oneOf: false; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf combined with anyOf, oneOf; allOf: true, anyOf: true, oneOf: true; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf simple types; mismatch one; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf simple types; valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf with base schema; mismatch base schema; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf with base schema; mismatch both; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf with base schema; mismatch first allOf; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf with base schema; mismatch second allOf; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf with base schema; valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf with boolean schemas, all false; any value is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf with boolean schemas, all true; any value is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf with boolean schemas, some false; any value is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf with one empty schema; any data is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf with the first empty schema; number is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf with the first empty schema; string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf with the last empty schema; number is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf with the last empty schema; string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf with two empty schemas; any data is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allOf; allOf; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf; mismatch first; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf; mismatch second; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: allOf; wrong type; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; boolean false is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; boolean true is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; empty array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; empty object is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; null is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; number is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; object is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: allow everything with boolean schema false; string is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf complex types; both anyOf valid (complex); valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf complex types; first anyOf valid (complex); valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: anyOf complex types; neither anyOf valid (complex); valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf complex types; second anyOf valid (complex); valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: anyOf with base schema; both anyOf invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: anyOf with base schema; mismatch base schema; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf with base schema; one anyOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: anyOf with boolean schemas, all false; any value is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf with boolean schemas, all true; any value is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf with boolean schemas, some true; any value is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf with one empty schema; number is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf with one empty schema; string is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf; both anyOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf; first anyOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: anyOf; neither anyOf valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: anyOf; second anyOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: array type matches arrays; a boolean is not an array; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: array type matches arrays; a float is not an array; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: array type matches arrays; a string is not an array; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: array type matches arrays; an array is an array; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: array type matches arrays; an integer is not an array; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: array type matches arrays; an object is not an array; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: array type matches arrays; null is not an array; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; a float is not a boolean; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; a string is not a boolean; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; an array is not a boolean; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; an empty string is not a boolean; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; an integer is not a boolean; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; an object is not a boolean; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; false is a boolean; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; null is not a boolean; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; true is a boolean; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: boolean type matches booleans; zero is not a boolean; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: by int; ignores non-numbers; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: by int; int by int fail; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: by int; int by int; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: by number; -4.5 is multiple of 1.5; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: by number; 35 is not multiple of 1.5; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: by number; 4.5 is multiple of 1.5; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: by number; zero is multiple of anything; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: by small number; 0.0075 is multiple of 0.0001; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: by small number; 0.00751 is not multiple of 0.0001; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: characters with the same visual representation but different codepoint; character looks the same but uses a different codepoint; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: characters with the same visual representation but different codepoint; character uses the same codepoint; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 2 | Independent JSON Schema assertion: characters with the same visual representation, but different number of codepoints; character looks the same but uses combining marks; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 2 | Independent JSON Schema assertion: characters with the same visual representation, but different number of codepoints; character uses the same codepoint; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: collect annotations inside a 'not', even if collection is disabled; annotations are still collected inside a 'not'; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: collect annotations inside a 'not', even if collection is disabled; unevaluated property; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const validation; another type is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const validation; another value is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const validation; same value is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with -2.0 matches integer and float types; float -2.0 is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with -2.0 matches integer and float types; float -2.00001 is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with -2.0 matches integer and float types; float 2.0 is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with -2.0 matches integer and float types; integer -2 is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with -2.0 matches integer and float types; integer 2 is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with 0 does not match other zero-like types; empty array is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with 0 does not match other zero-like types; empty object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with 0 does not match other zero-like types; empty string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with 0 does not match other zero-like types; false is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with 0 does not match other zero-like types; float zero is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with 0 does not match other zero-like types; integer zero is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with 1 does not match true; float one is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with 1 does not match true; integer one is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with 1 does not match true; true is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with [false] does not match [0]; [0.0] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with [false] does not match [0]; [0] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with [false] does not match [0]; [false] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with [true] does not match [1]; [1.0] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with [true] does not match [1]; [1] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with [true] does not match [1]; [true] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with array; another array item is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with array; array with additional items is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with array; same array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with false does not match 0; false is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with false does not match 0; float zero is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with false does not match 0; integer zero is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with null; not null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with null; null is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with object; another object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with object; another type is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with object; same object is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with object; same object with different property order is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with true does not match 1; float one is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with true does not match 1; integer one is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with true does not match 1; true is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with {"a": false} does not match {"a": 0}; {"a": 0.0} is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with {"a": false} does not match {"a": 0}; {"a": 0} is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with {"a": false} does not match {"a": 0}; {"a": false} is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with {"a": true} does not match {"a": 1}; {"a": 1.0} is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: const with {"a": true} does not match {"a": 1}; {"a": 1} is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: const with {"a": true} does not match {"a": 1}; {"a": true} is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: dependentSchemas with additionalProperties; additionalProperties can't see bar even when foo2 is present; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: dependentSchemas with additionalProperties; additionalProperties can't see bar; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: dependentSchemas with additionalProperties; additionalProperties doesn't consider dependentSchemas; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: double negation; any value is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: empty enum; array is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: empty enum; boolean is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: empty enum; null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: empty enum; number is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: empty enum; object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: empty enum; string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with 0 does not match false; false is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with 0 does not match false; float zero is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with 0 does not match false; integer zero is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with 1 does not match true; float one is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with 1 does not match true; integer one is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with 1 does not match true; true is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with [0] does not match [false]; [0.0] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with [0] does not match [false]; [0] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with [0] does not match [false]; [false] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with [1] does not match [true]; [1.0] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with [1] does not match [true]; [1] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with [1] does not match [true]; [true] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with [false] does not match [0]; [0.0] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with [false] does not match [0]; [0] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with [false] does not match [0]; [false] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with [true] does not match [1]; [1.0] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with [true] does not match [1]; [1] is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with [true] does not match [1]; [true] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with escaped characters; another string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with escaped characters; member 1 is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with escaped characters; member 2 is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with false does not match 0; false is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with false does not match 0; float zero is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with false does not match 0; integer zero is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with true does not match 1; float one is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enum with true does not match 1; integer one is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enum with true does not match 1; true is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enums in properties; both properties are valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enums in properties; missing all properties is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: enums in properties; missing optional property is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enums in properties; missing required property is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enums in properties; wrong bar value; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: enums in properties; wrong foo value; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: exclusiveMaximum validation; above the exclusiveMaximum is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: exclusiveMaximum validation; below the exclusiveMaximum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: exclusiveMaximum validation; boundary point is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: exclusiveMaximum validation; ignores non-numbers; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: exclusiveMinimum validation; above the exclusiveMinimum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: exclusiveMinimum validation; below the exclusiveMinimum is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: exclusiveMinimum validation; boundary point is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: exclusiveMinimum validation; ignores non-numbers; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: float and integers are equal up to 64-bit representation limits; float is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: float and integers are equal up to 64-bit representation limits; float minus one is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: float and integers are equal up to 64-bit representation limits; integer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: float and integers are equal up to 64-bit representation limits; integer minus one is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: float division = inf; always invalid, but naive implementations may raise an overflow error; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; array is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; boolean false is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; boolean true is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; empty array is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; empty object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; number is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with boolean schema true; string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; array is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; boolean false is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; boolean true is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; empty array is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; empty object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; number is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbid everything with empty schema; string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: forbidden property; property absent; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: forbidden property; property present; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: heterogeneous enum validation; extra properties in object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: heterogeneous enum validation; objects are deep compared; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: heterogeneous enum validation; one of the enum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: heterogeneous enum validation; something else is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: heterogeneous enum validation; valid object matches; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: heterogeneous enum-with-null validation; null is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: heterogeneous enum-with-null validation; number is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: heterogeneous enum-with-null validation; something else is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: integer type matches integers; a boolean is not an integer; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: integer type matches integers; a float is not an integer; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: integer type matches integers; a float with zero fractional part is an integer; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: integer type matches integers; a string is not an integer; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: integer type matches integers; a string is still not an integer, even if it looks like one; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: integer type matches integers; an array is not an integer; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: integer type matches integers; an integer is an integer; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: integer type matches integers; an object is not an integer; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: integer type matches integers; null is not an integer; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxItems validation with a decimal; shorter is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maxItems validation with a decimal; too long is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxItems validation; exact length is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxItems validation; ignores non-arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxItems validation; shorter is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maxItems validation; too long is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxLength validation with a decimal; shorter is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maxLength validation with a decimal; too long is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxLength validation; exact length is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxLength validation; ignores non-strings; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxLength validation; shorter is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maxLength validation; too long is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxLength validation; two graphemes is long enough; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxProperties = 0 means the object is empty; no properties is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maxProperties = 0 means the object is empty; one property is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxProperties validation with a decimal; shorter is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maxProperties validation with a decimal; too long is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxProperties validation; exact length is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxProperties validation; ignores arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxProperties validation; ignores other non-objects; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxProperties validation; ignores strings; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maxProperties validation; shorter is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maxProperties validation; too long is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maximum validation with unsigned integer; above the maximum is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maximum validation with unsigned integer; below the maximum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maximum validation with unsigned integer; boundary point float is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maximum validation with unsigned integer; boundary point integer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: maximum validation; above the maximum is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maximum validation; below the maximum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maximum validation; boundary point is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: maximum validation; ignores non-numbers; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minItems validation with a decimal; longer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minItems validation with a decimal; too short is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minItems validation; exact length is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minItems validation; ignores non-arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minItems validation; longer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minItems validation; too short is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minLength validation with a decimal; longer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minLength validation with a decimal; too short is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minLength validation; exact length is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minLength validation; ignores non-strings; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minLength validation; longer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minLength validation; one grapheme is not long enough; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minLength validation; too short is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minProperties validation with a decimal; longer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minProperties validation with a decimal; too short is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minProperties validation; exact length is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minProperties validation; ignores arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minProperties validation; ignores booleans; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minProperties validation; ignores null; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minProperties validation; ignores other non-objects; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minProperties validation; ignores strings; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minProperties validation; longer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minProperties validation; too short is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minimum validation with signed integer; boundary point is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minimum validation with signed integer; boundary point with float is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minimum validation with signed integer; float below the minimum is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minimum validation with signed integer; ignores non-numbers; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minimum validation with signed integer; int below the minimum is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minimum validation with signed integer; negative above the minimum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minimum validation with signed integer; positive above the minimum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minimum validation; above the minimum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: minimum validation; below the minimum is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minimum validation; boundary point is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: minimum validation; ignores non-numbers; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: multiple types can be specified in an array; a boolean is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: multiple types can be specified in an array; a float is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: multiple types can be specified in an array; a string is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: multiple types can be specified in an array; an array is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: multiple types can be specified in an array; an integer is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: multiple types can be specified in an array; an object is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: multiple types can be specified in an array; null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: nested allOf, to check validation semantics; anything non-null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: nested allOf, to check validation semantics; null is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: nested anyOf, to check validation semantics; anything non-null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: nested anyOf, to check validation semantics; null is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: nested oneOf, to check validation semantics; anything non-null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: nested oneOf, to check validation semantics; null is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: non-ASCII pattern with additionalProperties; matching the pattern is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: non-ASCII pattern with additionalProperties; not matching the pattern is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: not more complex schema; match; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: not more complex schema; mismatch; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: not more complex schema; other match; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: not multiple types; mismatch; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: not multiple types; other mismatch; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: not multiple types; valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: not; allowed; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: not; disallowed; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 2 | Independent JSON Schema assertion: nul characters in strings; do not match string lacking nul; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | ApplicationContent | — | 2 | Independent JSON Schema assertion: nul characters in strings; match string with nul; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. The valid document carries NUL characters or control characters in property names, which the default rulesets block as injection-shaped input. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; a float is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; a string is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; an array is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; an empty string is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; an integer is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; an object is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; false is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: null type matches only the null object; null is null; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; true is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: null type matches only the null object; zero is not null; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: number type matches numbers; a boolean is not a number; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: number type matches numbers; a float is a number; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: number type matches numbers; a float with zero fractional part is a number (and an integer); valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: number type matches numbers; a string is not a number; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: number type matches numbers; a string is still not a number, even if it looks like one; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: number type matches numbers; an array is not a number; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: number type matches numbers; an integer is a number; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: number type matches numbers; an object is not a number; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: number type matches numbers; null is not a number; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: object properties validation; both properties invalid is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: object properties validation; both properties present and valid is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: object properties validation; doesn't invalidate other properties; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: object properties validation; ignores arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: object properties validation; ignores other non-objects; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: object properties validation; one property invalid is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: object type matches objects; a boolean is not an object; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: object type matches objects; a float is not an object; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: object type matches objects; a string is not an object; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: object type matches objects; an array is not an object; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: object type matches objects; an integer is not an object; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: object type matches objects; an object is an object; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: object type matches objects; null is not an object; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf complex types; both oneOf valid (complex); valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf complex types; first oneOf valid (complex); valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf complex types; neither oneOf valid (complex); valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf complex types; second oneOf valid (complex); valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with base schema; both oneOf valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with base schema; mismatch base schema; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf with base schema; one oneOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with boolean schemas, all false; any value is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with boolean schemas, all true; any value is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with boolean schemas, more than one true; any value is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf with boolean schemas, one true; any value is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with empty schema; both valid - invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf with empty schema; one valid - valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with missing optional property; both oneOf valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf with missing optional property; first oneOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with missing optional property; neither oneOf valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf with missing optional property; second oneOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with required; both invalid - invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf with required; both valid - invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf with required; first valid - valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf with required; second valid - valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf; both oneOf valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf; first oneOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: oneOf; neither oneOf valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: oneOf; second oneOf valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties whose names are Javascript object property names; __proto__ not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties whose names are Javascript object property names; all present and valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties whose names are Javascript object property names; constructor not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties whose names are Javascript object property names; ignores arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties whose names are Javascript object property names; ignores other non-objects; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties whose names are Javascript object property names; none of the properties mentioned; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties whose names are Javascript object property names; toString not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties with boolean schema; both properties present is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties with boolean schema; no property present is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties with boolean schema; only 'false' property present is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties with boolean schema; only 'true' property present is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | ApplicationContent | — | 1 | Independent JSON Schema assertion: properties with escaped characters; object with all numbers is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. The valid document carries NUL characters or control characters in property names, which the default rulesets block as injection-shaped input. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties with escaped characters; object with strings is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties with null valued instance properties; allows null values; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties, patternProperties, additionalProperties interaction; additionalProperty ignores property; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties, patternProperties, additionalProperties interaction; additionalProperty invalidates others; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties, patternProperties, additionalProperties interaction; additionalProperty validates others; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties, patternProperties, additionalProperties interaction; patternProperty invalidates nonproperty; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties, patternProperties, additionalProperties interaction; patternProperty invalidates property; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties, patternProperties, additionalProperties interaction; patternProperty validates nonproperty; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: properties, patternProperties, additionalProperties interaction; property invalidates property; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: properties, patternProperties, additionalProperties interaction; property validates property; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required default validation; not required by default; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: required properties whose names are Javascript object property names; __proto__ present; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required properties whose names are Javascript object property names; all present; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: required properties whose names are Javascript object property names; constructor present; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required properties whose names are Javascript object property names; ignores arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required properties whose names are Javascript object property names; ignores other non-objects; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: required properties whose names are Javascript object property names; none of the properties mentioned; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: required properties whose names are Javascript object property names; toString present; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required validation; ignores arrays; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required validation; ignores boolean; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required validation; ignores null; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required validation; ignores other non-objects; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required validation; ignores strings; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: required validation; non-present required property is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required validation; present required property is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: required with empty array; property not required; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | ApplicationContent | — | 1 | Independent JSON Schema assertion: required with escaped characters; object with all properties present is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. The valid document carries NUL characters or control characters in property names, which the default rulesets block as injection-shaped input. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: required with escaped characters; object with some properties missing is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: simple enum validation; one of the enum is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: simple enum validation; something else is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: small multiple of large integer; any integer is a multiple of 1e-8; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: string type matches strings; 1 is not a string; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: string type matches strings; a boolean is not a string; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: string type matches strings; a float is not a string; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: string type matches strings; a string is a string; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: string type matches strings; a string is still a string, even if it looks like a number; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: string type matches strings; an array is not a string; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: string type matches strings; an empty string is still a string; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: string type matches strings; an object is not a string; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: string type matches strings; null is not a string; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: type as array with one item; number is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: type as array with one item; string is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: type: array or object; array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: type: array or object; null is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: type: array or object; number is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: type: array or object; object is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: type: array or object; string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: type: array, object or null; array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: type: array, object or null; null is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: type: array, object or null; number is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: type: array, object or null; object is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: type: array, object or null; string is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; 0 and false are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; 1 and true are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; [0] and [false] are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; [1] and [true] are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; different objects are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; false is not equal to zero; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; nested [0] and [false] are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; nested [1] and [true] are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; non-unique array of arrays is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; non-unique array of integers is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; non-unique array of more than two arrays is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; non-unique array of more than two integers is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; non-unique array of nested objects is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; non-unique array of objects is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; non-unique array of strings is invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; non-unique heterogeneous types are invalid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; numbers are unique if mathematically unequal; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; objects are non-unique despite key order; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems validation; property order of array of objects is ignored; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; true is not equal to one; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; unique array of arrays is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; unique array of integers is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; unique array of nested objects is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; unique array of objects is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; unique array of strings is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; unique heterogeneous types are valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; {"a": false} and {"a": 0} are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems validation; {"a": true} and {"a": 1} are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items and additionalItems=false; [false, false] from items array is not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items and additionalItems=false; [false, true] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items and additionalItems=false; [true, false] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items and additionalItems=false; [true, true] from items array is not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items and additionalItems=false; extra items are invalid even if unique; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items; [false, false] from items array is not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items; [false, true] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items; [true, false] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items; [true, true] from items array is not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items; non-unique array extended from [false, true] is not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items; non-unique array extended from [true, false] is not valid; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items; unique array extended from [false, true] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems with an array of items; unique array extended from [true, false] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; 0 and false are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; 1 and true are unique; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; false is not equal to zero; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; non-unique array of arrays is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; non-unique array of integers is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; non-unique array of nested objects is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; non-unique array of objects is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; non-unique heterogeneous types are valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; numbers are unique if mathematically unequal; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; true is not equal to one; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; unique array of arrays is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; unique array of integers is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; unique array of nested objects is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; unique array of objects is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false validation; unique heterogeneous types are valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items and additionalItems=false; [false, false] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items and additionalItems=false; [false, true] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items and additionalItems=false; [true, false] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items and additionalItems=false; [true, true] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Attack | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items and additionalItems=false; extra items are invalid even if unique; valid=false. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items; [false, false] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items; [false, true] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items; [true, false] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items; [true, true] from items array is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items; non-unique array extended from [false, true] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items; non-unique array extended from [true, false] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items; unique array extended from [false, true] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | json-schema-test-suite | api-schema | api-schema | Attack | Benign | — | 1 | Independent JSON Schema assertion: uniqueItems=false with an array of items; unique array extended from [true, false] is valid; valid=true. Invalid denotes a request that violates its configured schema, not malicious intent. | | payloads-all-the-things | ldap-injection | ldap-injection | Attack | Benign | — | 54 | Bare LDAP attribute names are benign data. The pinned README lists them as Defaults Attributes and interpolates them into filter syntax for attacks. | | payloads-all-the-things | ldap-injection | ldap-injection | Attack | Attack | — | 98 | The LDAP README defines authentication bypass by interpolating user input into a login filter. Preserve payload bytes in a named login parameter; no filter wrapper or successful detection is required for classification. | | payloads-all-the-things | ldap-injection | ldap-injection | Attack | Attack | — | 54 | The pinned LDAP Injection README uses each attribute in the filter-breaking login template *)({attribute}=*)) followed by NUL; bare attribute names are not injections. | | payloads-all-the-things | ldap-injection | ldap-injection | Attack | Benign | — | 28 | This complete value contains no LDAP filter assertion metacharacter (asterisk, parentheses, backslash or NUL). Slash and literal boolean-operator characters inside an assertion value do not change RFC4515 filter syntax; retain it as a benign regression. | | payloads-all-the-things | open-redirect | open-redirect | Attack | Attack | — | 211 | Standalone destinations are placed in the redirect query parameter, matching the pinned Open Redirect README Common Query Parameters. | | payloads-all-the-things | open-redirect | open-redirect | Attack | Benign | open-redirect | 50 | This destination remains a same-origin relative path for both HTTP and HTTPS localhost bases, including zero, one and two percent-decoding passes where valid, under independent Node WHATWG URL parsing. Preserve it as a benign off-origin regression; no undocumented server rewrite is assumed. | | payloads-all-the-things | open-redirect | open-redirect | Attack | Attack | — | 12 | This source line is a complete request target with its own redirect parameters. Preserve that query instead of encoding the entire target inside one parameter; see the pinned README redirect?url= example. | | payloads-all-the-things | open-redirect | open-redirect | Attack | Benign | open-redirect | 48 | Under the original HTTP request origin, this same-scheme no-slash URL is a relative path under WHATWG special-relative-or-authority parsing. Retain this HTTP control and add a separate HTTPS-origin attack/probe from the same exact source bytes. | | payloads-all-the-things | xxe | php-injection | Attack | Attack | — | 3 | PHP code execution or an XSLT PHP extension invocation; it remains an attack in its original XML body and does not declare or resolve an external XML entity. | | payloads-all-the-things | xxe | sql-injection | Attack | Attack | — | 3 | Boolean SQL injection text carried inside XML CDATA; it remains an attack in its original XML body and does not declare or resolve an external XML entity. | | payloads-all-the-things | ldap-injection | xpath-injection | Attack | Attack | — | 6 | This quoted boolean/name() expression is XPath injection syntax, not LDAP filter syntax; retain its Attack role and bytes. | | payloads-all-the-things | xxe | xpath-injection | Attack | Attack | — | 4 | XPath query probing or a boolean XPath breakout; it remains an attack in its original XML body. XPath injection semantics: https://owasp.org/www-community/attacks/XPATH_Injection | | payloads-all-the-things | xxe | xss | Attack | Attack | — | 37 | Browser script, script-context breakout or legacy XML data-island XSS vector; it remains an attack in its original XML body. XSS semantics: https://cheatsheetseries.owasp.org/cheatsheets/XSS_Filter_Evasion_Cheat_Sheet.html#xml-data-island-with-cdata-obfuscation | | payloads-all-the-things | open-redirect | xss | Attack | Attack | — | 4 | The destination uses a script/data scheme rather than another web origin; retain it as an XSS attack in the original named redirect parameter. Classification follows WHATWG URL parsing independently of WAF matches. | | payloads-all-the-things | xxe | xxe | Attack | Benign | — | 2 | The line contains only literal Unicode punctuation and no executable, DTD or entity syntax. XML semantics: https://www.w3.org/TR/xml/#sec-cdata-sect | | payloads-all-the-things | xxe | xxe | Attack | Benign | — | 7 | The line contains only ordinary XML markup, an XML declaration, predefined character references or a plain-text CDATA section; it has no DTD, custom entity or executable construct. XML semantics: https://www.w3.org/TR/xml/#sec-cdata-sect | | payloads-all-the-things-core | command-injection | command-injection | Attack | Attack | — | 160 | Published command-injection probes inserted as an application command argument through query and form input; original bytes, quoting and encodings are preserved. | | payloads-all-the-things-core | path-traversal | command-injection | Attack | Attack | — | 8 | The payload invokes /bin/cat using line or quote injection and contains no directory traversal segment. Preserve its attack role as command injection. | | payloads-all-the-things-core | path-traversal | path-traversal | Attack | Attack | — | 272 | Published traversal and sensitive-file read probes inserted as an application file path through query and form input; original bytes and encodings are preserved. | | payloads-all-the-things-core | command-injection | php-injection | Attack | Attack | — | 6 | The payload calls PHP system() using PHP expression syntax, rather than a shell command separator plus a program. Preserve its attack role with PHP injection attribution. | | payloads-all-the-things-core | protocol | protocol | Attack | Attack | — | 34 | Complete published CRLF response-header injection list supplied through query and form input reflected by an application into an HTTP header, as described in the pinned CRLF README; raw transport-invalid requests are not substituted for these application inputs. | | payloads-all-the-things-core | xss | xss | Attack | ApplicationContent | — | 2 | A heading element alone contains no executable script, event handler, navigation or script-context escape, but it is an HTML injection probe. Markup is application content: the default rulesets block it and rich-text applications opt out with an exclusion ruleset. | | payloads-all-the-things-core | xss | xss | Attack | Attack | — | 32 | Complete published XSS polyglot list supplied through query and form input for downstream HTML/attribute/script interpolation; original bytes are preserved. | | payloads-all-the-things-core | xss | xss | Attack | Attack | — | 76 | Published script-injection probes supplied through query and form input to an HTML, attribute or inline-script interpolation context; no browser execution is performed. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 1 | Published Json.NET ObjectDataProvider payload retains single-quoted JSON accepted by Json.NET; submit raw bytes without normalizing the document. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 3 | Published PHP deserialization authentication bypass using boolean coercion or aliased references; retain attacks requiring application semantics. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 1 | Published PHP object injection payload supplied in serialized input context. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 1 | Published Ruby Marshal gadget byte sequence, decoded from its documented hexadecimal representation without executing it. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 3 | Published Ruby YAML universal deserialization gadget; submit the complete YAML document unchanged. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 1 | Published SnakeYAML ScriptEngineManager and URLClassLoader construction gadget. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 1 | Published XmlSerializer ObjectDataProvider execution gadget, excluding the generator command. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 2 | Published multi-line unsafe YAML execution gadget; complete document preserved. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 2 | Published serialized immediately invoked function gadget for node-serialize or funcster; complete JSON body preserved. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 6 | Published unsafe YAML dynamic object construction example; full source tag and arguments preserved. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | ApplicationContent | — | 1 | Source explicitly labels this PHP array as normal serialization output; it contains strings and no object construction. Serialized data in a cookie is still deserialization-shaped application content: the default rulesets block it and applications that store serialized cookies opt out with an exclusion ruleset. | | payloads-all-the-things-examples | deserialization | deserialization | Attack | Attack | — | 5 | The source identifies this JSON polymorphic type as an unsafe deserialization gadget; preserve its published type and value bytes, including documented placeholders. | | payloads-all-the-things-examples | graphql | graphql | Attack | Attack | — | 3 | Published schema introspection/enumeration request; production policy prohibits schema disclosure, while ordinary application queries remain benign. | | payloads-all-the-things-examples | graphql | graphql | Attack | Attack | — | 1 | Source explicitly describes password brute-force amplification using repeated login aliases; preserve its four attempts even below the current generic alias cap. | | payloads-all-the-things-examples | graphql | graphql | Attack | Attack | — | 1 | Source introspection query in production schema-disclosure policy context; GraphQL itself permits this feature. | | payloads-all-the-things-examples | graphql | graphql | Attack | Benign | — | 4 | Source ordinary query example retrieves a user and related fields without schema introspection or amplification. | | payloads-all-the-things-examples | graphql | graphql | Attack | Benign | — | 2 | Source ordinary sign-in or user creation mutation; operation type alone is not an attack. | | payloads-all-the-things-examples | jwt | jwt | Attack | Attack | — | 1 | Published RSA-to-HMAC key-confusion forged JWT. Its header and signature are syntactically ordinary; detecting this attack requires issuer algorithm/key policy, so retain the measurement miss. | | payloads-all-the-things-examples | jwt | jwt | Attack | Attack | — | 1 | Published null-signature authentication bypass compact JWT; no signature is added by the adapter. | | payloads-all-the-things-examples | jwt | jwt | Attack | Benign | — | 1 | The token format section gives this ordinary signed JWT as a structural example; signature validity requires issuer keys outside this traffic. | | payloads-all-the-things-examples | nosql-injection | nosql-injection | Attack | Attack | — | 1 | Source identifies embedded NoSQL query operator injection in a GraphQL argument; preserve GraphQL transport and expected injection category. | | payloads-all-the-things-examples | open-redirect | open-redirect | Attack | Attack | — | 48 | Published no-slash HTTP redirect bypass requires a different HTTPS origin to enter authority parsing. Exact source bytes retained; invalid authority probes remain attacks and are not dropped when WHATWG rejects them. | | payloads-all-the-things-examples | prototype-pollution | prototype-pollution | Attack | Attack | — | 3 | Published HTTP URL query pollution payload; extract only its query component, preserving percent encoding. | | payloads-all-the-things-examples | prototype-pollution | prototype-pollution | Attack | Attack | — | 4 | Published parameter pollution path supplied as a query assignment; retain bracket and dotted syntax. | | payloads-all-the-things-examples | prototype-pollution | prototype-pollution | Attack | Attack | — | 2 | Published prototype pollution JSON payload; preserve dotted and object property forms. | | payloads-all-the-things-examples | prototype-pollution | prototype-pollution | Attack | Attack | — | 4 | Published server-side prototype pollution JSON request; preserve object nesting and property names. | | payloads-all-the-things-examples | sql-injection | sql-injection | Attack | Attack | — | 1 | Source explicit stacked SQL statement and delay injection inside GraphQL; category follows injection semantics. | | payloads-all-the-things-examples | ssrf | ssrf | Attack | Attack | — | 53 | Published SSRF bypass/exploitation URL in an outbound fetch parameter. Retain URL parser and redirect-dependent cases without resolving DNS or following redirects. | | payloads-all-the-things-examples | ssrf | ssrf | Attack | Benign | — | 1 | Published Unicode spelling of a public example.com host; encoding alone is not an internal destination. | | scanner-defaults-feroxbuster | scanner | scanner | Attack | Attack | — | 1 | The pinned generated shell-completion description states this exact default User-Agent. This tests the declared scanner fingerprint, not hidden or randomized scanner identities. | | scanner-defaults-feroxbuster | scanner | scanner | Attack | Attack | — | 1 | The pinned scan-state integration fixture supplies this exact configured User-Agent for its real scan requests. This tests the declared scanner fingerprint, not hidden or randomized scanner identities. | | scanner-defaults-ffuf | scanner | scanner | Attack | Attack | — | 5 | Complete TestSelectVersion decision table: combine its expected version with the default User-Agent format in pinned pkg/runner/simple.go. This measures a declared security-tool fingerprint, not all scanning behavior; no upstream code is executed. | | scanner-defaults-gobuster | scanner | scanner | Attack | Attack | — | 1 | Pinned libgobuster/helpers.go DefaultUserAgent combines gobuster/ with this declared VERSION constant. This is a tool fingerprint; operators may explicitly authorize their own scanner traffic. | | synthetic-benign | — | — | Benign | ApplicationContent | — | 15 | Source code, markup and SQL statements are attack-shaped input that only authoring, developer and database applications accept. The default rulesets block them; such applications opt out with an exclusion ruleset or by disabling rulesets for their routes. | ## Skipped tests The report records 119 skipped tests. Reasons include unsupported replay semantics, explicit exclusions, and requests that cannot be reconstructed. These are separate from unsupported expected source rule IDs in the CRS tables. | Source | Reason | Tests | |---|---|---| | crs | AutocompleteHeadersDisabled | 19 | | crs | KestrelRejectsRequest | 15 | | crs | Listed | 8 | | crs | LogTextExpectation | 48 | | crs | ResponseSide | 10 | | crs | StatusOnlyExpectation | 17 | | crs | UnsupportedDataTemplate | 2 | ## Failure records The report contains 1019 failure records, grouped below. BudgetExceeded and BodyUninspected record incomplete evaluation separately at every affected paranoia level, even when a category matched. BudgetExceeded includes exhausted parser, engine work and retained-finding limits. IncompleteBlocked records an attack whose inspection was incomplete but which is still blocked in Prevention, either because a rule in its category reached the threshold or because the exhausted budget fails closed; it does not make a category unmeasured. These are diagnostic records, not additional cases or a denominator for the rates above; the JSON report retains individual test IDs. | Source | Kind | Records | |---|---|---| | crs | IncompleteBlocked | 31 | | crs | Missed | 27 | | crs-plugin-nextcloud | BudgetExceeded | 2 | | crs-plugin-wordpress | BudgetExceeded | 2 | | crs-plugin-wordpress | Missed | 1 | | payloads-all-the-things | IncompleteBlocked | 12 | | payloads-all-the-things | Missed | 782 | | payloads-all-the-things-core | Missed | 14 | | payloads-all-the-things-examples | Missed | 148 | ================================================================================ DOCUMENT: Data leakage ruleset Human URL: /docs/security/waf-data-leakage/ ================================================================================ `clearplane-data-leakage` contains response rules derived from CRS 950–956 and native disclosure signatures. Enable Headers and body response inspection to inspect response text. ## Paranoia levels and compatibility Error documentation and source-code pages can still need a scoped policy. Streaming and oversized responses have log-only response decisions; see [inspected traffic](/docs/security/waf-inspected-traffic/#responses) for those boundaries. Start in Detection, review [detections](/docs/security/waf-detections/), and configure only the [exclusions](/docs/security/waf-exclusion-rulesets/) needed for the affected route and field. See the [measured coverage](/docs/security/waf-coverage/) for the exact tested payload hashes, missed detections and false-positive rates. [Ruleset operation](/docs/security/waf-rulesets/) explains activation, stages and rollback. ================================================================================ DOCUMENT: Review WAF detections Human URL: /docs/security/waf-detections/ ================================================================================ Open **Firewall → Detections** for every request the WAF matched a rule against. Logs still record WAF activity as ordinary application entries; this view is the typed, filterable one. Each row is one inspected transaction: a request, a client WebSocket message or a response. Expand it to see the request line with its query string, the recorded request headers, the stage, the scoring mode and combined scores, one card per ruleset that matched (version, ruleset stage, effective mode, blocking and detection scores against its threshold, marked **Exceeded** when the ruleset reached it), and the individual findings with the ruleset each came from and the value it matched. Filter by decision, mode, stage, ruleset, rule, severity, route, minimum score, host, or source address. A rule is identified by its ruleset and rule ID together; two rulesets may use the same rule ID. A WebSocket message has its own detection with the originating connection ID and message index. `ConnectionClosed` means Prevention rejected the message and closed the connection with status 1008. A gRPC request's detection carries the cumulative score of its inspected messages. See [WAF inspected traffic](/docs/security/waf-inspected-traffic/) for message limits and large-body behavior. A response detection has stage `Response`, with one detection per response and the request's correlation ID. `ResponseDecisionLoggedOnly` means the response would have been blocked, but it was streaming or had already started. The row's score adds blocking and detection scores. That total alone does not explain a blocking decision: detection scores cannot contribute to blocking, and Per ruleset mode compares each ruleset with its own threshold. Use the expanded evaluations and the [scoring guide](/docs/security/waf-scoring-and-paranoia/) to interpret the decision. ## Request context and redaction {#request-context-and-redaction} Edge redacts a detection before writing it, so a secret you mark as sensitive never reaches the log. With request context on, a detection records: - the query string, with the value of every sensitive query key replaced by `‹redacted›`; - the request headers, at most 64 and up to 1,024 characters per value. **Allowlist** mode keeps the values of the recorded headers and redacts the rest; **Redact sensitive** keeps every value except the sensitive headers. Sensitive headers such as `Authorization`, `Cookie` and `X-Api-Key` are redacted in both modes; - each finding's matched value, cut to the configured length. A value from a sensitive header, or from a query, form or JSON field named like a sensitive query key, is redacted whole; so are cookie values while `Cookie` is sensitive and JWT values while `Authorization` is. Sensitive `key=value` or JSON pairs inside a value are masked. The detail shows each redacted value as a **redacted** chip and notes when headers were left out. Request bodies and uploaded content are never recorded beyond matched values. Only a request that produces a detection is captured, and redaction happens once: changing the lists affects new detections only. Each [WAF policy](/docs/security/waf-rulesets/#waf-policies) chooses **Record request context** and its **Header values** mode; with capture off, its detections record only the method, host, path and findings. Docker-discovered routes use the `clearplane.proxy.waf.request-context.enabled` and `clearplane.proxy.waf.request-context.header-capture-mode` labels. The lists and the global switch live in [Firewall settings](#firewall-settings). ## Tune a route before Prevention Select a route, either with the route scope or the route filter. The **Noisy rules** panel ranks the rules that produced the most detections on that route in the last 7 days, with the targets and field names they matched most often. From a noisy rule or from a finding, choose **Exclude** to add an exclusion to the route's effective WAF policy: - **Disable this rule in the policy** stops the rule for every field on the policy's routes. - **Skip this rule for a field with this exact name** stops it only for that target and field name, for example the `content` form field. - **Skip this rule for field names starting with** covers families of fields, for example every `$.items[` JSON path. Before you save, the dialog names the policy and the routes it reaches, and shows how many of this route's findings from the last 7 days the exclusion would have suppressed, with examples. An exclusion on the Global policy applies to every route that follows it. Saving changes only the policy's rule tuning, so you need **WAF policies: Write**; it also works on a policy defined by container labels. The exclusion applies to new requests once the configuration is applied. Prefer the narrowest exclusion that stops the false positive. For applications that many installations share, an [exclusion ruleset](/docs/security/waf-exclusion-rulesets/) may already cover it. Neither the **Noisy rules** report nor the exclusion preview reads recorded request context. Every detection is recorded; none are sampled. A rule that matches a large share of your traffic will produce a correspondingly large number of rows until retention removes them, which is itself the signal that the rule needs an exclusion. ## Reason codes and fingerprints A finding's reason code is an identifier defined by the ruleset that matched, such as `sql-union-select` or `xss-event-handler`. Reason codes are ruleset data rather than a fixed Clearplane list, so new content brings new codes without a Clearplane release. Two rulesets may use the same code for the same class of finding; the ruleset ID and rule ID beside it together identify which rule fired. The fingerprint column is filled in only by fingerprint detectors, which summarise how a value parsed instead of naming a pattern. A SQL fingerprint is the libinjection token signature of the value, such as `s&1`; an HTML fingerprint names the construct that triggered it, such as `tag:script` or `attr:onmouseover`. A fingerprint is a compact description of the input's shape, not a copy of the input. Ruleset authors define both: see [condition reason codes](/docs/waf-reference/rule-flow/#operators-and-negation), [detector pattern reasons](/docs/waf-reference/detectors-and-patterns/) and the [tokenizer reference](/docs/waf-reference/tokenizers/). ## What the WAF inspects Rules match against named targets. [Targets](/docs/waf-reference/targets/) lists every field a rule can inspect, and [Facts and limits](/docs/waf-reference/facts-and-limits/) lists the parser facts, measures and structural limits. A body sent without a `Content-Type` is parsed as a form. The engine never resolves or expands an XML entity and never loads an external DTD. A general entity reference is inspected as the literal text `&name;` wherever it appears, in content and in attribute values alike, and a declaration contributes its replacement text, system identifier or public identifier as a declaration rather than as document content. GraphQL field paths use the schema field name, so an alias cannot hide `__schema`; aliases are only counted. Fragment spreads are recorded, never expanded. The engine parses the document and never executes it. Bodies are decoded for inspection only. Edge always forwards the original bytes upstream; decompression and transcoding never change the proxied request. ## Firewall settings Open **System → Settings → Firewall** to bound body decoding and to decide what detections record. Each WAF policy sets its own scoring mode; see [scoring and paranoia levels](/docs/security/waf-scoring-and-paranoia/). The body decoding settings apply to every route; [Resource settings](/docs/waf-reference/facts-and-limits/#resource-settings) lists them with their defaults. Firewall settings are staged with the rest of the configuration. **Maximum file content bytes** is how many leading bytes of each uploaded file rules may inspect; `0` inspects file names, content types and archive entry names only. **Raw body window characters** and **Maximum raw body characters** govern raw-body inspection. **Maximum raw body characters** caps how much of a decoded body those windows cover — beyond it raw text is not scanned; structured parsing remains subject to the policy's effective body and parser limits. Lower both if large bodies dominate your traffic; raise them if you need raw coverage of larger bodies. Under **Detection context**, **Record request context** off stops capture on every route, whatever its policy says. **Recorded headers** lists the header values that Allowlist policies keep. **Sensitive headers** and **Sensitive query keys** are redacted in every mode, and their names match without regard to case. **Matched value length** keeps 0–160 characters of each matched value; 0 keeps none. The [rule language reference](/docs/waf-reference/) explains the targets, reason codes and integrity vectors behind a finding. ================================================================================ DOCUMENT: Use WAF exclusion rulesets Human URL: /docs/security/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. | Application | Ruleset ID | Scoped workflows | |---|---|---| | WordPress | `clearplane-exclusions-wordpress-core` | Password and installation forms; REST editor, template and global-style fields; block-widget editor content in batch requests; supported method overrides; customizer previews and saves; selected metadata, nonce, referrer and AJAX fields. | | Nextcloud | `clearplane-exclusions-nextcloud-core` | DAV methods beyond the default `PUT`, `PATCH` and `DELETE`, uploaded-file metadata and media types; named mail, notes, editor, chat, calendar and password fields; smart-picker reference URLs; guarded office settings uploads. | | phpMyAdmin | `clearplane-exclusions-phpmyadmin-core` | SQL entry, linting and formatting; named routine and generated-column expressions; import filenames; selected return links and database search fields. | 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](/docs/security/waf-detections/). The [reference example](/docs/waf-reference/examples/#exclude-a-wordpress-editor-field) shows the exclusion document and its vector checking the selected field and path. ================================================================================ DOCUMENT: WAF inspected traffic Human URL: /docs/security/waf-inspected-traffic/ ================================================================================ Each [WAF policy](/docs/security/waf-rulesets/#waf-policies) controls how Edge inspects client WebSocket messages, gRPC messages and large request bodies on the routes it reaches. Inspection requires an applicable active ruleset. The ordinary request-body mode does not turn off WebSocket or binary gRPC inspection; the WebSocket switch is separate. Start in Detection and review [WAF detections](/docs/security/waf-detections/) before promoting to Prevention. ## GraphQL request bodies A JSON request body whose `query` string parses as a GraphQL document is inspected as GraphQL. Injection rules check each argument value and variable default instead of the raw query text, so ordinary field selections such as `user(id: "1") { name }` do not look like SQL or shell syntax. Variables in the `variables` object remain JSON values. If the query contains `#` comments, fails to parse or exceeds a GraphQL limit, the raw query string stays inspected as a JSON value as well. ## WebSocket, gRPC and large bodies ### WebSocket messages With **Inspect WebSocket messages** on, each client message is inspected separately against the WAF policy captured when the connection opened. In Prevention, a blocking message closes the connection with status **1008** and records `ConnectionClosed`; Detection records findings and forwards the message. Messages larger than **Maximum WebSocket message bytes** are inspected up to that cap and raise `websocket-message-too-large`. Inspected routes remove `permessage-deflate` negotiation. Upstream-to-client WebSocket messages pass through. ### gRPC streams Edge inspects binary gRPC and binary gRPC-Web messages as they stream, without buffering or replaying the entire request. Protocol-buffer values are identified by field-number paths, without requiring a schema. Text-mode base64 gRPC-Web is outside this binary message parser. Each message is inspected up to **Maximum gRPC message bytes**. Messages beyond **Inspected gRPC messages** pass through and raise `grpc-messages-uninspected`. Scores accumulate within the request, and a rule scores once even if later messages also match it. A Prevention block returns HTTP 200 with `grpc-status: 7` before the response starts; an already-started response is aborted. For plain-HTTP gRPC upstreams, select **HTTP/2** in the cluster's **Upstream protocol** setting. It forces HTTP/2, including prior-knowledge h2c. **Auto** keeps normal protocol negotiation. ### Bodies above the limit For **Bodies above the limit**, **Block** rejects an oversized body in Prevention. **Inspect prefix** inspects the available prefix, raises `body-inspection-truncated` when inspection is truncated, and forwards the remaining original bytes. Structured parsing stops at the policy's body limit. Active ruleset profiles can lower the effective body limit when the action is Block. With **Disk spool**, raw windows and multipart inspection can continue up to **Maximum spooled inspection bytes**, subject to the normal parser and raw-character limits. Disk spooling bounds retained inspection data; it does not require the whole body to fit in memory. Explicit inspection work-budget exhaustion still fails closed when the policy can block. ### Container labels Docker-discovered routes set these options with the `clearplane.proxy.waf.request-body.*`, `waf.websocket.*` and `waf.grpc.*` labels and `clearplane.proxy.upstream.protocol`. See the [configuration catalog](/docs/configuration/catalog/#proxy-directives) for the full route configuration. ## Responses With **Response inspection** set to **Headers**, Edge inspects the upstream status and headers before sending them. **Headers and body** also holds inspectable bodies until inspection finishes. This adds the time needed to receive and inspect the buffered body before the client sees it. Start in Detection to review matches before enabling Prevention. Up to **Maximum response body bytes**, Edge buffers `text/*`, JSON (`application/json` and `+json` types), XML (`application/xml` and `+xml` types), and JavaScript (`application/javascript` or `application/x-javascript`). Other content types receive status and header inspection only. Upstream-compressed bodies are decompressed for inspection within the [Firewall decoding limits](/docs/security/waf-detections/#firewall-settings); allowed responses retain their original encoded bytes. If response capture cannot reserve memory, a policy eligible to block can reject it before the response starts; Detection and already-started responses continue with the original bytes and a budget finding. A response denied capture admission is not cached. In Prevention, a fully buffered response that reaches the blocking threshold is replaced whole with Clearplane's block page. No byte of that upstream body reaches the client. Larger responses are inspected on a bounded prefix and their decision is logged only. Server-sent events (`text/event-stream`) and gRPC responses pass through immediately while Edge captures a bounded copy. Once streaming starts, response inspection cannot replace the response. Every response is a separate transaction that uses Combined scoring against the policy's **Response threshold**, regardless of its request scoring mode, with its paranoia levels. Only Prevention rulesets can contribute blocking scores under a policy in Prevention. Response inspection requires applicable active response rules, such as [`clearplane-data-leakage`](/docs/security/waf-data-leakage/). The dashboard warns when response inspection is enabled on routes but no active ruleset contains response rules. A Detection ruleset counts because its response findings are still scored and logged. Response inspection runs before cache storage and response compression. Cache hits reuse the inspected result; they are not inspected again. Changes to the response policy or active rulesets invalidate the applicable cache entries, and entries remain scoped to the originating request's method, path and origin. Background refreshes are inspected too. Block replacements and responses with a log-only decision that would have blocked are not stored. Docker-discovered routes use `clearplane.proxy.waf.response.inspection`, `response.threshold` and `response.maximum-body-bytes`. See [Targets](/docs/waf-reference/targets/) for the fields available at each inspection stage and [Facts and limits](/docs/waf-reference/facts-and-limits/) for parser outcomes and resource bounds. ================================================================================ DOCUMENT: Path traversal ruleset Human URL: /docs/security/waf-path-traversal/ ================================================================================ `clearplane-path-traversal` detects traversal sequences and sensitive path patterns. Level-2 supplements inspect traversal revealed by repeated URL decoding. ## Paranoia levels and compatibility File managers and developer tools may legitimately accept relative paths, dotfiles and source examples. The ruleset also flags same-origin redirect destinations containing encoded parent segments at level 2. Review level-1 findings and the additional level-2 decoding checks on those routes. A path match describes suspicious input; upstream path normalization and filesystem access controls remain application responsibilities. Start in Detection, review [detections](/docs/security/waf-detections/), and configure only the [exclusions](/docs/security/waf-exclusion-rulesets/) needed for the affected route and field. See the [measured coverage](/docs/security/waf-coverage/) for the exact tested payload hashes, missed detections and false-positive rates. [Ruleset operation](/docs/security/waf-rulesets/) explains activation, stages and rollback. ================================================================================ DOCUMENT: Protocol ruleset Human URL: /docs/security/waf-protocol/ ================================================================================ `clearplane-protocol` combines HTTP policy and evasion checks with parser and framing facts. In Prevention, a critical protocol finding reaches the default request threshold of 5. JSON, XML, GraphQL, multipart and decompression limits can therefore block a request whose remaining content cannot be inspected. ## Methods and content types A WAF policy can allow methods and request content types beyond the ruleset's policy. In the policy under **Firewall → WAF policies**, add **Additional allowed methods**, such as `PROPFIND` for WebDAV, and **Additional request content types**, such as `text/plain`. Docker-discovered routes use the `clearplane.proxy.waf.allowed-methods` and `clearplane.proxy.waf.allowed-request-content-types` labels. ## Paranoia levels and compatibility The default CRS charset, extension and restricted-header policies are opinionated. Review WebDAV, method overrides and uncommon media types before promotion. Inspect-prefix traffic can still block when a rule scores its truncation fact. Start in Detection, review [detections](/docs/security/waf-detections/), and configure only the [exclusions](/docs/security/waf-exclusion-rulesets/) needed for the affected route and field. See the [measured coverage](/docs/security/waf-coverage/) for the exact tested payload hashes, missed detections and false-positive rates. [Ruleset operation](/docs/security/waf-rulesets/) explains activation, stages and rollback. ================================================================================ DOCUMENT: WAF rulesets Human URL: /docs/security/waf-rulesets/ ================================================================================ Clearplane ships no WAF ruleset and has no built-in fallback. A [WAF policy](#waf-policies) does not supply rules. If no compatible ruleset is active, the WAF inspects nothing; Clearplane shows an attention item when an enabled WAF policy covers routes in that state. ## Ruleset releases Each ruleset has its own current release, identified by a ruleset ID and [version](/docs/waf-reference/ruleset-format/#top-level-fields). Several rulesets can be active together. Activating a new version replaces the current version of that identity while keeping other rulesets active. Installing a release alone does not change inspection. Signed releases arrive through [Cloud ruleset updates](#cloud-ruleset-updates). Operators can [write and test custom rules](/docs/guides/write-custom-waf-rules/) in rulesets of their own. ## First release candidate The first content release covers eight category rulesets. These are reviewed candidate drafts; production publication is pending. | Ruleset | Coverage and compatibility guidance | |---|---| | `clearplane-protocol` | [HTTP policy, framing and incomplete inspection](/docs/security/waf-protocol/) | | `clearplane-scanners` | [Known scanner signatures](/docs/security/waf-scanners/) | | `clearplane-sql-injection` | [SQL syntax and fingerprints](/docs/security/waf-sql-injection/) | | `clearplane-xss` | [Cross-site scripting](/docs/security/waf-xss/) | | `clearplane-command-injection` | [Shell and command injection](/docs/security/waf-command-injection/) | | `clearplane-path-traversal` | [Traversal and sensitive paths](/docs/security/waf-path-traversal/) | | `clearplane-api-schema` | [Configured API-schema violations](/docs/security/waf-api-schema/) | | `clearplane-data-leakage` | [Response disclosure](/docs/security/waf-data-leakage/) | ## Which rulesets apply to a route Every active, compatible ruleset applies to every route with an effective WAF policy, unless that policy opts out of its ruleset ID. The policy chooses the **Standard** or **Management** profile from each applicable ruleset. Rulesets of kind `Exclusion` require an explicit policy opt-in; activation alone never selects them. See [exclusion rulesets](/docs/security/waf-exclusion-rulesets/) before enabling application-specific exceptions. For Docker-discovered routes, use `clearplane.proxy.waf.opt-out-rulesets` for ruleset IDs to skip and `clearplane.proxy.waf.exclusion-rulesets` for Exclusion IDs to select. See the [configuration catalog](/docs/configuration/catalog/#proxy-directives). The WAF policy API expresses opt-outs through `RulesetOverrides` entries with `RulesetId` and `OptedOut`, Exclusion opt-ins through `ExclusionRulesets`, and the policy extensions through `AllowedMethods` and `AllowedRequestContentTypes`. Each rule reference includes both its ruleset ID and rule ID, so an exclusion cannot accidentally target a same-numbered rule in another ruleset. ## Route mode and ruleset stage {#route-mode-and-ruleset-stage} A ruleset's stage and the mode of the route's WAF policy jointly determine whether its matches can contribute to blocking. A route without an effective WAF policy is not inspected. | Policy mode | Ruleset stage | Effective mode | |---|---|---| | Detection | Detection or Prevention | Detection; findings only | | Prevention | Detection | Detection; findings only | | Prevention | Prevention | Prevention; eligible scores can block | An opted-out ruleset is always Off for that policy's routes. Read [scoring and paranoia levels](/docs/security/waf-scoring-and-paranoia/) for how eligible scores reach a blocking decision. ## Operate rulesets Open **Firewall → Rulesets** to see each ruleset's source, kind, current version, stage, update strategy and last update. Operators with **WAF rulesets: Manage** can: - **Activate version** — choose an installed release and start it in Detection or Prevention. The dialog lists incompatible releases but prevents selecting them. - **Promote** — move the current release from Detection to Prevention. - **Roll back** — restore the previous verified release at its last stage. - **Deactivate** — stop the ruleset on every route. - **Update strategy** — save a per-ruleset Cloud update preference or follow the system default. Custom rules have no update strategy. The preference takes effect when WAF ruleset updates are enabled under Settings → Cloud. - **Open a ruleset** — browse its current rules, see which rules are disabled and disable or restore an individual rule. Moving a ruleset to a resource group requires **WAF rulesets: Write**. Read permission allows browsing without exposing signed envelopes, rule patterns, or signatures. Copying a rule into a custom draft requires **WAF rulesets: Manage** and does expose that rule's patterns, since the copy is editable. See [write custom WAF rules](/docs/guides/write-custom-waf-rules/). Activation actions include the generation shown by the page. If another operator changes activation state first, the action is refused and the page reloads. Check the new state before trying again. ## Disable a ruleset rule A rule that is wrong for every application does not need disabling route by route. Open the ruleset from the Rulesets page, find the rule and select **Disable rule**. Operators need **WAF rulesets: Manage** to disable or restore rules. The disabled rule is inactive on every route that uses the ruleset, and a WAF policy cannot turn it back on. Select **Restore** in the ruleset to let each policy's settings apply again. The change reaches the gateway with the next configuration apply. Each entry shows its current state: - **Disabled** — the rule is in the active release and inactive on every route. - **Rule changed since** — the release changed this rule after it was disabled. The entry stays applied, because rule identifiers are only unique within a ruleset version and a later release can retire and reuse one. Review it and re-add it against the current release if the rule still deserves to be off. - **Not in this release** — the active release no longer contains that rule. The entry is kept and has no effect. - **Ruleset inactive** — the whole ruleset is deactivated, so nothing from it is inspecting traffic. To silence a noisy rule on one application rather than everywhere, use its WAF policy's disabled rules and target exclusions instead, described under [WAF policies](#waf-policies). ## Rule memory Compiled rules live in the gateway's memory, and each ruleset costs a different amount. The **Rule memory** panel on the Rulesets page shows what the running rulesets currently use, what the gateway has available, the threshold above which a change is refused, and the measured cost of each installed ruleset. Before compiling a new set of rulesets, Edge projects what they will cost and compares it against the threshold. A configuration revision whose rulesets would not fit is refused: the revision fails, the previously published rulesets keep serving traffic, and no request goes uninspected. A revision that changes no ruleset content is never refused, because nothing has to be compiled. If a change is refused, opt WAF policies out of rulesets their routes do not need, deactivate a ruleset, or give the Edge container more memory and restart it. `CLEARPLANE_EDGE_BOOTSTRAP_WAF_MEMORY_ADMISSION_PERCENT` adjusts the threshold; see the [configuration catalog](/docs/configuration/catalog/). Raising it trades safety margin for capacity. ## Cloud ruleset updates With **WAF ruleset updates** on under **Settings → Cloud**, Core checks Cloud periodically. You can also select **Check now** above the ruleset list. The panel shows when the last check ran and, if it failed, a short error code such as `manifest-unavailable`. Installed rulesets keep enforcing whatever the result. Core downloads each new release, verifies it against the signing keys built into this Clearplane version, and installs it. Edge receives verified rulesets from Core and holds no signing keys. `CLEARPLANE_CORE_BOOTSTRAP_WAF_RULESET_SIGNING_KEYS` pins different keys; see the [configuration catalog](/docs/configuration/catalog/). The ruleset's update strategy then decides whether the release becomes current. Automatic updates never reactivate a ruleset you deactivated and never demote one you promoted. The version column shows **Cloud offers** when a newer release is waiting, for example under Manual. It shows **Withdrawn by Cloud** when Cloud withdrew the current release but the fallback was not applied, and **No longer offered** when Cloud stopped listing a ruleset, which keeps enforcing. Every automatic activation appears on the dashboard's attention list. If a release is withdrawn, Cloud offers a compatible replacement and reports the withdrawn version explicitly. Under Manual, Clearplane reports the withdrawal for operator action; automatic strategies can apply the replacement at the current stage. Cloud refuses withdrawal when it would leave installations without a compatible fallback. See [Cloud data and consent](/docs/operations/change-apply-configuration/#cloud-integration-error-reporting-and-installation-id) for what each request sends and which delivery records Cloud retains. ## WAF policies {#waf-policies} A WAF policy holds a route's complete firewall configuration: mode, profile, scoring, paranoia levels, ruleset opt-outs and exclusions, body, stream and response inspection, bot challenges, an optional [API schema](/docs/guides/validate-api-schemas/) and what [detections record](/docs/security/waf-detections/#request-context-and-redaction). Manage policies under **Firewall → WAF policies**; you need **WAF policies: Read** to view them, **Write** to create and edit them, and **Manage** to delete them. The API is `/api/waf-policies` on the management API route. Like other [policy families](/docs/concepts/policies-and-scope/#route-policy-state), a policy is Global or Route, and each route has a WAF state. **Inherit** uses the enabled Global policy, **On** uses the route's own policy, and **Off** turns the WAF off for the route. A route that is On whose policy is disabled gets no WAF; it never falls back to the Global policy. A policy's mode is **Detection** or **Prevention**. **Routing → Proxy routes** shows each route's effective WAF mode, or Off. A new installation ships the Global policy **Default WAF** (`default-waf`) in Detection. It inspects nothing until a ruleset is active, and the attention list warns about that. Clear the warning in one of three ways: - turn on **Cloud integration** and **WAF ruleset updates** under **Settings → Cloud** to download the Clearplane rulesets; - publish a [custom ruleset](/docs/guides/write-custom-waf-rules/); - disable **Default WAF** and every other enabled WAF policy. The editor lists the routes a policy reaches; a Global policy reaches every route that inherits the WAF. Saving a Prevention policy whose reach grows asks you to confirm the routes it will block on. The editor lists active rulesets and their stages. You can opt out of a ruleset or set its threshold for Per ruleset scoring. Exclusion rulesets are listed separately for explicit opt-in. **Additional allowed methods** and **Additional request content types** extend the [protocol ruleset's](/docs/security/waf-protocol/#methods-and-content-types) method and content-type policy for the policy's routes only. **Disabled rules** and **target exclusions** identify both a ruleset and a rule. A target exclusion matches a target name exactly or by prefix. The editor warns about inactive rulesets, rules missing from the current release, targets a rule no longer inspects, and body limits above a ruleset's profile. These references remain editable and do not block saving a structurally valid policy. Container labels can [create an inline policy](/docs/configuration/docker-labels/#proxy-waf) for a discovered route. Its labelled settings are read-only here, but its disabled rules, target exclusions and per-ruleset thresholds stay editable, and discovery keeps them. ## Release changes and rollback Release changes do not invalidate a saved WAF policy. References to inactive rulesets, retired rules, or retired targets become policy warnings. Those references remain saved; they have no effect while their targets are absent. If a release lowers its body-size limit, inspection uses the lower limit and records a warning. Malformed policy settings, such as an invalid threshold, are still rejected. A current release that needs a newer Clearplane version is skipped without stopping other compatible rulesets or configuration changes. Clearplane retains the release and shows **WAF rulesets need a newer Clearplane version** as an attention item. A release signed by a key Core no longer trusts is skipped the same way, marked **Untrusted signing key** and reported as **WAF rulesets are signed by a key this installation no longer trusts**. Check active versions and stages after a change, then use [WAF detections](/docs/security/waf-detections/) to see which rulesets actually matched traffic. Core retains activation history per ruleset. **Roll back** selects that identity's previous verified release and restores its last stage; it leaves other rulesets in place. A rollback requires a previous release in that ruleset's own history. For release JSON and profile fields, see [Ruleset format](/docs/waf-reference/ruleset-format/). ================================================================================ DOCUMENT: Scanners ruleset Human URL: /docs/security/waf-scanners/ ================================================================================ `clearplane-scanners` recognizes known automated scanner identifiers in request headers. These signatures identify tool names; a client can change or omit its user agent. This ruleset does not establish whether an unidentified client is human. ## Paranoia levels and compatibility Start at paranoia level 1 and review monitoring tools and authorized vulnerability scanners. Scope any exception to the authorized route or client policy. The scoped application profiles do not disable scanner detection. Start in Detection, review [detections](/docs/security/waf-detections/), and configure only the [exclusions](/docs/security/waf-exclusion-rulesets/) needed for the affected route and field. See the [measured coverage](/docs/security/waf-coverage/) for the exact tested payload hashes, missed detections and false-positive rates. [Ruleset operation](/docs/security/waf-rulesets/) explains activation, stages and rollback. ================================================================================ DOCUMENT: WAF scoring and paranoia levels Human URL: /docs/security/waf-scoring-and-paranoia/ ================================================================================ A matching scoring rule adds its score once per transaction. Request metadata and body share a transaction; WebSocket messages and responses have separate transactions. Challenge actions add no score. Several rules can score the same request, including rules from different rulesets. The scoring mode determines whether eligible scores combine across rulesets or each ruleset must reach its own threshold. ## Choose a scoring mode Each [WAF policy](/docs/security/waf-rulesets/#waf-policies) sets its own **Scoring mode** under **Firewall → WAF policies**, or through the policy API's `ScoringMode` field. New policies use Combined. Apply the staged configuration to Edge after saving. | Mode | Blocking decision | Use it when | |---|---|---| | Combined | Add blocking scores from all applicable rulesets and compare the sum with the policy threshold. | Evidence spread across rulesets should contribute to one decision. | | Per ruleset | Compare each ruleset's blocking score with its own threshold; any one reaching its threshold can block. | Each ruleset should reach a decision independently. | Set **Blocking threshold** in the policy editor, the policy API's `Threshold`, or the Docker label `clearplane.proxy.waf.threshold`. It defaults to 5. Higher thresholds require more score before blocking. In **Per ruleset** mode, set an individual threshold in the policy's ruleset overrides editor or with `ThresholdOverride` in that ruleset's `RulesetOverrides` API entry. The combined threshold and Docker threshold label do not replace these individual thresholds. Profiles select rules and inspection limits, not thresholds. For example, two rulesets each contribute a blocking score of 3. Combined mode blocks at a threshold of 5. Per ruleset mode with both thresholds at 5 does not block, because neither ruleset reaches its threshold. ## Blocking and detection scores **Blocking score** contains matches eligible to block: the route's WAF policy is in Prevention, the ruleset is in Prevention, and the rule is within the policy's paranoia level. **Detection score** contains scored matches outside those conditions. Detection scores never help a Prevention ruleset cross a blocking threshold. A Prevention ruleset scoring 3 and a Detection ruleset scoring 3 therefore produce a blocking score of 3 and detection score of 3. They do not block at a threshold of 5, even in Combined mode. Activation lets you choose Detection or Prevention; see [ruleset stages](/docs/security/waf-rulesets/#route-mode-and-ruleset-stage). ## Paranoia levels A WAF policy's **paranoia level** selects rules from levels **1–4**, up to the selected level. Higher levels include more rules from the selected profiles and can produce more false positives. The optional **detection paranoia level** lets additional levels run for observation. Leaving it unset runs only through the policy's paranoia level. For example, paranoia level 1 with detection paranoia level 2 runs levels 1 and 2. Eligible level-1 matches can add blocking score; level-2 matches add only detection score. Review these findings before raising the paranoia level. The policy editor sets both levels. Its detection-level selector offers levels above the paranoia level; the API fields `ParanoiaLevel` and `DetectionParanoiaLevel` also accept equal levels, which adds no extra rules. Use [WAF detections](/docs/security/waf-detections/) to inspect the separate scores and the ruleset evaluations behind a request's decision. ## Container labels A Docker-discovered route's inline WAF policy uses `clearplane.proxy.waf.scoring-mode`, `clearplane.proxy.waf.paranoia-level` and `clearplane.proxy.waf.detection-paranoia-level`, alongside the required `clearplane.proxy.waf.mode`. Container labels do not set per-ruleset thresholds; set them on the inline policy under **Firewall → WAF policies**. See the [configuration catalog](/docs/configuration/catalog/#proxy-directives) for the complete list. See [Scoring and integrity tests](/docs/waf-reference/scoring-and-integrity-tests/) for response thresholds, Challenge actions and how rule authors test their releases. ================================================================================ DOCUMENT: SQL injection ruleset Human URL: /docs/security/waf-sql-injection/ ================================================================================ `clearplane-sql-injection` inspects selected request fields for SQL injection syntax, database functions and fingerprint matches. The protocol ruleset supplies complementary inspection-limit protection. ## Paranoia levels and compatibility SQL editors, query-building APIs and documentation search can legitimately contain SQL syntax. A full SQL statement in an ordinary parameter can reach the blocking threshold at level 1. Higher paranoia levels add matches. Use a reviewed target exclusion for a trusted field and verify attack controls outside that field before promotion. Start in Detection, review [detections](/docs/security/waf-detections/), and configure only the [exclusions](/docs/security/waf-exclusion-rulesets/) needed for the affected route and field. See the [measured coverage](/docs/security/waf-coverage/) for the exact tested payload hashes, missed detections and false-positive rates. [Ruleset operation](/docs/security/waf-rulesets/) explains activation, stages and rollback. ================================================================================ DOCUMENT: Cross-site scripting ruleset Human URL: /docs/security/waf-xss/ ================================================================================ `clearplane-xss` detects script markup, event handlers, dangerous URI schemes and related browser injection patterns in selected request fields. Detection depends on the supplied field and document context; it is not a browser execution or output-encoding check. ## Paranoia levels and compatibility Rich-text editors, HTML examples and code uploads can match at level 1. Level 2 adds stricter patterns, including bounded checks for script markup, legacy HTML data binding, remote HTML imports and split JavaScript schemes when an XML body cannot be parsed completely. Review the coverage report and use narrowly scoped target exclusions for trusted authoring fields. Start in Detection, review [detections](/docs/security/waf-detections/), and configure only the [exclusions](/docs/security/waf-exclusion-rulesets/) needed for the affected route and field. See the [measured coverage](/docs/security/waf-coverage/) for the exact tested payload hashes, missed detections and false-positive rates. [Ruleset operation](/docs/security/waf-rulesets/) explains activation, stages and rollback. ================================================================================ DOCUMENT: Detectors and patterns Human URL: /docs/waf-reference/detectors-and-patterns/ ================================================================================ ## What the engine and ruleset each own | Engine | Ruleset | |---|---| | Tokenizer grammar, token fields, contexts and option validation. | Keyword lexicons and reusable value lists. | | Bounded pattern compiler and matcher. | Token patterns, predicates and diagnostic reasons. | | SQL and HTML fingerprint interpretation. | Fingerprint lexicons, fingerprint lists and reported reason. | | Work budgets and version checks. | Rule targets, transformations, score and detector selection. | The available grammar is listed in [Tokenizers](/docs/waf-reference/tokenizers/). A ruleset can add words and patterns without adding executable tokenizer code. ## Lists and lexicons A `lists` entry has an `id` and non-empty `values`. A ruleset can contain up to 64 lists, each with at most 16,384 values of at most 256 characters. Operators and pattern predicates refer to lists by ID within the same ruleset. A `lexicons` entry has an `id`, `tokenizer` and `entries`, mapping a word to up to eight classes. There can be at most 16 lexicons and 16,384 entries per lexicon. In pattern mode, class names match `[A-Z][A-Za-z0-9]*` and cannot replace tokenizer grammar classes. SQL fingerprint lexicons instead use the permitted libinjection type letters. A lexicon cannot mix incompatible uses. ## Detector definitions A detector declares `id`, `tokenizer`, `mode`, optional `lexicon`, and optional `options`. `Patterns` mode requires a non-empty `patterns` array and forbids fingerprint fields. `Fingerprint` mode uses `fingerprints` to name a list and requires `fingerprintReason`; it has no patterns. The tokenizer determines whether fingerprint mode is available and which options and contexts are valid. There can be up to 32 detectors, 256 patterns per detector, 16 steps per pattern and four captures per pattern. A fingerprint list is subject to the 16,384-value list bound. These are admission limits; runtime [work budgets](/docs/waf-reference/facts-and-limits/) still apply. A rule calls a same-ruleset detector with `operator: { "kind": "Detect", "value": "detector-id" }`. `Detect` accepts only its supported untrusted value targets, not arbitrary facts or metadata. It cannot be negated and cannot take `values`, `number`, `list` or an operand. [Operators](/docs/waf-reference/operators/) and [Targets](/docs/waf-reference/targets/) describe the available surface. ## Pattern language Each pattern has a diagnostic `reason` and a `sequence`. A step’s `class` array is a choice of grammar or lexicon classes. Without `repeat`, the step consumes one matching token; `?` makes it optional and `*` permits zero through 32 repetitions. At least one step must require a token. `capture` names a token for later predicates. `skip` permits listed token classes between steps. `reset` discards progress on listed classes. Without `anchor`, matching can begin later in the token stream; `anchor: "Start"` restricts the start. `where` on a step tests the token’s `text` or a field defined by its tokenizer. Supported checks are membership in a named list (`in`), literal `prefix` with optional `minLength`, a list-driven `prefixAnyIgnoringWhitespace`, `startsWithAny`, or `nonBlank`. Pattern-level `where` compares captures with `same`, or tests a capture’s class using `class`. Captures and their references must be valid at compilation. See the [SQL, XSS and shell examples](/docs/waf-reference/examples/) for complete syntax. ## Matching and cost The compiled automaton processes tokens without regex-style backtracking. It reports a pattern completing at the earliest token; simultaneous completions use pattern list order. Detector contexts run in configured order until one matches. Tokenization cost is charged for each attempted context, and pattern work is charged as tokens multiplied by compiled positions. Fingerprint mode implements the pinned libinjection v4.0.0-compatible SQL and XSS decisions. Compatibility describes that algorithm, not proof that every injection is detected. The [third-party notices](/docs/security/third-party-notices/) give its license, and [protection coverage](/docs/security/waf-coverage/) reports the measured coverage results. ================================================================================ DOCUMENT: Examples Human URL: /docs/waf-reference/examples/ ================================================================================ The seed fragments below are copied from the compiler-tested category fixtures. They illustrate the rule language. Fragments belong inside the corresponding top-level collection, rather than being complete rulesets. ## SQL union-select The SQL detector recognizes the `sql-union-select` sequence, permits comments, and resets that sequence at a semicolon. Its `sql-keywords` lexicon supplies `Union`, `Select` and the other word classes. Both objects are from `clearplane-sql-injection`. ```json {"id": "sql-keywords", "tokenizer": "Sql", "entries": { "union": ["Union"], "select": ["Select"], "all": ["All"], "distinct": ["Distinct"], "or": ["Boolean"], "and": ["Boolean"], "like": ["Like"], "sleep": ["DelayFunction"], "benchmark": ["DelayFunction"], "pg_sleep": ["DelayFunction"], "waitfor": ["Waitfor"], "delay": ["Delay"], "drop": ["StackedVerb"], "delete": ["StackedVerb"], "insert": ["StackedVerb"], "update": ["StackedVerb"], "exec": ["StackedVerb"], "execute": ["StackedVerb"], "create": ["StackedVerb"], "alter": ["StackedVerb"]}} ``` ```json {"id": "sql-injection", "tokenizer": "Sql", "mode": "Patterns", "lexicon": "sql-keywords", "options": {"contexts": ["AsIs", "FoldQuotes"], "versionedCommentDigits": 6}, "patterns": [ {"reason": "sql-stacked-statement", "skip": ["Comment"], "sequence": [{"class": ["Semicolon"]}, {"class": ["StackedVerb"]}]}, {"reason": "sql-union-select", "skip": ["Comment"], "reset": ["Semicolon"], "sequence": [{"class": ["Union"]}, {"class": ["Union", "All", "Distinct", "LeftParenthesis"], "repeat": "*"}, {"class": ["Select"]}]}, {"reason": "sql-time-delay", "skip": ["Comment"], "sequence": [{"class": ["DelayFunction"]}, {"class": ["LeftParenthesis"]}]}, {"reason": "sql-time-delay", "skip": ["Comment"], "sequence": [{"class": ["Waitfor"]}, {"class": ["Delay"]}]}, {"reason": "sql-boolean-tautology", "skip": ["Comment", "LeftParenthesis", "RightParenthesis"], "sequence": [{"class": ["Boolean"]}, {"class": ["Word", "Number", "String"], "capture": "l"}, {"class": ["Equal", "Like"]}, {"class": ["Word", "Number", "String"], "capture": "r"}], "where": [{"same": ["l", "r"]}]}, {"reason": "sql-boolean-tautology", "skip": ["Comment", "LeftParenthesis", "RightParenthesis"], "sequence": [{"class": ["Boolean"]}, {"class": ["Number"]}, {"class": ["Comparison"]}, {"class": ["Number"]}]} ]} ``` A rule calls this detector with `operator: { "kind": "Detect", "value": "sql-injection" }`. For example, the seed’s metadata rule matches `1 UNION/**/SELECT secret FROM accounts` after its configured transformations. ## XSS event-handler attribute This pattern from the `clearplane-xss` HTML detector recognizes an attribute whose name starts with `on`, has at least three characters and has a value. `` exercises it. ```json {"reason": "xss-event-handler", "sequence": [{"class": ["Attribute"], "where": [{"field": "name", "prefix": "on", "minLength": 3}, {"field": "hasValue", "nonBlank": true}]}]} ``` ## Command substitution This pattern from `clearplane-command-injection` recognizes a non-blank shell substitution such as `$(id)`. It runs in the Shell tokenizer’s Command context. ```json {"reason": "command-substitution", "sequence": [{"class": ["Substitution"], "where": [{"field": "nonBlank", "nonBlank": true}]}]} ``` ## Path traversal This complete rule from `clearplane-path-traversal` uses bounded `SafeRegex` after decoding and normalization. Its reason is `path-traversal-sequence`; `../private/example` matches. ```json { "id": 1930100, "revision": 1, "message": "Path traversal attempt in request metadata", "description": "Clearplane deterministic built-in request inspection rule.", "category": "path-traversal", "severity": "Critical", "score": 5, "paranoiaLevel": 1, "action": "Score", "tags": ["attack-lfi", "attack-path-traversal"], "provenance": {"kind": "ClearplaneOriginal", "source": "Clearplane", "license": "Proprietary", "sourceVersion": "1.0.0", "sourceRuleId": "GK-1930100"}, "inspectionStage": "RequestMetadata", "conditions": [{"targets": [{"target": "RawPath"}, {"target": "NormalizedPath"}, {"target": "QueryValue"}], "transformations": ["UriDecode", "UriDecode", "HtmlEntityDecode", "UnicodeNormalize", "RemoveNulls", "Lowercase"], "scope": "AllFields", "operator": {"kind": "SafeRegex", "value": "\\.\\.[/\\\\]"}, "reasonCode": "path-traversal-sequence"}], "diagnosticMetadata": {"detectorRevision": "2"} } ``` ## Protocol anomaly This rule from `clearplane-protocol` scores the application-visible `upgrade-h2c` anomaly. It matches a fact emitted by protocol inspection, rather than parsing the Upgrade header itself. ```json { "id": 1920107, "revision": 1, "message": "Application-visible HTTP protocol anomaly: upgrade-h2c", "description": "Clearplane deterministic built-in request inspection rule.", "category": "protocol", "severity": "Critical", "score": 5, "paranoiaLevel": 1, "action": "Score", "tags": ["attack-protocol"], "provenance": {"kind": "ClearplaneOriginal", "source": "Clearplane", "license": "Proprietary", "sourceVersion": "1.0.0", "sourceRuleId": "GK-1920107"}, "inspectionStage": "RequestMetadata", "conditions": [{"targets": [{"target": "ProtocolAnomaly"}], "transformations": [], "scope": "AllFields", "operator": {"kind": "Equal", "value": "upgrade-h2c"}, "reasonCode": "upgrade-h2c"}], "diagnosticMetadata": {"detectorRevision": "2"} } ``` ## Challenge a login path This complete local ruleset requests a challenge for `/login`. Its configured score remains valid for Critical severity, but the Challenge action adds zero to the transaction’s score. Enable [bot challenges](/docs/guides/bot-challenges/) on the HTTPS route and publish to Prevention before eligible requests can be challenged. Existing clearance and normal WAF blocking still apply. ```json { "rulesetId": "local", "version": "1.0.0", "schemaVersion": 1, "kind": "Application", "minimumClearplaneVersion": "1.0.0-alpha4", "releasedAt": "2026-09-12T00:00:00+00:00", "provenance": { "source": "Operator", "license": "Proprietary" }, "profiles": [ { "id": "standard", "revision": 1, "name": "Standard", "ruleIds": [ 2 ], "limits": {} }, { "id": "management", "revision": 1, "name": "Management", "ruleIds": [ 2 ], "limits": {} } ], "rules": [ { "id": 2, "revision": 1, "message": "Custom inspection example", "description": "A small example for the WAF rule language reference.", "category": "custom", "severity": "Critical", "score": 5, "paranoiaLevel": 1, "action": "Challenge", "provenance": { "kind": "ClearplaneOriginal", "source": "Operator", "license": "Proprietary" }, "inspectionStage": "RequestMetadata", "conditions": [ { "targets": [ { "target": "NormalizedPath" } ], "operator": { "kind": "Equal", "value": "/login" } } ] } ], "integrityTests": [ { "id": "login", "profileId": "standard", "method": "GET", "path": "/login", "fields": [], "expectedMatchedRuleIds": [ 2 ] }, { "id": "other-path", "profileId": "management", "path": "/account", "fields": [], "expectedMatchedRuleIds": [] } ] } ``` ## Exclude a WordPress editor field This Exclusion ruleset removes only the `content` query field from rule `1941100` in `clearplane-xss`, for POST requests whose normalized path starts with `/wp-admin/`. It does not exempt other rules or body fields. Adapt the target and field to the traffic your editor actually sends, and opt the route's WAF policy into the exclusion ruleset. Exclusion definitions are shown for release authors; **Custom rules** publishes the local Application ruleset. The embedded vector verifies suppression on the selected path. Embedded exclusion vectors must expect at least one suppressed rule; test an outside path separately to confirm it remains protected. ```json { "rulesetId": "wordpress-editor", "version": "2026_09_19_10_00", "schemaVersion": 1, "kind": "Exclusion", "minimumClearplaneVersion": "1.0.0-alpha4", "releasedAt": "2026-09-12T00:00:00+00:00", "provenance": { "source": "Operator", "license": "Proprietary" }, "profiles": [], "rules": [], "exclusions": [ { "id": "editor-html", "rulesetId": "clearplane-xss", "ruleId": 1941100, "target": "QueryValue", "name": { "exact": "content" }, "pathPrefix": "/wp-admin/", "methods": [ "POST" ] } ], "integrityTests": [ { "id": "editor-content", "profileId": "standard", "rulesetId": "clearplane-xss", "method": "POST", "path": "/wp-admin/post.php", "fields": [ { "target": "QueryValue", "name": "content", "value": "" } ], "expectedMatchedRuleIds": [], "expectedSuppressedRuleIds": [ 1941100 ] } ] } ``` ================================================================================ DOCUMENT: Facts and limits Human URL: /docs/waf-reference/facts-and-limits/ ================================================================================ Parsers report facts and measures as fields, so rules score them like any other target. Parser-specific limits can emit the facts listed below and preserve parsed fields. Exhausting a transaction work budget stops further evaluation; the route’s enforcement mode determines the outcome. ## ProtocolAnomaly | Name | Description | |---|---| | `absolute-form-host-mismatch` | An absolute-form request target named a host other than the Host header. | | `conflicting-content-length` | Content-Length values were not unsigned decimal integers or differed in their text representation. | | `content-length-transfer-encoding-conflict` | A request carried both Content-Length and Transfer-Encoding. | | `decompression-failed` | A compressed body could not be decompressed, so its raw bytes were inspected. Requests emit ProtocolAnomaly with this value; responses emit ParserFact with this name. Decoded body inspection remains incomplete. | | `encoded-request-body` | The body declared a Content-Encoding other than identity. | | `hop-by-hop-header-abuse` | The Connection header named a token outside the supported connection-token allowlist. | | `malformed-cookie-header` | A Cookie header segment had an empty name or no equals sign. | | `malformed-percent-encoding` | The raw path or query contained an invalid percent escape. | | `malformed-query` | The query string could not be parsed. | | `unsupported-charset` | The body declared a charset Edge cannot decode, so it was inspected as bytes. | | `upgrade-h2c` | The request asked for an h2c upgrade or carried an HTTP2-Settings header. | ## ParserFact | Name | Description | |---|---| | `body-inspection-truncated` | A request body, protobuf message or response was inspected only in part. | | `decompression-limit-exceeded` | Decompression reached the size or ratio limit; the decompressed prefix is inspected. | | `duplicate-json-key` | A JSON object repeated a property name. | | `duplicate-parameter-name` | A query, URL-encoded form or multipart field name occurred more than once. | | `graphql-limit-exceeded` | GraphQL parsing reached a structural limit; fields already parsed remain available within the work budget. | | `grpc-messages-uninspected` | The gRPC per-request inspection count was reached; later messages are outside payload inspection. | | `json-limit-exceeded` | JSON parsing reached a structural limit; fields already parsed remain available within the work budget. | | `jwt-empty-signature` | A compact JWS had an empty signature segment. | | `jwt-zero-signature` | A compact JWS had a signature of zero bytes only. | | `multipart-limit-exceeded` | Multipart parsing or archive inspection reached a structural limit; retained fields remain available. | | `route-allowed-content-type` | The request has one Content-Type header whose media type is in the route's additional allowed request content types. The value is the lowercase media type. | | `route-allowed-method` | The route's additional allowed methods include the request method. The value is the method. | | `schema-validation-limit-exceeded` | API schema validation could not finish within its input, estimated-work or runtime safety limits. | | `websocket-compressed-frame` | A compressed WebSocket message was observed and its payload was not inspected. | | `websocket-message-too-large` | A WebSocket message exceeded the configured cap, so only its retained prefix could be inspected. | | `xml-doctype` | An XML body declared a document type. | | `xml-external-entity` | An XML body declared an entity with a system or public identifier. | | `xml-limit-exceeded` | XML parsing reached a structural limit or stopped inspecting an unsafe DTD subset; retained fields remain available. | ## Measure | Name | Description | |---|---| | `archive-entries` | The number of entries in an uploaded zip archive's central directory. | | `args-combined-size` | The combined character length of query argument names and values, plus parsed body argument names or paths and values at the body stage. | | `args-count` | The number of query arguments, plus parsed body argument values when inspecting the body. | | `body-length` | The byte length seen by body inspection after applicable decompression and charset conversion. | | `files-combined-size` | The combined size of every uploaded file part. | | `graphql-aliases` | The number of GraphQL field aliases. | | `graphql-batch-size` | The number of operations in a GraphQL batch. | | `graphql-depth` | The deepest GraphQL selection nesting. | | `graphql-root-fields` | The number of root fields in GraphQL operations. | | `grpc-messages` | The one-based number of the gRPC message currently being inspected. | | `header-count` | The number of request headers. | | `jwt-signature-length` | The decoded length of a compact JWS signature. | | `protobuf-depth` | The deepest protobuf message nesting the wire walker reached. | | `xml-depth` | The deepest XML element nesting. | | `xml-entity-declarations` | The number of entities declared in the DTD. | ## SchemaViolation | Name | Description | |---|---| | `invalid-content-type` | The content type is not one the operation accepts. | | `invalid-type` | A parameter or JSON body failed schema validation other than a missing-required or forbidden-property check. | | `missing-required` | A required parameter or property is missing. | | `unknown-operation` | The path and method match no operation in the route's OpenAPI document. | | `unknown-parameter` | A query parameter is not declared by the operation. | | `unknown-property` | A JSON property is forbidden by additionalProperties false or unevaluatedProperties false. | ## Work limits Profiles set these per ruleset; a transaction uses the largest value among applicable rulesets, capped by the engine maximum. Before merging, the `local` profile’s limits are capped at their defaults. JSON profile properties use camelCase, for example `maximumJsonDepth`. | Limit | Default | Engine maximum | Description | |---|---|---|---| | `MaximumInspectedValues` | 4,096 | 32,768 | Fields inspected in one transaction. | | `MaximumInspectedCharacters` | 2,500,000 | 8,388,608 | Characters inspected in one transaction, names included. | | `MaximumTransformationSteps` | 4,096 | 131,072 | Transformation steps in one transaction. | | `MaximumTransformationInputBytes` | 12,000,000 | 16,777,216 | Bytes entering transformations in one transaction. | | `MaximumTransformationOutputBytes` | 12,000,000 | 16,777,216 | Bytes produced by transformations in one transaction. | | `MaximumRegexInputCharacters` | 16,384 | 131,072 | Characters of one value a regular expression may scan. | | `MaximumFindings` | 32 | 256 | Findings kept per ruleset in one transaction. | | `MaximumBase64DecodedBytes` | 65,536 | 1,048,576 | Bytes one base64 transformation may produce. | | `MaximumTargetCharacters` | 65,536 | 1,048,576 | Characters in one field value or name. | | `MaximumTransformationCacheEntries` | 2,048 | 32,768 | Cached transformation results in one transaction. | | `MaximumOperatorInvocations` | 4,096 | 131,072 | Operator evaluations in one transaction. | | `MaximumOperatorInputValues` | 65,536 | 1,048,576 | Values passed to operators in one transaction. | | `MaximumOperatorInputCharacters` | 320,000,000 | 536,870,912 | Characters scanned by operators in one transaction. | | `MaximumRegexAttempts` | 256 | 4,096 | Regular-expression evaluations in one transaction. | | `MaximumRegexWorkUnits` | 100,000,000 | 4,000,000,000 | Estimated regular-expression work, based on input length and compiled pattern complexity, in one transaction. | | `MaximumJsonDepth` | 32 | 128 | JSON nesting depth. | | `MaximumJsonTokens` | 4,096 | 131,072 | JSON tokens in one body. | | `MaximumBodyFields` | 4,096 | 32,768 | Fields produced by one body, message or response parser invocation. | | `MaximumMultipartSections` | 128 | 4,096 | Parts in one multipart body. | | `MaximumMultipartHeaders` | 1,024 | 32,768 | Part headers in one multipart body. | | `MaximumFieldNameCharacters` | 1,024 | 65,536 | Characters in one body field name. | | `MaximumScalarCharacters` | 65,536 | 1,048,576 | Characters permitted in a structured scalar value or parser text item. | | `MaximumArgumentNameSegments` | 32 | 256 | Segments taken from one bracket or dot argument name. | | `MaximumJwtFields` | 64 | 1,024 | Header fields and claims taken from one JWT. | | `MaximumArchiveEntries` | 1,024 | 65,535 | Entries read from one zip central directory. | | `MaximumXmlDepth` | 64 | 256 | XML element nesting depth. | | `MaximumXmlNodes` | 16,384 | 1,048,576 | XML nodes in one body. | | `MaximumXmlAttributes` | 256 | 4,096 | Attributes on one XML element. | | `MaximumXmlEntityDeclarations` | 64 | 4,096 | Entity declarations read from one DTD. | | `MaximumGraphQlTokens` | 16,384 | 262,144 | Tokens in one GraphQL document. | | `MaximumGraphQlDepth` | 16 | 128 | GraphQL selection nesting depth. | | `MaximumGraphQlAliases` | 64 | 4,096 | Aliases in one GraphQL document. | | `MaximumGraphQlBatchSize` | 16 | 256 | Operations in one GraphQL batch. | | `MaximumProtobufDepth` | 16 | 64 | Nested protobuf messages the wire walker descends into. | | `MaximumSchemaValidationSteps` | 16,384 | 1,048,576 | Estimated schema-validation work shared by request parameters and the selected JSON body schema. | ## Resource settings These system settings are under **Settings → Firewall**. They bound decompression, uploaded-file content and overlapping raw-body scans; see [Inspected traffic](../../security/waf-inspected-traffic/) for the route-level controls. | Setting | Default | Description | |---|---|---| | `MaximumDecompressedBytes` | 16,777,216 | Bytes decompression may produce for one body or value, a system setting. | | `MaximumDecompressionRatio` | 100 | Output-to-input ratio decompression may reach, a system setting. | | `MaximumFileContentBytes` | 65,536 | Bytes of each file part inspected, a system setting. | | `MaximumRawBodyWindowCharacters` | 65,536 | Characters in each overlapping raw-body window, also bounded by MaximumTargetCharacters, a system setting. | | `MaximumRawBodyCharacters` | 1,048,576 | Distinct decoded characters emitted as raw-body fields before scanning stops, a system setting. | ================================================================================ DOCUMENT: Feature versions Human URL: /docs/waf-reference/feature-versions/ ================================================================================ A ruleset declares `minimumClearplaneVersion`. It must be at least the version that introduced every feature it uses, as listed here. Edge skips an active release that requires a newer Clearplane version, keeps the rest of the configuration and reports the incompatible release. This catalog describes engine compatibility, not availability of Cloud content. | Feature | Since | Description | |---|---|---| | `Method` (target) | 1.0.0-alpha4 | The request method, such as GET or POST. | | `Protocol` (target) | 1.0.0-alpha4 | The HTTP protocol version, such as HTTP/1.1 or HTTP/2. | | `Scheme` (target) | 1.0.0-alpha4 | The request scheme, http or https. | | `Host` (target) | 1.0.0-alpha4 | The Host value Edge received, including any port. | | `RawPath` (target) | 1.0.0-alpha4 | The raw request target before its query string, retaining percent escapes and any absolute-form URI. | | `NormalizedPath` (target) | 1.0.0-alpha4 | The path supplied by ASP.NET Core, including the request path base. | | `RawQuery` (target) | 1.0.0-alpha4 | The query string exactly as sent, without its leading question mark. | | `QueryName` (target) | 1.0.0-alpha4 | Each query parameter name, one field per occurrence. | | `QueryValue` (target) | 1.0.0-alpha4 | Each query parameter value, named by its parameter. | | `HeaderName` (target) | 1.0.0-alpha4 | Each request header name. | | `HeaderValue` (target) | 1.0.0-alpha4 | Each request header value, named by its header; header names compare case-insensitively. | | `CookieName` (target) | 1.0.0-alpha4 | Each cookie name from the Cookie header. | | `CookieValue` (target) | 1.0.0-alpha4 | Each cookie value, named by its cookie. | | `JsonFieldPath` (target) | 1.0.0-alpha4 | The path of each JSON scalar value, such as $.user.name. | | `JsonPropertyName` (target) | 1.0.0-alpha4 | Each JSON object property name, named by its full JSON path. | | `JsonScalarValue` (target) | 1.0.0-alpha4 | Each JSON string, number, boolean or null as text, named by its JSON path. A GraphQL request's query string that parses without comments is represented by GraphQL targets instead. | | `FormName` (target) | 1.0.0-alpha4 | Each URL-encoded form field name. | | `FormValue` (target) | 1.0.0-alpha4 | Each URL-encoded form field value, named by its field. | | `MultipartTextName` (target) | 1.0.0-alpha4 | The name of each multipart text part. | | `MultipartTextValue` (target) | 1.0.0-alpha4 | The content of each multipart text part, named by its part. | | `MultipartFieldName` (target) | 1.0.0-alpha4 | The form-data name of every multipart part, text or file. | | `MultipartFileName` (target) | 1.0.0-alpha4 | The file name a multipart file part declares. | | `MultipartContentType` (target) | 1.0.0-alpha4 | The content type a multipart part declares, named by its part. | | `ProtocolAnomaly` (target) | 1.0.0-alpha4 | A protocol anomaly Edge observed; the value is the anomaly name listed under Facts and limits. | | `RawBodyValue` (target) | 1.0.0-alpha4 | The decoded request body in overlapping text windows, bounded by the raw-body character setting and inspection budgets. | | `RequestLine` (target) | 1.0.0-alpha4 | The request line: method, raw target and protocol. | | `RequestBasename` (target) | 1.0.0-alpha4 | The last segment of the raw path. | | `BodyFormat` (target) | 1.0.0-alpha4 | The detected format of the ordinary request body, or None when it is empty. | | `MultipartPartHeaderName` (target) | 1.0.0-alpha4 | Each header name of each multipart part. | | `MultipartPartHeaderValue` (target) | 1.0.0-alpha4 | Each multipart part header value, named by its header with case-insensitive name comparisons. | | `MultipartFileContent` (target) | 1.0.0-alpha4 | The retained prefix of each file part, up to the file-content setting, with one character per byte. | | `MultipartArchiveEntryName` (target) | 1.0.0-alpha4 | Entry names from a zip file part's central directory; nothing is extracted. | | `ArgumentNameSegment` (target) | 1.0.0-alpha4 | Each segment of bracket or dot argument names, such as $ne in user[$ne]. | | `JsonValueKind` (target) | 1.0.0-alpha4 | The kind of each JSON value (object, array, string, number, boolean or null), named by its path. | | `JwtHeader` (target) | 1.0.0-alpha4 | Each header field of a compact JWS found in Authorization, cookies or parameters, named by field path. | | `JwtClaim` (target) | 1.0.0-alpha4 | Each claim of a compact JWS, named by claim path. | | `Measure` (target) | 1.0.0-alpha4 | A named number Edge computed, such as args-count; the name is the measure and the value the number. | | `ParserFact` (target) | 1.0.0-alpha4 | A parser observation whose name identifies the fact and whose value carries optional detail. | | `XmlElementName` (target) | 1.0.0-alpha4 | Each XML element name, named by its element path. | | `XmlAttributeName` (target) | 1.0.0-alpha4 | Each XML attribute name, named by its element path. | | `XmlAttributeValue` (target) | 1.0.0-alpha4 | Each XML attribute value, named by its element path and attribute. | | `XmlText` (target) | 1.0.0-alpha4 | The text content of each XML element, named by its element path. | | `XmlProcessingInstruction` (target) | 1.0.0-alpha4 | The content of each XML processing instruction, named by its target. | | `XmlEntityDeclaration` (target) | 1.0.0-alpha4 | Each entity declared in the internal DTD subset, with its literal value or identifier; entities are never expanded. | | `GraphQlOperationType` (target) | 1.0.0-alpha4 | The type of each GraphQL operation: query, mutation or subscription. | | `GraphQlFieldPath` (target) | 1.0.0-alpha4 | The path of every selected GraphQL field. | | `GraphQlArgumentName` (target) | 1.0.0-alpha4 | Each GraphQL argument name, named by its field. | | `GraphQlArgumentValue` (target) | 1.0.0-alpha4 | Each GraphQL argument value, named by its argument and grouped with its argument-name field, and each variable default value, named by its $variable. | | `GraphQlDirective` (target) | 1.0.0-alpha4 | Each GraphQL directive name. | | `Args` (target) | 1.0.0-alpha4 | A selector group for every argument value: QueryValue, FormValue, JsonScalarValue and MultipartTextValue. | | `ArgNames` (target) | 1.0.0-alpha4 | A selector group for actual argument names: QueryName, FormName, JsonPropertyName and MultipartTextName. JSON array indices and generated field paths are not argument names. | | `WebSocketTextMessage` (target) | 1.0.0-alpha4 | The retained client-to-server WebSocket text message in overlapping windows. | | `WebSocketBinaryMessage` (target) | 1.0.0-alpha4 | The retained client-to-server WebSocket binary message in overlapping windows, with one character per byte. | | `GrpcMethod` (target) | 1.0.0-alpha4 | The gRPC method from the request path, such as /package.Service/Method. | | `ProtobufString` (target) | 1.0.0-alpha4 | Each length-delimited protobuf field that is valid UTF-8, named by its field-number path such as 1.4.2. | | `ProtobufBytes` (target) | 1.0.0-alpha4 | Opaque protobuf leaves or undecodable compressed messages, with one character per byte and a field-number path when available. | | `ResponseStatus` (target) | 1.0.0-alpha4 | The response status code. | | `ResponseHeaderName` (target) | 1.0.0-alpha4 | Each response header name. | | `ResponseHeaderValue` (target) | 1.0.0-alpha4 | Each response header value, named by its header with case-insensitive name comparisons. | | `ResponseBody` (target) | 1.0.0-alpha4 | The captured response body or streaming prefix, decompressed when supported and read as UTF-8 in overlapping windows. | | `SchemaViolation` (target) | 1.0.0-alpha4 | A mismatch with the route's OpenAPI document; the name is the violation kind and the value its JSON pointer. | | `FormRawValue` (target) | 1.0.0-alpha4 | Each encoded form parameter occurrence, including its encoded name, equals sign if present, and original adjacent ampersand delimiters. Named by the decoded field name and grouped with its FormName and FormValue. Encoded ampersands do not split parameters. Not included in Args; RawBodyValue remains the whole body. | | `UriDecode` (transformation) | 1.0.0-alpha4 | Decodes percent-encoded bytes, %u escapes and plus signs using the URL decoding compatibility rules. | | `HtmlEntityDecode` (transformation) | 1.0.0-alpha4 | Decodes named and numeric HTML entities, including entities without a trailing semicolon. | | `Lowercase` (transformation) | 1.0.0-alpha4 | Converts the value to lowercase using invariant rules. | | `UnicodeNormalize` (transformation) | 1.0.0-alpha4 | Applies Unicode NFKC normalisation. | | `RemoveNulls` (transformation) | 1.0.0-alpha4 | Removes NUL characters. | | `CompressWhitespace` (transformation) | 1.0.0-alpha4 | Collapses every run of whitespace, line breaks included, into one space. | | `NormalizePath` (transformation) | 1.0.0-alpha4 | Converts backslashes to slashes and resolves dot segments and repeated slashes in a path. | | `Base64Decode` (transformation) | 1.0.0-alpha4 | Decodes a base64 prefix, ignoring ASCII whitespace and stopping at padding or an invalid character, within the decoded-size limit. | | `JsDecode` (transformation) | 1.0.0-alpha4 | Decodes JavaScript hexadecimal, Unicode, octal and simple escapes using the compatibility decoder. | | `CssDecode` (transformation) | 1.0.0-alpha4 | Decodes CSS hexadecimal and character escapes using the compatibility decoder. | | `EscapeSeqDecode` (transformation) | 1.0.0-alpha4 | Decodes ANSI C hexadecimal, octal and simple escape sequences. | | `HexDecode` (transformation) | 1.0.0-alpha4 | Decodes pairs as bytes and reads the result as UTF-8, ignoring an unmatched final character. | | `Utf8ToUnicode` (transformation) | 1.0.0-alpha4 | Rewrites each non-ASCII Unicode scalar as a %u escape with at least four hexadecimal digits. | | `CmdLine` (transformation) | 1.0.0-alpha4 | Normalises command lines: removes backslashes, quotes and carets, turns commas and semicolons into spaces, collapses whitespace, removes spaces before slashes and parentheses, and lowercases. | | `RemoveWhitespace` (transformation) | 1.0.0-alpha4 | Removes all whitespace. | | `ReplaceComments` (transformation) | 1.0.0-alpha4 | Replaces each C-style comment with a single space. | | `RemoveCommentsChar` (transformation) | 1.0.0-alpha4 | Removes comment markers: /*, */, -- and #. | | `Base64UrlDecode` (transformation) | 1.0.0-alpha4 | Decodes a base64url prefix with optional padding, ignoring ASCII whitespace, within the decoded-size limit. | | `Base64AutoDecode` (transformation) | 1.0.0-alpha4 | Decodes sufficiently long base64 or base64url runs only when their decoded bytes are printable UTF-8 text. | | `Decompress` (transformation) | 1.0.0-alpha4 | Detects gzip or zlib-wrapped deflate by its header, otherwise tries Brotli, and retains the decoded prefix within the decompression settings. | | `Utf8BytesAsLatin1` (transformation) | 1.0.0-alpha4 | Produces a byte view in which each UTF-8 byte becomes one character. | | `Utf8LowByteTruncation` (transformation) | 1.0.0-alpha4 | Keeps each character's low byte, which reveals CRLF smuggled as U+560A or U+560D. | | `EvaluateLookups` (transformation) | 1.0.0-alpha4 | Folds Log4j and expression-language lookups such as ${lower:}, ${::-x} and ${base64:} under depth and size caps. | | `FoldExpressionStrings` (transformation) | 1.0.0-alpha4 | Folds string concatenation and escapes inside quotes, such as 'a'+'b' and \x5f. | | `ExtractSerializedTypeNames` (transformation) | 1.0.0-alpha4 | Outputs the type names found in Java serialization, .NET NRBF, Python pickle, YAML tags and PHP serialized objects; nothing is deserialized. | | `UriScheme` (transformation) | 1.0.0-alpha4 | Returns the scheme from the engine's WHATWG-style URL parser, or an empty value if parsing fails. | | `UriHost` (transformation) | 1.0.0-alpha4 | Returns the host from the engine's WHATWG-style URL parser, or an empty value if parsing fails. | | `Equal` (operator) | 1.0.0-alpha4 | Matches a value equal to the operand using ordinal, case-sensitive comparison. | | `StartsWith` (operator) | 1.0.0-alpha4 | Matches a value that starts with the operand using ordinal, case-sensitive comparison. | | `EndsWith` (operator) | 1.0.0-alpha4 | Matches a value that ends with the operand using ordinal, case-sensitive comparison. | | `Contains` (operator) | 1.0.0-alpha4 | Matches a value that contains the operand using ordinal, case-sensitive comparison. | | `PhraseSet` (operator) | 1.0.0-alpha4 | Matches a value containing any phrase from values or a list, optionally ignoring case. | | `Exists` (operator) | 1.0.0-alpha4 | Matches when at least one selected field is present. | | `CountAtLeast` (operator) | 1.0.0-alpha4 | Matches when at least the given number of selected fields are present. | | `NumericGreaterThan` (operator) | 1.0.0-alpha4 | Matches a value that parses as a signed 64-bit integer greater than number. | | `NumericLessThan` (operator) | 1.0.0-alpha4 | Matches a value that parses as a signed 64-bit integer less than number. | | `LengthGreaterThan` (operator) | 1.0.0-alpha4 | Matches a value longer than the given number of characters. | | `LengthLessThan` (operator) | 1.0.0-alpha4 | Matches a value shorter than the given number of characters. | | `SafeRegex` (operator) | 1.0.0-alpha4 | Matches a non-backtracking regular expression and captures its named groups. | | `Malformed` (operator) | 1.0.0-alpha4 | Matches a field its parser or a decoding step flagged as malformed. Supports ProtocolAnomaly, RawQuery, JsonScalarValue, FormValue, MultipartTextValue and XmlText; an XmlText marker can guard raw-body fallback rules after malformed XML parsing. | | `InSet` (operator) | 1.0.0-alpha4 | Matches a value that equals an entry of values or a list, optionally ignoring case. | | `ValidateByteRange` (operator) | 1.0.0-alpha4 | Matches when any byte in the value's UTF-8 encoding falls outside the configured byte ranges. | | `ValidateUtf8` (operator) | 1.0.0-alpha4 | Matches a value containing a Unicode replacement character or an unpaired UTF-16 surrogate. | | `ValidateUriEncoding` (operator) | 1.0.0-alpha4 | Matches a value with invalid percent-encoding. | | `NumericEqual` (operator) | 1.0.0-alpha4 | Matches a value that parses as a signed 64-bit integer equal to number. | | `NumericGreaterOrEqual` (operator) | 1.0.0-alpha4 | Matches a value that parses as a signed 64-bit integer greater than or equal to number. | | `IpIn` (operator) | 1.0.0-alpha4 | Matches a value that parses as an IP address, including inet_aton and IPv6 mapped forms, inside a CIDR list. | | `UriHostIn` (operator) | 1.0.0-alpha4 | Matches a URL, under RFC 3986 or WHATWG rules, whose host is in a CIDR list or matches a host pattern; DNS is never resolved. | | `OffOrigin` (operator) | 1.0.0-alpha4 | Matches a parsed URL whose host differs from the request origin and all allowed host patterns; relative URLs use the request origin. | | `Detect` (operator) | 1.0.0-alpha4 | Runs a detector from the same ruleset and reports the matching pattern's reason code or the fingerprint reason. | | `condition:matchEachField` | 1.0.0-alpha4 | Apply negation to each selected field separately and retain matching fields for later scoped conditions. With the default false, negation applies to the combined result across selected fields. | | `condition:matchEachTransformation` | 1.0.0-alpha4 | A condition evaluated on the original value and each distinct intermediate transformation result. | | `condition:reasonCode` | 1.0.0-alpha4 | A condition that reports its own reason code when it matches. | | `detector:mode:Fingerprint` | 1.0.0-alpha4 | A detector that uses SQL fingerprint lists or HTML token classification and reports a fingerprint when it matches. | | `detector:mode:Patterns` | 1.0.0-alpha4 | A detector that matches token patterns compiled into one automaton. | | `exclusion:methods` | 1.0.0-alpha4 | An exclusion entry limited to the listed request methods. | | `exclusion:name` | 1.0.0-alpha4 | An exclusion entry limited to fields with an exact name, a prefix or a regular expression. | | `exclusion:path` | 1.0.0-alpha4 | An exclusion entry limited to request paths by prefix or regular expression. | | `exclusion:requestFields` | 1.0.0-alpha4 | All request-field guards must match exactly one named field (or zero when absent). Duplicates reject the exclusion. Body guards require a complete, valid buffered body and are unavailable during streamed part inspection. | | `exclusion:ruleTag` | 1.0.0-alpha4 | An exclusion entry that selects rules by tag instead of rule ID. | | `exclusion:value` | 1.0.0-alpha4 | An ordinal exact, prefix, or bounded regex condition on the excluded field value. | | `exclusions` | 1.0.0-alpha4 | An opt-in exclusion ruleset removes matching target fields from selected rules in another ruleset without evaluating or scoring its own rules. | | `integrity:metadataFields` | 1.0.0-alpha4 | A request-body integrity vector supplies prior request-metadata fields for chained conditions. Metadata and body fields share the existing vector field and value limits. | | `integrity:origin` | 1.0.0-alpha4 | An integrity vector supplies the originating HTTP or HTTPS scheme and host for origin-dependent operators. | | `lexicon` | 1.0.0-alpha4 | A named table that assigns lexicon classes to the words a tokenizer produces. | | `list` | 1.0.0-alpha4 | A named list of values that operators and detectors reference by ID. | | `operand:capture` | 1.0.0-alpha4 | An operand taken from a named capture of an earlier regular-expression condition. | | `operand:valueFrom` | 1.0.0-alpha4 | An operand taken from another selected field available in the current transaction. | | `operator:ignoreCase` | 1.0.0-alpha4 | A set operator that compares without regard to case. | | `pattern:anchor:Start` | 1.0.0-alpha4 | A pattern that must match from the first token. | | `pattern:capture` | 1.0.0-alpha4 | A pattern step that names its token for predicates. | | `pattern:class` | 1.0.0-alpha4 | A predicate that a capture has a given class. | | `pattern:in` | 1.0.0-alpha4 | A predicate requiring a token field to equal a list entry, ignoring case. | | `pattern:minLength` | 1.0.0-alpha4 | A minimum length that a prefix predicate's field must reach. | | `pattern:nonBlank` | 1.0.0-alpha4 | A predicate that a token field is not blank. | | `pattern:prefix` | 1.0.0-alpha4 | A predicate requiring a token field to start with the given text, ignoring case. | | `pattern:prefixAnyIgnoringWhitespace` | 1.0.0-alpha4 | A predicate requiring a token field to start with a list value, ignoring case and whitespace in the field. | | `pattern:repeat:*` | 1.0.0-alpha4 | A pattern step that matches zero or more times within the fixed repetition cap. | | `pattern:repeat:?` | 1.0.0-alpha4 | A pattern step that may match once or not at all. | | `pattern:reset` | 1.0.0-alpha4 | Token classes that discard earlier partial matches before the current token is considered as a new start. | | `pattern:same` | 1.0.0-alpha4 | A predicate requiring two captured tokens to have the same grammar class and case-insensitively equal text. | | `pattern:skip` | 1.0.0-alpha4 | Token classes that preserve partial matches while the pattern waits for later steps. | | `pattern:startsWithAny` | 1.0.0-alpha4 | A predicate requiring a token field to start with a list entry, ignoring case. | | `rule:action:Challenge` | 1.0.0-alpha4 | A rule whose action is Challenge asks for a bot challenge instead of adding score. | | `scope:MatchedFields` | 1.0.0-alpha4 | A condition that inspects only the fields the previous condition matched. | | `scope:SameGroup` | 1.0.0-alpha4 | A condition that inspects fields in the group of a field the previous condition matched. | | `selector:excludeNames` | 1.0.0-alpha4 | A target selector that leaves out fields by exact name, prefix or regular expression. | | `selector:namePrefix` | 1.0.0-alpha4 | A target selector that matches field names by prefix. | | `selector:nameRegex` | 1.0.0-alpha4 | A target selector that matches field names with a non-backtracking regular expression. | | `stage:Response` | 1.0.0-alpha4 | Rules inspecting upstream responses as their own transaction. | | `stage:WebSocketMessage` | 1.0.0-alpha4 | Rules inspecting each client-to-server WebSocket message as its own transaction. | | `tokenizer:Html` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:class:Attribute` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:class:Comment` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:class:Doctype` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:class:Tag` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:class:Text` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:context:Data` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:context:ValueBackQuote` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:context:ValueDoubleQuote` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:context:ValueNoQuote` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:context:ValueSingleQuote` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:field:closing` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:field:hasValue` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:field:localName` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:field:name` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:field:value` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Html:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:Comment` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:Identifier` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:LeftBracket` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:LeftParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:Number` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:Punctuator` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:RegularExpression` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:RightBracket` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:RightParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:String` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:class:Template` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:context:Code` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:context:DoubleQuoteString` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:context:SingleQuoteString` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:context:Template` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:JavaScript:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:And` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:Attribute` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:Escape` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:FilterType` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:LeftParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:Not` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:Or` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:RightParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:Value` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:class:Wildcard` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:context:Filter` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:context:InsideValue` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:LdapFilter:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Cmdlet` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Invocation` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Parameter` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Pipe` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Separator` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:String` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Subexpression` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Symbol` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Variable` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:class:Word` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:context:Command` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:PowerShell:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:class:LeftParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:class:Redirect` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:class:Separator` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:class:Substitution` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:class:Symbol` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:class:Variable` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:class:Word` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:context:Command` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:field:basename` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:field:nonBlank` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:field:target` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Shell:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:Comment` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:Comparison` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:Equal` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:LeftParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:Number` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:RightParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:Semicolon` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:String` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:Symbol` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:class:Word` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:context:AsIs` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:context:FoldQuotes` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Sql:option:versionedCommentDigits` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:AttributeAccess` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Call` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Close` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Filter` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Identifier` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Number` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Open` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Operator` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:String` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Subscript` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:class:Text` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:context:Text` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:field:family` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:Template:option:families` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:class:LeftParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:class:Redirect` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:class:Separator` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:class:Symbol` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:class:Variable` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:class:Word` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:context:Command` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:field:basename` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:field:target` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:WindowsCmd:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:At` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:Axis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:Comma` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:DoubleSlash` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:LeftBracket` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:LeftParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:Name` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:Number` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:Operator` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:RightBracket` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:RightParenthesis` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:Slash` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:class:String` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:context:DoubleQuoteString` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:context:Expression` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:context:SingleQuoteString` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | | `tokenizer:XPath:option:contexts` | 1.0.0-alpha4 | See [Tokenizers](../tokenizers/). | ================================================================================ DOCUMENT: WAF rule language Human URL: /docs/waf-reference/ ================================================================================ Use this reference when writing rules in **Firewall → Custom rules** or reviewing a Cloud ruleset. [Write custom WAF rules](/docs/guides/write-custom-waf-rules/) covers editing, testing and publishing the unsigned `local` ruleset. Cloud releases use the same rule language inside a signed envelope. 1. [Ruleset format](ruleset-format/) defines the JSON document, profiles and rule metadata. 2. [Rule flow](rule-flow/) explains conditions, field scope, captures and operands. 3. [Targets](targets/) lists selectable request, message and response fields. 4. [Facts and limits](facts-and-limits/) lists parser facts and bounded work settings. 5. [Transformations](transformations/) lists value normalization steps. 6. [Operators](operators/) lists comparisons and detection operations. 7. [Detectors and patterns](detectors-and-patterns/) explains lists, lexicons and token patterns. 8. [Tokenizers](tokenizers/) lists grammar classes, token fields, contexts and options. 9. [Scoring and integrity tests](scoring-and-integrity-tests/) explains score attribution and release checks. 10. [Feature versions](feature-versions/) gives the minimum Clearplane version for each construct. 11. [Examples](examples/) shows tested seed fragments, a challenge rule and an exclusion ruleset. ================================================================================ DOCUMENT: Operators Human URL: /docs/waf-reference/operators/ ================================================================================ An operator decides whether a condition matches its transformed fields. Value operators take `value` or an `operand`; set operators take `values` or a `list`; numeric and count operators take `number`. `negated` inverts operators that support it. See [Rule flow](../rule-flow/) for operands and [Detectors and patterns](../detectors-and-patterns/) for `Detect`. | Operator | Since | Description | |---|---|---| | `Equal` | 1.0.0-alpha4 | Matches a value equal to the operand using ordinal, case-sensitive comparison. | | `StartsWith` | 1.0.0-alpha4 | Matches a value that starts with the operand using ordinal, case-sensitive comparison. | | `EndsWith` | 1.0.0-alpha4 | Matches a value that ends with the operand using ordinal, case-sensitive comparison. | | `Contains` | 1.0.0-alpha4 | Matches a value that contains the operand using ordinal, case-sensitive comparison. | | `PhraseSet` | 1.0.0-alpha4 | Matches a value containing any phrase from values or a list, optionally ignoring case. | | `Exists` | 1.0.0-alpha4 | Matches when at least one selected field is present. | | `CountAtLeast` | 1.0.0-alpha4 | Matches when at least the given number of selected fields are present. | | `NumericGreaterThan` | 1.0.0-alpha4 | Matches a value that parses as a signed 64-bit integer greater than number. | | `NumericLessThan` | 1.0.0-alpha4 | Matches a value that parses as a signed 64-bit integer less than number. | | `LengthGreaterThan` | 1.0.0-alpha4 | Matches a value longer than the given number of characters. | | `LengthLessThan` | 1.0.0-alpha4 | Matches a value shorter than the given number of characters. | | `SafeRegex` | 1.0.0-alpha4 | Matches a non-backtracking regular expression and captures its named groups. | | `Malformed` | 1.0.0-alpha4 | Matches a field its parser or a decoding step flagged as malformed. Supports ProtocolAnomaly, RawQuery, JsonScalarValue, FormValue, MultipartTextValue and XmlText; an XmlText marker can guard raw-body fallback rules after malformed XML parsing. | | `InSet` | 1.0.0-alpha4 | Matches a value that equals an entry of values or a list, optionally ignoring case. | | `ValidateByteRange` | 1.0.0-alpha4 | Matches when any byte in the value's UTF-8 encoding falls outside the configured byte ranges. | | `ValidateUtf8` | 1.0.0-alpha4 | Matches a value containing a Unicode replacement character or an unpaired UTF-16 surrogate. | | `ValidateUriEncoding` | 1.0.0-alpha4 | Matches a value with invalid percent-encoding. | | `NumericEqual` | 1.0.0-alpha4 | Matches a value that parses as a signed 64-bit integer equal to number. | | `NumericGreaterOrEqual` | 1.0.0-alpha4 | Matches a value that parses as a signed 64-bit integer greater than or equal to number. | | `IpIn` | 1.0.0-alpha4 | Matches a value that parses as an IP address, including inet_aton and IPv6 mapped forms, inside a CIDR list. | | `UriHostIn` | 1.0.0-alpha4 | Matches a URL, under RFC 3986 or WHATWG rules, whose host is in a CIDR list or matches a host pattern; DNS is never resolved. | | `OffOrigin` | 1.0.0-alpha4 | Matches a parsed URL whose host differs from the request origin and all allowed host patterns; relative URLs use the request origin. | | `Detect` | 1.0.0-alpha4 | Runs a detector from the same ruleset and reports the matching pattern's reason code or the fingerprint reason. | ================================================================================ DOCUMENT: Rule flow Human URL: /docs/waf-reference/rule-flow/ ================================================================================ ## Conditions All conditions of a rule must match. A rule using another scope, an operand or `matchEachField: true` keeps its written condition order so later conditions can use earlier matches and captures. A rule matches at most once per transaction, even if multiple values or body windows match. ## Selecting fields Each entry in `targets` selects a target and optionally one of `name`, `namePrefix` or `nameRegex`. `excludeNames` removes names with entries shaped as `{ "exact": "name" }`, `{ "prefix": "prefix" }` or `{ "regex": "pattern" }`. Header names compare without case; other named targets use ordinal comparison. Regex selectors use the same bounded regex implementation as `SafeRegex`. `Args` and `ArgNames` expand to argument targets from the current inspection stage. A RequestBody rule can also explicitly select metadata-only targets such as `Method` and `HeaderValue` to combine the original request context with parsed body fields. Targets shared with the body stage, such as parser facts, use the body stage’s values. `Args` and `ArgNames` are selectors, not fields an integrity vector can supply. See [Targets](/docs/waf-reference/targets/) for group membership and which targets support names. ## Groups and scope `scope` defaults to `AllFields`. `MatchedFields` selects the exact fields that matched the previous condition. `SameGroup` selects fields sharing a group with a previous match; group zero does not join unrelated fields. A multipart part is one group. JSON values share their nearest enclosing object’s group; each object in an array has its own group. Query and form parameter occurrences, headers and cookies have separate groups. XML groups follow elements; GraphQL argument values share their field’s group. These `RequestBody` conditions match a `.php` filename only when the same part’s inspected content contains `.+)`. Repeated captures retain their last value. A later comparison uses `operator.operand.capture`; the capture must have been declared by an earlier condition. Scope also restricts which captured fields can supply the operand. This comparison matches when the Host header equals a value captured from `X-Expected-Host`: ```json [ { "targets": [ { "target": "HeaderValue", "name": "x-expected-host" } ], "operator": { "kind": "SafeRegex", "value": "^(?.+)$" } }, { "targets": [ { "target": "HeaderValue", "name": "host" } ], "operator": { "kind": "Equal", "operand": { "capture": "expected" } } } ] ``` To read a field directly, use `operator.operand.valueFrom` with a concrete target and optional exact name. It reads available fields from the current stage or request metadata. It cannot use prefix/regex names, excluded names or selector groups. This example compares `X-Forwarded-Host` with Host; it does not establish that either header is trusted: ```json [ { "targets": [ { "target": "HeaderValue", "name": "x-forwarded-host" } ], "operator": { "kind": "Equal", "operand": { "valueFrom": { "target": "HeaderValue", "name": "host" } } } } ] ``` ## Transformations Transformations run in listed order. Normally the operator sees the final value. With `matchEachTransformation: true`, it can match the original value and the intermediate transformed values. See [Transformations](/docs/waf-reference/transformations/) for supported steps. ## Operators and negation Put `kind` and its inputs inside `operator`. Depending on the kind, use `value`, `values`, a named `list`, a numeric `number`, `ignoreCase` or an `operand`; unsupported combinations fail compilation. `negated` belongs to the condition. By default, a negated comparison succeeds when no selected value matches, which can include an empty selection. With `matchEachField: true`, negation instead retains each selected field whose value does not match; an empty selection does not match. A later `MatchedFields` condition can then inspect only those retained fields. Scoped conditions cannot follow aggregate negation, and negated regex conditions do not declare captures. `reasonCode` is a condition-level diagnostic label. A detector can provide a more specific pattern reason. See [Operators](/docs/waf-reference/operators/) for the operator inventory and value shapes. ================================================================================ DOCUMENT: Ruleset format Human URL: /docs/waf-reference/ruleset-format/ ================================================================================ ## Top-level fields | Field | Meaning | |---|---| | `rulesetId` | Stable identifier matching `[a-z0-9][a-z0-9.-]*`, at most 200 characters. `local` identifies operator custom rules. | | `version` | Release version. Rulesets published through Clearplane Cloud use the UTC publication minute, `yyyy_MM_dd_HH_mm`, so a version states how fresh the rules are. Operator-authored `local` rulesets may use that form or a semantic version. Engine compatibility is carried separately by `minimumClearplaneVersion`. | | `schemaVersion` | `1`. | | `kind` | `Baseline`, `Application`, `VirtualPatch`, `Bot` or `Exclusion`. | | `minimumClearplaneVersion` | Earliest compatible product version; it must cover every [feature used](/docs/waf-reference/feature-versions/). | | `releasedAt` | Release timestamp with a UTC offset. | | `provenance` | `source`, `license` and optional `sourceUri`. | | `profiles` | The `standard` and `management` rule selections; empty for Exclusion rulesets. | | `rules` | Rules to evaluate; empty for Exclusion rulesets. | | `lists`, `lexicons`, `detectors` | Reusable data and [token detectors](/docs/waf-reference/detectors-and-patterns/) belonging to this ruleset. | | `exclusions` | Target exclusions, allowed only in Exclusion rulesets. | | `integrityTests` | Embedded [test vectors](/docs/waf-reference/scoring-and-integrity-tests/) checked before a release is accepted. | ## JSON rules Use camelCase property names and enum names such as `RequestMetadata`, never numeric enum values. Unknown properties and duplicate properties reject the document. The maximum JSON nesting depth is 64. A signed envelope is limited to 16 MiB; its decoded payload is also bounded. Local draft JSON is limited to 16 MiB of UTF-8. Compiler collection and text limits can reject a smaller document. ## Profiles A ruleset with rules requires both `standard` and `management`, with distinct names. Each profile has an `id`, positive `revision`, `name`, positive `maximumRequestBodyBytes`, `ruleIds` and `limits`. Omitted body size and work limits use the engine defaults in [Facts and limits](/docs/waf-reference/facts-and-limits/). A route’s profile choice applies to every participating ruleset. Profiles contain no score threshold. Exclusion rulesets require empty `profiles` and `rules` arrays. They refer to rules in another ruleset and apply only through route opt-in. ## Rules A rule has a positive `id` and `revision`, a `message` of at most 500 characters, a `description` of at most 2,000 characters and a lowercase identifier `category`, such as `sql-injection`. Rule identity is the pair of ruleset ID and rule ID, so custom rules can use small positive IDs. `severity` and `score` must agree: Critical 5, Error 4, Warning 3 or Notice 2. `paranoiaLevel` is 1–4 and defaults to 1. `action` defaults to `Score`; `Challenge` still carries a valid severity/score pair but contributes zero at runtime. See [Scoring and integrity tests](/docs/waf-reference/scoring-and-integrity-tests/). `inspectionStage` is `RequestMetadata`, `RequestBody`, `WebSocketMessage` or `Response`. A rule has 1–16 `conditions`; their targets must belong to that stage. `tags` label rules for review and exclusions. `diagnosticMetadata` carries bounded descriptive key/value pairs. Rule `provenance` includes `kind`, `source` and `license`. `ClearplaneOriginal` records original work. `OwaspCrsAdapted` also requires `sourceVersion`, `sourceRuleId` and `sourceUri`. `PublishedTechniqueDerived` requires `sourceUri`. ## A complete local ruleset This compact adaptation of the editor’s starter ruleset scores a query value containing `alert(1)" } ], "expectedMatchedRuleIds": [ 1 ] }, { "id": "clean-query", "profileId": "management", "fields": [ { "target": "QueryValue", "name": "q", "value": "hello" } ], "expectedMatchedRuleIds": [] } ] } ``` ================================================================================ DOCUMENT: Scoring and integrity tests Human URL: /docs/waf-reference/scoring-and-integrity-tests/ ================================================================================ ## Scores `combinedBlockingScore` sums the blocking contributions of participating rulesets; `combinedDetectionScore` sums the rest. A retained finding’s configured `score` is not necessarily a contribution to either sum: a Challenge finding contributes zero. A reported threshold-exceeded result can describe a Detection-mode ruleset’s hypothetical result and is not itself proof that a response was blocked. See [WAF scoring and paranoia levels](/docs/security/waf-scoring-and-paranoia/) for blocking and detection scores, scoring modes, thresholds and paranoia levels. [Event exports](/docs/guides/export-metrics-and-waf-events/) filter on the actual combined blocking score, so a positive minimum excludes events whose findings are all detection-only or Challenge actions. ## Other inspection stages Each WebSocket message has its own transaction and request-style scoring threshold. An inspected response retains its request method, path and origin for request-dependent comparisons and conditional exclusions. See [Inspected traffic](/docs/security/waf-inspected-traffic/) for response scoring and stream limitations. ## Challenge actions `action: "Challenge"` adds no score. A retained matching Challenge rule can trigger a challenge only when it is within the blocking paranoia level, its ruleset is effectively in Prevention, and the route’s challenge policy is enabled and eligible. It does not override an ordinary WAF block. Responses and WebSocket messages do not serve challenge pages. In Combined mode, a configured suspicious-score threshold can also trigger a challenge from scoring matches. See [Bot challenges](/docs/guides/bot-challenges/) for HTTPS, request eligibility, clearance and fallback behavior. ## Integrity test vectors An `integrityTests` entry declares a unique `id`, `profileId`, optional `inspectionStage` (default RequestMetadata), optional `paranoiaLevel` (default 4), `fields` and `expectedMatchedRuleIds`. Each field supplies `target`, `value`, and optional `name` and `group`. Tests compare the exact set of retained matched rule IDs; they do not merely check that one expected rule appeared. Budget exhaustion or truncated findings fails the vector. Use `method`, `path` and `origin: { "scheme": "https", "host": "example.com" }` when behavior depends on the original request. Omitted method/path are GET and `/`; ordinary request test metadata uses HTTPS and a reserved integrity-test host by default. For response and WebSocket origin comparisons, supply the origin explicitly. For RequestBody vectors, optional `metadataFields` supplies the original request’s metadata alongside body `fields`. The runner inspects metadata first and compares cumulative request matches after the body stage. These are field vectors, not raw HTTP parser tests; the custom-rule tester preserves this context when generating vectors from parsed inputs. A release may contain at most 1,024 vectors, 64 fields per vector and 16,384 fields total, counting `metadataFields` together with `fields`. Include an expecting vector for every scoring rule before distributing a release. Gateways run embedded integrity tests before accepting a release; a failing release is not activated. Local publication also runs its vectors. For an Exclusion ruleset, `rulesetId` selects the other ruleset under test. `method` and `path` supply the exclusion’s request scope. `expectedMatchedRuleIds` describes matches with the exclusion enabled, and `expectedSuppressedRuleIds` is the exact difference from running without it. Vectors targeting an inactive ruleset are skipped until that target is active. An embedded exclusion vector must expect a retained match or a suppressed rule. This allows boundary vectors to prove that a request outside the exclusion still matches. Cloud publication requires positive suppression coverage for every exclusion; boundary vectors alone do not satisfy that gate. The [WordPress example](/docs/waf-reference/examples/) verifies the selected path; include outside-path and method-boundary controls as well. ================================================================================ DOCUMENT: Targets Human URL: /docs/waf-reference/targets/ ================================================================================ A condition's `targets` list selects fields by target. A target is inspected only in the stages listed, and named targets accept the `name`, `namePrefix`, `nameRegex` and `excludeNames` selectors described in [Rule flow](../rule-flow/). Facts and measures are listed in [Facts and limits](../facts-and-limits/). | Target | Stages | Named | Since | Description | |---|---|---|---|---| | `Method` | RequestMetadata | no | 1.0.0-alpha4 | The request method, such as GET or POST. | | `Protocol` | RequestMetadata | no | 1.0.0-alpha4 | The HTTP protocol version, such as HTTP/1.1 or HTTP/2. | | `Scheme` | RequestMetadata | no | 1.0.0-alpha4 | The request scheme, http or https. | | `Host` | RequestMetadata | no | 1.0.0-alpha4 | The Host value Edge received, including any port. | | `RawPath` | RequestMetadata | no | 1.0.0-alpha4 | The raw request target before its query string, retaining percent escapes and any absolute-form URI. | | `NormalizedPath` | RequestMetadata | no | 1.0.0-alpha4 | The path supplied by ASP.NET Core, including the request path base. | | `RawQuery` | RequestMetadata | no | 1.0.0-alpha4 | The query string exactly as sent, without its leading question mark. | | `QueryName` | RequestMetadata | yes | 1.0.0-alpha4 | Each query parameter name, one field per occurrence. | | `QueryValue` | RequestMetadata | yes | 1.0.0-alpha4 | Each query parameter value, named by its parameter. | | `HeaderName` | RequestMetadata | yes | 1.0.0-alpha4 | Each request header name. | | `HeaderValue` | RequestMetadata | yes | 1.0.0-alpha4 | Each request header value, named by its header; header names compare case-insensitively. | | `CookieName` | RequestMetadata | yes | 1.0.0-alpha4 | Each cookie name from the Cookie header. | | `CookieValue` | RequestMetadata | yes | 1.0.0-alpha4 | Each cookie value, named by its cookie. | | `JsonFieldPath` | RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | The path of each JSON scalar value, such as $.user.name. | | `JsonPropertyName` | RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | Each JSON object property name, named by its full JSON path. | | `JsonScalarValue` | RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | Each JSON string, number, boolean or null as text, named by its JSON path. A GraphQL request's query string that parses without comments is represented by GraphQL targets instead. | | `FormName` | RequestBody | yes | 1.0.0-alpha4 | Each URL-encoded form field name. | | `FormValue` | RequestBody | yes | 1.0.0-alpha4 | Each URL-encoded form field value, named by its field. | | `MultipartTextName` | RequestBody | yes | 1.0.0-alpha4 | The name of each multipart text part. | | `MultipartTextValue` | RequestBody | yes | 1.0.0-alpha4 | The content of each multipart text part, named by its part. | | `MultipartFieldName` | RequestBody | yes | 1.0.0-alpha4 | The form-data name of every multipart part, text or file. | | `MultipartFileName` | RequestBody | yes | 1.0.0-alpha4 | The file name a multipart file part declares. | | `MultipartContentType` | RequestBody | yes | 1.0.0-alpha4 | The content type a multipart part declares, named by its part. | | `ProtocolAnomaly` | RequestMetadata, RequestBody | no | 1.0.0-alpha4 | A protocol anomaly Edge observed; the value is the anomaly name listed under Facts and limits. | | `RawBodyValue` | RequestBody | no | 1.0.0-alpha4 | The decoded request body in overlapping text windows, bounded by the raw-body character setting and inspection budgets. | | `RequestLine` | RequestMetadata | no | 1.0.0-alpha4 | The request line: method, raw target and protocol. | | `RequestBasename` | RequestMetadata | no | 1.0.0-alpha4 | The last segment of the raw path. | | `BodyFormat` | RequestBody | no | 1.0.0-alpha4 | The detected format of the ordinary request body, or None when it is empty. | | `MultipartPartHeaderName` | RequestBody | yes | 1.0.0-alpha4 | Each header name of each multipart part. | | `MultipartPartHeaderValue` | RequestBody | yes | 1.0.0-alpha4 | Each multipart part header value, named by its header with case-insensitive name comparisons. | | `MultipartFileContent` | RequestBody | yes | 1.0.0-alpha4 | The retained prefix of each file part, up to the file-content setting, with one character per byte. | | `MultipartArchiveEntryName` | RequestBody | yes | 1.0.0-alpha4 | Entry names from a zip file part's central directory; nothing is extracted. | | `ArgumentNameSegment` | RequestMetadata, RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | Each segment of bracket or dot argument names, such as $ne in user[$ne]. | | `JsonValueKind` | RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | The kind of each JSON value (object, array, string, number, boolean or null), named by its path. | | `JwtHeader` | RequestMetadata, RequestBody | yes | 1.0.0-alpha4 | Each header field of a compact JWS found in Authorization, cookies or parameters, named by field path. | | `JwtClaim` | RequestMetadata, RequestBody | yes | 1.0.0-alpha4 | Each claim of a compact JWS, named by claim path. | | `Measure` | RequestMetadata, RequestBody, WebSocketMessage, Response | yes | 1.0.0-alpha4 | A named number Edge computed, such as args-count; the name is the measure and the value the number. | | `ParserFact` | RequestMetadata, RequestBody, WebSocketMessage, Response | yes | 1.0.0-alpha4 | A parser observation whose name identifies the fact and whose value carries optional detail. | | `XmlElementName` | RequestBody | yes | 1.0.0-alpha4 | Each XML element name, named by its element path. | | `XmlAttributeName` | RequestBody | yes | 1.0.0-alpha4 | Each XML attribute name, named by its element path. | | `XmlAttributeValue` | RequestBody | yes | 1.0.0-alpha4 | Each XML attribute value, named by its element path and attribute. | | `XmlText` | RequestBody | yes | 1.0.0-alpha4 | The text content of each XML element, named by its element path. | | `XmlProcessingInstruction` | RequestBody | yes | 1.0.0-alpha4 | The content of each XML processing instruction, named by its target. | | `XmlEntityDeclaration` | RequestBody | yes | 1.0.0-alpha4 | Each entity declared in the internal DTD subset, with its literal value or identifier; entities are never expanded. | | `GraphQlOperationType` | RequestMetadata, RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | The type of each GraphQL operation: query, mutation or subscription. | | `GraphQlFieldPath` | RequestMetadata, RequestBody, WebSocketMessage | no | 1.0.0-alpha4 | The path of every selected GraphQL field. | | `GraphQlArgumentName` | RequestMetadata, RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | Each GraphQL argument name, named by its field. | | `GraphQlArgumentValue` | RequestMetadata, RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | Each GraphQL argument value, named by its argument and grouped with its argument-name field, and each variable default value, named by its $variable. | | `GraphQlDirective` | RequestMetadata, RequestBody, WebSocketMessage | yes | 1.0.0-alpha4 | Each GraphQL directive name. | | `Args` | expands to `QueryValue`, `FormValue`, `JsonScalarValue`, `MultipartTextValue` | yes | 1.0.0-alpha4 | A selector group for every argument value: QueryValue, FormValue, JsonScalarValue and MultipartTextValue. | | `ArgNames` | expands to `QueryName`, `FormName`, `JsonPropertyName`, `MultipartTextName` | yes | 1.0.0-alpha4 | A selector group for actual argument names: QueryName, FormName, JsonPropertyName and MultipartTextName. JSON array indices and generated field paths are not argument names. | | `WebSocketTextMessage` | WebSocketMessage | no | 1.0.0-alpha4 | The retained client-to-server WebSocket text message in overlapping windows. | | `WebSocketBinaryMessage` | WebSocketMessage | no | 1.0.0-alpha4 | The retained client-to-server WebSocket binary message in overlapping windows, with one character per byte. | | `GrpcMethod` | RequestMetadata | no | 1.0.0-alpha4 | The gRPC method from the request path, such as /package.Service/Method. | | `ProtobufString` | RequestBody | yes | 1.0.0-alpha4 | Each length-delimited protobuf field that is valid UTF-8, named by its field-number path such as 1.4.2. | | `ProtobufBytes` | RequestBody | yes | 1.0.0-alpha4 | Opaque protobuf leaves or undecodable compressed messages, with one character per byte and a field-number path when available. | | `ResponseStatus` | Response | no | 1.0.0-alpha4 | The response status code. | | `ResponseHeaderName` | Response | yes | 1.0.0-alpha4 | Each response header name. | | `ResponseHeaderValue` | Response | yes | 1.0.0-alpha4 | Each response header value, named by its header with case-insensitive name comparisons. | | `ResponseBody` | Response | no | 1.0.0-alpha4 | The captured response body or streaming prefix, decompressed when supported and read as UTF-8 in overlapping windows. | | `SchemaViolation` | RequestMetadata, RequestBody | yes | 1.0.0-alpha4 | A mismatch with the route's OpenAPI document; the name is the violation kind and the value its JSON pointer. | | `FormRawValue` | RequestBody | yes | 1.0.0-alpha4 | Each encoded form parameter occurrence, including its encoded name, equals sign if present, and original adjacent ampersand delimiters. Named by the decoded field name and grouped with its FormName and FormValue. Encoded ampersands do not split parameters. Not included in Args; RawBodyValue remains the whole body. | ================================================================================ DOCUMENT: Tokenizers Human URL: /docs/waf-reference/tokenizers/ ================================================================================ A detector names one tokenizer. The tokenizer supplies grammar classes and fields; the detector's lexicon adds classes to words, and its patterns or fingerprints decide a match ([Detectors and patterns](../detectors-and-patterns/)). Tokenizers run in linear time and charge their work to the transaction's budget. ## Sql Splits SQL into words, strings, numbers, comments and punctuation, with a libinjection-compatible fingerprint mode. Since 1.0.0-alpha4. Starting contexts: `AsIs`, `FoldQuotes`. Grammar classes: `Comment`, `Comparison`, `Equal`, `LeftParenthesis`, `Number`, `RightParenthesis`, `Semicolon`, `String`, `Symbol`, `Word`. Token fields: none. Fingerprint mode: yes. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `AsIs`, `FoldQuotes` | `AsIs` | — | | `versionedCommentDigits` | — | `6` | 0–6 | ## Html Tokenizes HTML tags, attributes, text and comments in the chosen starting context, with a libinjection-compatible XSS fingerprint mode. Since 1.0.0-alpha4. Starting contexts: `Data`, `ValueNoQuote`, `ValueSingleQuote`, `ValueDoubleQuote`, `ValueBackQuote`. Grammar classes: `Attribute`, `Comment`, `Doctype`, `Tag`, `Text`. Token fields: `closing`, `hasValue`, `localName`, `name`, `value`. Fingerprint mode: yes. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `Data`, `ValueNoQuote`, `ValueSingleQuote`, `ValueDoubleQuote`, `ValueBackQuote` | `Data` | — | ## JavaScript Splits JavaScript into identifiers, strings, templates, numbers, regular expressions and punctuators. Since 1.0.0-alpha4. Starting contexts: `Code`, `SingleQuoteString`, `DoubleQuoteString`, `Template`. Grammar classes: `Comment`, `Identifier`, `LeftBracket`, `LeftParenthesis`, `Number`, `Punctuator`, `RegularExpression`, `RightBracket`, `RightParenthesis`, `String`, `Template`. Token fields: none. Fingerprint mode: no. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `Code`, `SingleQuoteString`, `DoubleQuoteString`, `Template` | `Code` | — | ## Shell Splits Unix shell input into separators, substitutions, redirects, variables and words. Since 1.0.0-alpha4. Starting contexts: `Command`. Grammar classes: `LeftParenthesis`, `Redirect`, `Separator`, `Substitution`, `Symbol`, `Variable`, `Word`. Token fields: `basename`, `nonBlank`, `target`. Fingerprint mode: no. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `Command` | `Command` | — | ## WindowsCmd Splits Windows cmd input into separators, variables, redirects and words, removing caret escapes. Since 1.0.0-alpha4. Starting contexts: `Command`. Grammar classes: `LeftParenthesis`, `Redirect`, `Separator`, `Symbol`, `Variable`, `Word`. Token fields: `basename`, `target`. Fingerprint mode: no. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `Command` | `Command` | — | ## PowerShell Splits PowerShell into cmdlets, parameters, variables, strings, invocations and subexpressions. Since 1.0.0-alpha4. Starting contexts: `Command`. Grammar classes: `Cmdlet`, `Invocation`, `Parameter`, `Pipe`, `Separator`, `String`, `Subexpression`, `Symbol`, `Variable`, `Word`. Token fields: none. Fingerprint mode: no. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `Command` | `Command` | — | ## LdapFilter Splits RFC 4515 LDAP filters, including values placed inside an existing filter. Since 1.0.0-alpha4. Starting contexts: `Filter`, `InsideValue`. Grammar classes: `And`, `Attribute`, `Escape`, `FilterType`, `LeftParenthesis`, `Not`, `Or`, `RightParenthesis`, `Value`, `Wildcard`. Token fields: none. Fingerprint mode: no. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `Filter`, `InsideValue` | `Filter` | — | ## XPath Splits XPath and XQuery expressions, including values that break out of string literals. Since 1.0.0-alpha4. Starting contexts: `Expression`, `SingleQuoteString`, `DoubleQuoteString`. Grammar classes: `At`, `Axis`, `Comma`, `DoubleSlash`, `LeftBracket`, `LeftParenthesis`, `Name`, `Number`, `Operator`, `RightBracket`, `RightParenthesis`, `Slash`, `String`. Token fields: none. Fingerprint mode: no. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `Expression`, `SingleQuoteString`, `DoubleQuoteString` | `Expression` | — | ## Template Splits enabled template delimiter families into calls, attribute access, filters and literals. Since 1.0.0-alpha4. Starting contexts: `Text`. Grammar classes: `AttributeAccess`, `Call`, `Close`, `Filter`, `Identifier`, `Number`, `Open`, `Operator`, `String`, `Subscript`, `Text`. Token fields: `family`. Fingerprint mode: no. | Option | Allowed values | Default | Range | |---|---|---|---| | `contexts` | `Text` | `Text` | — | | `families` | `Jinja`, `Erb`, `FreeMarker`, `Velocity`, `Thymeleaf`, `SpringEl`, `Ognl`, `Handlebars`, `Razor`, `Smarty` | `Jinja`, `Erb`, `FreeMarker`, `Velocity`, `Thymeleaf`, `SpringEl`, `Ognl`, `Handlebars`, `Razor`, `Smarty` | — | ================================================================================ DOCUMENT: Transformations Human URL: /docs/waf-reference/transformations/ ================================================================================ A condition's `transformations` run in order on a copy of each field's value. Results are cached per field and step prefix, so rules that share leading steps share the work. The descriptions below state each transformation’s behavior; compatibility fixtures cover the supported ModSecurity cases. | Transformation | Since | Description | |---|---|---| | `UriDecode` | 1.0.0-alpha4 | Decodes percent-encoded bytes, %u escapes and plus signs using the URL decoding compatibility rules. | | `HtmlEntityDecode` | 1.0.0-alpha4 | Decodes named and numeric HTML entities, including entities without a trailing semicolon. | | `Lowercase` | 1.0.0-alpha4 | Converts the value to lowercase using invariant rules. | | `UnicodeNormalize` | 1.0.0-alpha4 | Applies Unicode NFKC normalisation. | | `RemoveNulls` | 1.0.0-alpha4 | Removes NUL characters. | | `CompressWhitespace` | 1.0.0-alpha4 | Collapses every run of whitespace, line breaks included, into one space. | | `NormalizePath` | 1.0.0-alpha4 | Converts backslashes to slashes and resolves dot segments and repeated slashes in a path. | | `Base64Decode` | 1.0.0-alpha4 | Decodes a base64 prefix, ignoring ASCII whitespace and stopping at padding or an invalid character, within the decoded-size limit. | | `JsDecode` | 1.0.0-alpha4 | Decodes JavaScript hexadecimal, Unicode, octal and simple escapes using the compatibility decoder. | | `CssDecode` | 1.0.0-alpha4 | Decodes CSS hexadecimal and character escapes using the compatibility decoder. | | `EscapeSeqDecode` | 1.0.0-alpha4 | Decodes ANSI C hexadecimal, octal and simple escape sequences. | | `HexDecode` | 1.0.0-alpha4 | Decodes pairs as bytes and reads the result as UTF-8, ignoring an unmatched final character. | | `Utf8ToUnicode` | 1.0.0-alpha4 | Rewrites each non-ASCII Unicode scalar as a %u escape with at least four hexadecimal digits. | | `CmdLine` | 1.0.0-alpha4 | Normalises command lines: removes backslashes, quotes and carets, turns commas and semicolons into spaces, collapses whitespace, removes spaces before slashes and parentheses, and lowercases. | | `RemoveWhitespace` | 1.0.0-alpha4 | Removes all whitespace. | | `ReplaceComments` | 1.0.0-alpha4 | Replaces each C-style comment with a single space. | | `RemoveCommentsChar` | 1.0.0-alpha4 | Removes comment markers: /*, */, -- and #. | | `Base64UrlDecode` | 1.0.0-alpha4 | Decodes a base64url prefix with optional padding, ignoring ASCII whitespace, within the decoded-size limit. | | `Base64AutoDecode` | 1.0.0-alpha4 | Decodes sufficiently long base64 or base64url runs only when their decoded bytes are printable UTF-8 text. | | `Decompress` | 1.0.0-alpha4 | Detects gzip or zlib-wrapped deflate by its header, otherwise tries Brotli, and retains the decoded prefix within the decompression settings. | | `Utf8BytesAsLatin1` | 1.0.0-alpha4 | Produces a byte view in which each UTF-8 byte becomes one character. | | `Utf8LowByteTruncation` | 1.0.0-alpha4 | Keeps each character's low byte, which reveals CRLF smuggled as U+560A or U+560D. | | `EvaluateLookups` | 1.0.0-alpha4 | Folds Log4j and expression-language lookups such as ${lower:}, ${::-x} and ${base64:} under depth and size caps. | | `FoldExpressionStrings` | 1.0.0-alpha4 | Folds string concatenation and escapes inside quotes, such as 'a'+'b' and \x5f. | | `ExtractSerializedTypeNames` | 1.0.0-alpha4 | Outputs the type names found in Java serialization, .NET NRBF, Python pickle, YAML tags and PHP serialized objects; nothing is deserialized. | | `UriScheme` | 1.0.0-alpha4 | Returns the scheme from the engine's WHATWG-style URL parser, or an empty value if parsing fails. | | `UriHost` | 1.0.0-alpha4 | Returns the host from the engine's WHATWG-style URL parser, or an empty value if parsing fails. |