---
title: "Custom Signatures"
slug: "custom-signatures"
updated: 2026-05-07T12:12:02Z
published: 2026-05-07T12:12:02Z
---

> ## Documentation Index
> Fetch the complete documentation index at: https://traceabledocs.document360.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Custom Signatures

##### Updates (April 2026 to June 2026)

- *May 2026* — Updated the topic to add information about the addition of change logs as an available action on Custom Signature rules. For more information, see [Actions available for a rule](/v1/docs/custom-signatures#actions-available-for-a-rule).

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](https://docs.traceable.ai/docs/en/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.

---

## Before you begin

Before you proceed to create the rules, make a note of the following:

- Make sure you have the *Settings* RBAC permissions under **Module Level Access** → **API Protection** to create the rules. For more information, see [RBAC](https://docs.traceable.ai/docs/rbac).
- Make sure you understand how payload matching works. For more information, see [Understand payload match](/v1/docs/custom-policies#understand-payload-match).

---

## **Understand****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.

| Why use it? | When to use? | How can you leverage it? |
| --- | --- | --- |
| It allows you to implement granular, application-specific protection for applications and APIs by inspecting request and response components, including headers, parameters, URLs, payload fields, and extracted attributes. They help enforce business logic, detect misuse patterns, reduce false positives, and introduce targeted protections beyond built-in detections. | You should use Custom Signatures when you need precise control over application and API traffic behavior that generic security detections cannot fully capture. For example, detecting suspicious header values, validating request patterns, enforcing application-specific rules, identifying abnormal payload structures, or protecting sensitive API operations from misuse. | Create a rule by defining the intent, criteria, and target scope. Configure the enforcement action (*Allow*,*Monitor*, *Monitor and Block*, or*Mark for Testing*), define source conditions, specify the payload-matching logic (static or dynamic), and specify the services or endpoints to which the rule applies. |

---

## 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](https://docs.traceable.ai/docs/en/tracing-agents-rule-evaluation-for-protection). Create the rule using the following three steps:

1. [Define the intent](/v1/docs/custom-signatures#step-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](/v1/docs/custom-signatures#step-2-—-set-the-criteria)— Configure the conditions the traffic must meet, including source, payload components, and target scope.
3. [Review and submit](/v1/docs/custom-signatures#step-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:

![](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/Traceable_protection_custom_signature_create_rule_intent_section.png)

Custom Signature Intent

1. **Rule Name**— A unique and identifiable name for the rule, for example, *custom signature allow rule*.
2. (Optional) **Description** — 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](https://docs.traceable.ai/docs/traceable-runtime-protection#traceable-application-and-api-protection-deployment-models):
    - **Inline Tracing Agent**— It runs within your application traffic path and enforces security rules as requests pass through your system. This evaluation point is selected by default.
    - **Traceable Edge**— It routes traffic through Traceable’s cloud, where requests are inspected, and security controls are applied before they reach your services, without requiring internal deployment.
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:

![](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/Traceable_Protection_custom_policies_CS_criteria_Dynamic_match_flow.png)

Custom Signature Criteria

> [!NOTE]
> 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](/v1/docs/custom-policies#understand-payload-match).
    - Static Payload Match (Default)****— By default, Traceable compares a static component against a static value.
    - Dynamic Payload Match — 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]
> Note
> 
> The **Dynamic toggle** is only visible if you select*Monitor only* and *Mark for testing* actions in the [Step 1 — Define the Intent](/v1/docs/custom-signatures#step-1-—-define-the-intent) above.
  - **Sec Rule** — It helps you define security rules to analyze data as it passes through APIs. These rules are based on the [OWASP ModSecurity CRS](https://owasp.org/www-project-modsecurity-core-rule-set/), 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]
> 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 performs an AND operation across all the conditions defined in the rule.
4. **Target**— The API endpoints you want Traceable to monitor under this 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. The following table describes the different targets and their corresponding descriptions:

| Targets | Description |
| --- | --- |
| **All Services** | Apply the rule across all services that Traceable discovers and monitors. |
| **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*. |
  1. 
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** (![](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/traceable_edit_icon.png)) icon corresponding to a section.

---

## Actions available for a rule

After you add a rule, you can perform the following actions using the Ellipse (![traceable_ellipse_icon](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/traceable_ellipse_icon.png)) icon corresponding to a row:

- **Enable**or**Disable Toggle**— Use the toggle( ![](https://cdn.document360.io/24f14f07-13d1-4684-8fae-6d8f811768ee/Images/Documentation/image(28).png)) corresponding to a row to perform this action. It updates the status as active or inactive based on the enable or disable action, respectively.
- **Edit**—****Add or remove attributes as needed.
- **View** — View a rule after you have created it.
- **Clone** — Clone a rule to create a copy of an existing rule with the same values as the existing rule.
- **Delete** — Delete the rule.
- **Change Logs** — Log the changes of each activity occurring within the rule created.

Cookies are small pieces of data sent by a web server and stored on a user's device, typically a web browser. They are often used for session management, tracking user preferences, and maintaining state between HTTP requests. Cookies are not commonly used to transmit API Keys or other sensitive authentication information because they are more susceptible to various security vulnerabilities like cross-site scripting (XSS) attacks and cross-site request forgery (CSRF) attacks.

Custom Signature rules allow you to define precise conditions for evaluating incoming requests by examining attributes, such as headers, cookies, parameters, or payloads. By specifying operators and values for these attributes, you can detect and block malicious or unwanted traffic that may bypass default security protections. These rules provide fine-grained control over threat detection, enabling you to enforce security policies according to your requirements. Using these rules, you can improve your API and application security, reducing false positives, and address attack patterns that standard signatures may not cover.

Rule Evaluation Point indicates where Traceable evaluates a security rule as a request moves through your ecosystem. Depending on the deployment, Traceable evaluates the rules near the application, at the network edge, or within the platform. This determines how early Traceable inspects the request and whether it blocks, modifies, or monitors the traffic.

A comparison method where a fixed request or response component is evaluated against a predefined static value to determine if a condition is met.

A comparison method where two attributes from the request, response, or derived data are evaluated against each other to determine their relationship, instead of comparing against a fixed value.