In a traditional WAAP approach, a matched signature immediately blocks the request. This looks fast, but in real deployments it raises the risk of false positives. The same pattern can represent an attack in one context and a legitimate data format in another. That is why treating every rule with identical severity is rarely the right approach.
A second challenge is the management complexity of large rule sets. When it is not clear which rule runs in which scope, which attack category it belongs to, what score it produces and on which services it is active, operations teams end up running the WAAP either too permissively or too aggressively.
The modern attack surface is no longer limited to classic SQL injection and XSS. API endpoints, JSON body fields, GraphQL queries, JWT manipulation, NoSQL queries, template engine vulnerabilities, deserialization and new CVE variants all appear in the same traffic stream. If the WAAP engine cannot separate this variety by scope and category, visibility suffers.
The correct approach is to run signatures through a score-based decision model. Each rule should produce its own weight, service thresholds should evaluate the accumulated scores, rule state should be manageable as monitor or blocking, and custom needs should be overrideable at global or pool scope.
TR7 WAAP Signature & Scoring delivers this model: it makes 3,000+ production rules, 32 attack categories and 7 inspect scopes manageable through score, threshold and override logic.
TR7 applies the WAAP decision through multi-pattern matching, score-based thresholds, a two-tier override model and an enriched attack rule set.
TR7 runs large rule sets efficiently through a multi-regex matching approach. Rules can be compiled in shards so that only the changed portions are rebuilt when rules are updated.
Each rule can produce a score — 2, 4, 6 or 8. Those scores are combined with a per-service threshold value, so the overall risk picture is evaluated rather than a single weak signal.
Global custom rules and pool custom rules are kept in separate ID namespaces. This allows shared organizational policy and customer- or service-specific exceptions to coexist without conflicts.
TR7 adds enriched rules for API, JWT, GraphQL, NoSQL, prompt injection, template injection and CVE-specific attack variants beyond classic web signatures. This layer broadens coverage across the modern application surface.
WAAP Signature & Scoring makes a broad production rule set manageable through per-service score, scope and state controls.
TR7 ships with 3,000+ WAAP rules prepared for production use. Core attack families — SQL injection, XSS, path traversal, SSRF, XXE, deserialization, template injection, file read, file write, command execution and information disclosure — are covered. Rules are managed not just as a flat pattern list but together with category, score, scope and target metadata. This structure combines broad protection with operational control.
Rules are organized into 32 attack categories: access control bypass, authentication bypass, business logic abuse, cache poisoning, CRLF injection, data query injection, encoding evasion, file inclusion, HTTP smuggling, open redirect, parameter pollution, prompt injection, prototype pollution, session manipulation and more. This classification lets security teams understand which attack families trigger most often. Rule management works through meaningful risk headings rather than thousands of raw entries.
TR7 rules can operate across path, query, header, form, JSON, XML and raw fields. Each rule declares exactly which scope it matches against. A signature written for JSON body does not run unnecessarily on the header, and a path-focused rule is not applied incorrectly to body traffic. Scope separation matters for both accuracy and performance.
Each rule produces a specific score that is evaluated against the service threshold. Low-risk matches may produce only a log entry, while a higher total score results in a block decision. This approach considers the overall risk behavior rather than treating a single signature match as an absolute verdict. Per-service threshold tuning allows different applications to be protected at different sensitivities.
Every rule can run in enabled, disabled or monitor mode. In enabled mode the rule contributes to scoring and block decisions; in disabled mode it is inactive; in monitor mode it produces log-only output. New or uncertain rules can be observed in monitor mode first. This makes policy transitions in production services significantly safer.
Global override sets WAAP policy across the entire organization, while pool override defines different behavior for a specific service or customer. A rule can remain enabled globally yet be placed in monitor mode for a particular pool, or have its score adjusted there. This structure balances centralized management with real per-service requirements. Separate ID namespaces reduce custom rule conflicts.
The TR7 enriched layer adds modern attack families on top of classic web signatures. JWT manipulation, GraphQL nested DoS, NoSQL query injection, prompt injection, supply chain patterns, and container and serverless surface attacks are addressed as dedicated rule groups. This layer targets modern API and platform architectures — not only legacy web forms. WAAP protection aligns more closely with how current applications are built.
TR7 can include dedicated variant signatures for CVE-focused attacks such as Log4Shell, Spring4Shell and Shellshock. Encoded, obfuscated or syntax-varied forms are caught by separate patterns. When a CVE is published, custom rule addition and hot reload reduce response time. This operational speed is critical as the first line of defense after a zero-day disclosure.
For each request TR7 can carry the triggered rule IDs, score and relevant part information inside the WAAP payload. This data helps incident reviewers understand which rule fired and why. The operator sees not just a "blocked" outcome but the full score chain that led to blocking. This visibility is important for false-positive analysis.
WAAP events can be logged in CEF and JSON formats. Rule ID, attack category, score, scope and metadata fields are available for the SIEM side. Security teams can connect WAAP events to central alerting, correlation and reporting systems. The log format supports compliance and incident response processes.
Rules can be cross-referenced with security standards and attack taxonomies. CWE, CAPEC, MITRE ATT&CK and OWASP Web/API Top 10 links connect a technical WAAP event to audit and risk language. This lets SOC, application security and compliance teams discuss the same event within a common framework. Reporting is not limited to a raw signature ID.
TR7 can reload only the changed portions of the WAAP engine rather than restarting the entire stack on a rule update. This makes adding new signatures or updating custom rules faster and less disruptive. Updated rule sets can be put into effect without a container restart. This operational speed is decisive during emergency CVE response.
The WAAP signature engine is operated alongside compile modes, score distribution, scope density, custom rule ID namespaces, RRD statistics and hot reload behavior.
Rule compilation can run in all, poly or mono shard modes. In the sharded mono approach, rules are split into partitions that can be compiled in parallel. This model helps reduce compilation time and update impact for large rule sets.
The TR7 WAAP rule factory operates with a model targeting a maximum capacity of 10,000 rules. This ceiling provides expansion headroom for production rules, the enriched layer and customer custom rules. Operators should monitor the performance and coverage balance as the rule set grows.
Rules produce different scores according to their weight. Scores of 2 and 4 represent lower-signal findings; 6 and 8 carry stronger risk signals. Selected critical rules can be treated with higher urgency. The threshold decision is shaped by the combined effect of these accumulated scores.
Rules operate at varying densities across path, query, header, form, JSON, XML and raw fields. Query and form fields carry higher concentrations for classic attack surfaces, while JSON and raw fields gain importance for modern API traffic. Scope distribution helps teams understand which traffic surfaces generate the most protection signal.
Global custom rules and pool custom rules are generated in separate ID ranges. The global namespace carries organization-wide shared rules; the pool namespace carries service- or customer-specific rules. This separation reduces rule conflicts and makes override behavior easier to audit.
Rule hit counts can be aggregated per category and surfaced in charts. This makes it possible to see which attack families appear most often, which services produce the most risk signal and how policy changes affect the distribution over time. Statistics turn the WAAP from a pure blocker into a learnable security sensor.
Financial API teams can extend classic OWASP-aligned coverage with JWT, GraphQL, NoSQL and modern API attack rules. The TR7 enriched layer provides a signature scope better matched to the current API surface.
Banking teams can observe specific rules in monitor mode first, then tune per-pool service threshold values. This lets them establish a more controlled balance between aggressive security enforcement and legitimate user traffic.
Government portals can add custom regex rules scoped to form and JSON fields. When sensitive data patterns or unexpected input appears, a score and log entry trigger an investigation workflow.
SaaS teams can apply global baseline rules to all tenants while defining custom overrides for specific customers or pools. Separate ID namespaces ensure that customer-specific rules never conflict with the shared rule set.
3,000+ production rules, 32 attack categories and a score-based decision model. Let's walk through how it works in your own environment.