Custom Signatures

Custom Signatures are signature-based attacks that operate on traffic signatures generated by your application. You can configure a custom signature rule to fine-tune your application and API protection strategy by providing granular control over the event types generated and the requests blocked. These rules apply globally to all the APIs. You can create custom rules for different components of a request and response, such as the header name and value, the body, and the Cookie. You can also create these rules on one or more request components. Traceable provides different preset operations for each part of the request. Traceable lets you choose the rule evaluation points based on the tracing agents used in your deployment. For more information, see Tracing Agents Rule Evaluation for Protection.

What will you learn in this topic?

By the end of this topic, you will be able to:

• Understand the need for Custom Signature rules.

• Understand the steps to create a rule.

• The actions that you can take on the created rules.

Understanding Custom Signatures

Before you configure Custom Signature rules , it is important to understand how they translate your application’s security requirements into enforceable detection logic. The table below explains when to use Custom Signatures, why they are critical for closing protection gaps that generic detections cannot cover, and how you can strategically implement them to strengthen your API security posture with clarity and control.

Before you begin

Before you proceed to create the rules for custom signatures, it is important to understand how payload matching works.

Understand payload match

Before creating the rules, you should have a fair understanding of payload matching, as described in the subsequent sections of Steps to Create a Rule.  Traceable supports two types of payload matching when evaluating rule criteria:

• Static Payload match (default)

  In Step 2 of rule creation, Traceable uses payload match to evaluate request and response data against defined rule criteria. In static payload matching, Traceable compares a selected request or response component against a fixed Value to determine whether a rule condition is met. If you do not enable the Dynamic toggle, it compares a static component against a static value. You must configure the following elements:

  Element	Description
  Component	The part of the Request or Response to evaluate, for example, Header.
  Operator	The comparison logic used to evaluate the component against a specified value, for example, Matches exactly.
  Value	The fixed value used for comparison, for example, /login.

  In this example, the selected attribute, Request URL, matches the value /login.
  

  

• Dynamic payload match

  In Step 2 of rule creation, Traceable supports dynamic payload match for the Request, Response, or Attribute criteria field. Dynamic matching allows Traceable to compare two attributes rather than matching a component against a static value. Each side of the comparison can reference values from the request, response, or extracted attributes. The following table displays the different elements, their descriptions, and examples involved in payload matching:

  Element	Description	Example
  First Component	The first attribute selected for comparison. You can choose a value from the Request, Response, or Attributes.	Request Header: Authorization
  Operator	The comparison logic is used to evaluate the relationship between the two selected components.	Matches exactly
  Second Component	The second attribute selected for comparison from the Request, Response, or Attributes. Traceable dynamically resolves both values during request processing.	Request Header: x-auth-token

  Sample scenarios

  The following sample use-cases show different options available, giving you the flexibility to compare different attributes dynamically:

  Scenario 1 — Compares selected request header values to validate consistency

  For certain components, Traceable supports value-to-value comparisons within the same request context. In these cases, Traceable first evaluates each component independently at a granular level and then dynamically compares the resolved values. For example, the header component takes Authorization and x-auth-token request header values and compares them for each incoming API request, as shown below:

  

  Scenario 2 — Compares two attributes from the request, response, or extracted attributes to evaluate whether their values match dynamically

  For some components, you can compare the Request URL with the attribute component with the value to match a pattern. The screenshot shows dynamic payload matching configured for the Request URL attribute. In this example, the rule evaluates the Request URL and matches it against the pattern /login to identify requests targeting the login endpoint. You can also compare the Request URL with the attribute component with the value to match a pattern, as shown below:

  

The following interactive demo walks you through the steps to dynamically match payloads in the criteria step of rule creation, if you select request, response, or attribute criteria in the payload:

Steps to create a rule

To create a custom rule in Traceable, navigate to Protection → Settings → Policies → Custom Policies, select the appropriate rule type, and click + Add Rule. Traceable lets you choose the rule evaluation points based on the tracing agents used in your deployment. For more information, see Tracing Agents Rule Evaluation for Protection. Create the rule using the following three steps:

1. Define the Intent — Specify the rule name, environment, enforcement action, and rule evaluation point to determine how Traceable processes match traffic.

2. Set the Criteria — Configure the conditions the traffic must meet, including source, payload components, and target scope.

3. Review and Submit — Validate the configured settings and submit the rule for activation.

Step 1 — Define the intent

To define the intent, you must complete the following steps:

1. Rule Name — A unique and identifiable name for the rule, for example, custom signature allow rule.

2. Description (Optional) — A summary of the rule’s purpose or the type of traffic it controls.

3. Environment — The environment in which Traceable should apply the rule.

4. Action — The action Traceable should take when the rule conditions are met. Choose one of the available options from the table below.

   Action	Description	Configuration
   Mark for testing	Tests the custom signature rule before applying it to production data. Events generated by the rule appear with low severity, and Traceable does not send notifications for them. You can view these events by navigating to Protection → Threat Activity and selecting Testing in the Activity Status filter.	Not applicable
   Allow	Allows all requests that match the configured criteria.	Allow indefinitely — Allows matching requests permanently. Allow user for a period of time — Allows matching requests for a specified duration in minutes, hours, or days.
   Monitor only	Monitors traffic for requests that match the configured criteria. No requests are blocked.	Not applicable
   Monitor and Block	Blocks requests that match the configured criteria.	Block indefinitely — Blocks matching requests permanently. Block user for a period of time — Blocks matching requests for a specified duration in minutes, hours, or days.

   The following table highlights the availability of the configurations below based on the action you select above:

   Actions → Configurations ↓	Mark for Testing	Allow	Monitor only	Monitor and block
   Severity of the event generated	X	X	✔️	✔️
   Inject data in the request	✔️	X	✔️	X
   Rule Evaluation Point (The Inline Tracing Agent is selected by default)	✔️	✔️	✔️	✔️

5. What is the severity of the generated event? — The severity that Traceable should assign to the event generated by the Custom Signature rule, such as Low, High, Medium, or Critical.

6. Under the Advanced Configuration, you can configure the following:

   • Inject Data In Request? — Enable the toggle and add one or more headers (Header Key and Header Value) you wish to include in the request. You can use this data for monitoring to highlight any anomalies in the request. If you have selected Mark for testing or Monitor only, the rule is evaluated at the platform level and does not modify live traffic, so header injection is not applicable. For other actions (Allow, Monitor, and block), you can enable the toggle and select the appropriate rule evaluation point(s). Header injection is supported only at the Inline Tracing Agent or Traceable Edge, where traffic can be modified.

   • Rule Evaluation Points — Select the evaluation point(s) where Traceable should evaluate the rule, depending on your initial deployment setup:

     • Inline Tracing Agent — It runs within your application path and enforces security rules in real time. This rule evaluation point is selected by default.

     • Traceable Edge — It operates at the API gateway or ingress layer to inspect traffic and apply security controls before it reaches your services.

7. Once you have defined the intent, Next is enabled, click Next.

Step 2 — Set the criteria

To set the criteria, complete the following steps:

Note

The availability of the criteria (Source, Payload, and Target) below depends on the configurations you selected in Step 1 above.

1. Specify the Source criteria you want to apply the rule to. For example, IP Addresses → All External IPs. Traceable supports the following sources for creating a custom signature rule:

   Source	Description
   IP Address	Restrict or allow traffic from specific internal or external IP addresses.
   IP Type	Control traffic based on IP type, such as Anonymous VPNs, bots, or scanners.
   Scanner	Manage traffic originating from automated scanning and testing tools, such as Traceable AST and similar security scanners.
   Email Domain	Limit requests originating from specific email domains or domain ranges associated with an organization.
   User ID	Manage traffic using specific user IDs or user ID patterns defined through regular expressions (regex).
   User Agent	Restrict requests based on user-agent patterns that identify automated clients, scripts, or bots.
   IP Organization	Control traffic from known organizations or entities that commonly generate high API request volumes.
   Connection Type	Enforce limits based on the connection source, such as corporate networks or data centers.
   IP ASN	Restrict traffic from specific Autonomous System Numbers (ASNs) representing network providers.
   IP Abuse Velocity	Limit requests from IPs exhibiting unusually high or abusive API request rates.
   IP Reputation	Control traffic from IPs flagged as high risk by threat intelligence sources.
   Region	Apply limits based on geographic location to manage region-specific traffic patterns.

2. Specify the Payload or the type of API component on which you want to apply the rule. You can create the rule based on the following:

   • Request/Response/Attribute Criteria — This option allows you to evaluate specific components from the Request, Response, or Attributes using defined operators and values. You can use it to build conditions based on URLs, headers, parameters, and payload fields. For more information, see Understand Payload Match.

     • Static Matching (Default) — By default, Traceable compares a static component against a static value.

     • Dynamic Matching — If you enable the Dynamic toggle, it compares two attributes from the request, response, or extracted attributes, allowing Traceable to evaluate their relationship rather than matching against a fixed value.

       Note

       The Dynamic toggle is only visible if you select Monitor only and Mark for testing actions in the Step 1 — Define the Intent above.

   • Sec Rule — It helps you define security rules to analyze data passing through APIs. These rules are based on the OWASP ModSecurity CRS, which helps detect and block malicious patterns in API traffic. By using this feature, you can create rules that match specific patterns or behaviors in the payload, enhancing API security and automatically blocking or alerting to any suspicious activity. Traceable validates the Sec Rule during rule submission to ensure that it is valid for successful rule creation.

     Note

     • You can add one Sec Rule per custom signature rule.

     • A Sec Rule must contain the ID field.

     • A Sec Rule that includes the msg field must also have the logdata field. Conversely, if the Sec Rule contains the logdata field, the msg field is optional. If the Sec Rule does not include the logdata field, the msg field should be omitted. This applies to all parent and child Sec Rule chains.

3. You can add one or more criteria for the same or different payloads. Traceable carries out an AND operation on all the conditions defined in the rule.

4. Specify the Target — The API endpoints you want Traceable to monitor as part of the rule. You can select one or more APIs or the scope to which the rules should apply. The rule applies to all the underlying APIs and Services. Target has the following sub-sections:

   Targets	Description
   All Services	Apply the rule across all services discovered and monitored by Traceable.
   Services	Apply the rule to one or more specific services. You can search or filter services based on your requirements.
   All Endpoints	Apply the rule to all endpoints within the selected service(s).
   API Endpoints	Apply the rule to specific API endpoints. This allows granular control at the endpoint level.
   Endpoint Labels	Apply the rule to endpoints associated with specific labels, enabling logical grouping and reuse across APIs.
   URL Regex (Optional)	Further restrict rule scope by matching endpoint URLs using regular expressions (for example, /login).

5. Once you have configured the above criteria, click Next.

Step 3 — Review and submit

In the final step, you can review the selections and create the rule. If you wish to edit any intent or criteria during the review, click the Edit () icon corresponding to a section.

Actions available for a rule

After adding a rule, you can do the following:

• Enable or disable the rule using the toggle( ) corresponding to a row.

• View, Clone, Edit, or Delete the rule using the Ellipsis () icon corresponding to a row.