Rules are the heart of CyStack WAF: they determine which requests are blocked, logged, allowed, or redirected. CyStack WAF provides two complementary layers of rules:
- Managed OWASP ruleset — flip one switch to immediately gain protection against common web attacks.
- Custom rules — your organization’s own rules, including AI-generated virtual patches built from scan results.
Any rule change is synchronized to all edge nodes almost instantly.
Managed OWASP ruleset
Open a site and go to the Web attack protection section. Toggle the switch to apply the OWASP Core Rule Set (CRS) — an open-source, industry-standard ruleset maintained to detect and block web application attacks such as SQL injection, XSS, remote code execution (RCE), path traversal, malicious file uploads, and scanning tools.
Two parameters adjust how strict the ruleset is:
Protection sensitivity
Sensitivity determines the anomaly score threshold at which a request is blocked:
| Level | Behavior | Recommendation |
|---|
| Low | Blocks only when the attack signature is very clear. The fewest false positives. | Applications sensitive to false positives. |
| Medium (balanced) | Blocks clear attacks while still letting normal traffic through. | Default; suitable for most sites. |
| High | Blocks even subtle signatures. Catches more attacks but is more prone to false positives. | Applications with high security requirements. |
Paranoia level
The paranoia level (PL1–PL4) selects which group of rules is evaluated:
- PL1 (default) — conservative, with minimal false positives.
- PL2 — stricter, may produce some false positives.
- PL3–PL4 — very strict, catches the most signatures but with higher false positives.
Start at Sensitivity: Medium and PL1, watch the security events page for a few days, then gradually increase strictness if you do not see legitimate traffic being blocked by mistake. Custom rules
The Custom rules section lets you create your own rules to match any characteristic of a request and choose the corresponding action.
Each rule consists of one or more conditions (joined by AND — all must match) and one action.
Conditions
| Component | Value |
|---|
| Field | path, uri, query, method, header, cookie, body, ip, country, asn, user_agent. |
| Operator | eq (equals), ne (not equal), contains, starts_with, ends_with, matches (regular expression), in (in a list). |
| Value | A string or a list of values. For header/cookie, you can specify a particular field name. |
path contains "/wp-login.php" or path starts_with "/search" and query contains "union select".
Actions
| Action | Description |
|---|
| Block | Returns a status code (403, 429, or 503) and stops the request. |
| Log | Lets the request through but records an event — useful when testing a new rule. |
| Allow | Skips inspection for matching requests (allowlist). |
| Redirect | Returns a redirect to another URL. See Access & traffic control. |
AI-generated virtual patches
When a VulnScan scan discovers a web vulnerability that can be mitigated at the HTTP layer, the AI layer proposes a corresponding virtual patch rule. This rule appears in the custom rules list with a Virtual patch label and a reference to the source vulnerability.
A virtual patch is designed to match the exact attack signature (for example, a malicious parameter on a specific path) rather than blocking an entire endpoint, in order to limit impact on legitimate traffic. The workflow is:
- The AI generates the rule from the vulnerability and pre-fills the conditions and a block action.
- An administrator reviews the conditions to ensure the rule matches the exploit signature exactly.
- Enable the rule so the edge node starts blocking.
- Track the match count and events to confirm effectiveness.
A virtual patch is a temporary mitigation at the edge layer that helps narrow the risk window while your development team fixes the issue properly in the source code. A virtual patch should not be treated as a replacement for fixing the underlying vulnerability.
Rule application order
Rules are applied in priority order. Allow rules (allowlist) should be placed for trusted sources such as your office network, to prevent them from being affected by block rules below. The managed OWASP ruleset and custom rules operate in parallel; a request can be blocked by whichever layer matches first. 
