Built-in WAAP signatures provide baseline protection against SQL injection, XSS, path traversal, SSRF, known CVEs and common attack techniques. In real production environments, however, every application is different. Some APIs require specific header formats, some applications rely on legacy parameter structures, and traffic that is perfectly normal for one service may look suspicious to the built-in signature set.
Two requirements follow from this. First, adding application-specific WAAP rules without breaking the built-in rule set. Second, changing the behavior of an existing built-in rule for a specific service: disabling it, putting it in monitor mode, lowering its score or restricting it to a particular traffic section.
In traditional approaches, writing custom rules is often heavy work. The operator has to learn a proprietary scripting language, the rule syntax grows complex, a poorly written regex can cut production traffic, and deploying a rule can create a risk of service interruption. As a result, teams either write rules that are too broad or temporarily ignore risky traffic.
ID management, override handling and layer isolation add another dimension. When built-in rules, organization-wide custom rules and application-specific rules share the same namespace, maintenance becomes difficult. If the same rule must behave differently across applications, a duplicate-and-edit approach quickly becomes unsustainable.
The TR7 Custom WAAP Rules model simplifies this complexity: custom rules are defined with regex, scope, score and state; existing rules are adjusted with overrides; global and pool layers are managed through non-conflicting ID ranges.
TR7 turns custom WAAP rule authoring from a separate coding task into a verifiable, layered policy flow that is native to the core WAAP engine.
The operator defines a custom WAAP rule with name, description, regex, match scope, score and state fields. The wizard mode is sufficient for everyday use; teams that want tighter control can manage the same structure as raw JSON.
New regex patterns can be added for organization- or application-specific needs. For existing built-in rules, only the specific behavior that needs to change — state, score or match scope — is overridden; the built-in rule set is never forked.
The global layer provides an organization-wide baseline for all services; the pool layer applies narrower settings for specific applications or services. Because ID ranges are partitioned, built-in rules, global custom rules and service-specific rules never collide.
Before a rule goes live, name, score, scope and regex fields are validated. If the rule is valid, the targeted signature shard is recompiled; unchanged parts of the engine are not affected.
Custom WAAP Rules run custom security logic at the same level as the core WAAP scoring system.
Every custom rule is defined with name, description, regex, match scope, score and state. The regex specifies the attack pattern or disallowed format; the scope determines whether that pattern is searched in path, query, header, form, json, xml or raw content. The score value carries the threat weight into the WAAP scoring model. The state field controls whether the rule is enabled, monitor or disabled.
A custom rule is not applied blindly to the entire request. The exact traffic section to search is explicitly selected. Path, query, header, form, json, xml and raw scope options narrow where the rule operates. This reduces false-positive risk and ensures the regex only runs where it is meaningful. The same pattern can be used across different scopes with different effects.
Custom rules are assigned one of four score levels: 2, 4, 6 or 8. Lower scores are appropriate for monitoring or weak signals; higher scores indicate strong attack indicators. The score joins the core WAAP decision mechanism and is evaluated alongside other signatures. The custom rule is not an isolated blocking switch — it is part of a composite risk calculation.
A new custom rule does not have to go straight to blocking mode. In monitor mode, rule matches are logged but traffic is not interrupted. The operations team observes the false-positive rate on real traffic, tightens the regex and scope, and then confidently moves the rule to enabled. This model provides controlled rollout in production.
If an existing built-in rule generates too much noise in a specific application, there is no need to copy and modify the rule set. An override changes the state, score or match scope behavior. The same built-in rule can remain active globally while being placed in monitor mode or narrowed to a smaller scope for a specific pool. This reduces maintenance burden and prevents drift from the current signature set.
Global custom rule IDs are generated in the range 1,000,000–4,999,999; pool custom rule IDs in 5,000,000–9,999,999. This separation prevents conflicts between built-in rules, organization-wide rules and application-specific rules. The operations team can identify a rule's scope from its ID alone. Rule inventory management becomes more orderly in large environments.
When a custom rule is changed, only the targeted signature shard is recompiled. The approach of stopping and restarting the entire unchanged rule set is not used. This makes rule operations faster and lower risk. The behavior is especially valuable for frequently changing temporary protection rules.
Custom rule matches are not stored in a separate, disconnected log format. Rule ID, name, state, score value and matched scope are included in the main WAAP event stream. On the SIEM side, custom and built-in rules can be examined through the same event model. This visibility provides consistency for incident response and compliance reporting.
Custom WAAP rule management is considered together with validation, conflict control, hot-load, audit and rollback procedures.
Before a rule goes live, checks confirm that the regex is non-empty, the score is one of the allowed values, and the scope list is valid. Name uniqueness and ID range are also part of the validation process. An invalid rule is not admitted to the WAAP engine.
The global layer provides an organization-wide baseline; the pool layer defines more specific behavior for a particular service or application. When the same logic needs different results at different layers, the override mechanism is used. This model provides manageable, scoped exceptions instead of duplicate rules.
Carelessly written regex patterns can create performance risk. Patterns that are too broad, backtracking-heavy or applied to unnecessarily large scopes can generate cost in production traffic. Regex should therefore be defined with as narrow a scope and as precise a pattern as possible.
The safe workflow for a new custom rule is to observe real traffic in monitor mode first. Log results are reviewed and paths, headers or parameters that produce false positives are assessed. Once rule behavior is clear, the rule is moved to enabled mode.
Adding, updating, disabling and overriding custom rules should be tied to audit records. Who changed which rule's score, scope or state, and when, is critical information for post-incident review. Change history is especially important for operational safety on rules that have a blocking effect.
If a custom rule produces unexpected effects, it can quickly be moved to monitor or disabled state. Override changes can also be reverted to restore built-in rule behavior. This makes rule operations possible without interrupting production traffic.
The security team can add a temporary regex-based rule for a newly disclosed vulnerability without waiting for an official signature update. The rule is first tested in monitor mode and moved to enabled once the attack pattern is confirmed.
If a built-in WAAP rule affects normal traffic in a specific application, it is overridden rather than fully disabled. The scope is narrowed, the score is lowered, or the rule is placed in monitor mode for the relevant pool only.
Financial or healthcare applications can use custom rules to validate expected formats in specific headers, form fields or JSON fields. Non-conforming requests are scored or blocked before reaching application code.
SaaS teams can catch abuse patterns specific to their own API behavior in path, query, header or JSON scope. Business logic violations not covered by the built-in signature set are managed as custom rules inside TR7 WAAP.
Custom security rules with regex, scope, score and override. Let us walk through a live setup in your own environment.