---
title: "Custom Policies"
slug: "custom-policies"
status: "update"
updated: 2026-07-08T12:16:10Z
published: 2026-07-08T12:16:10Z
canonical: "traceabledocs.document360.io/custom-policies"
---

> ## 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 Policies

##### Updates (January 2026 to March 2026)

- *March 2026* — Updated the topic to add information about the dynamic match for the payload section in custom policy rule creation. For more information, see [Understand payload match](/v1/docs/custom-policies#understand-payload-match).

Custom Policies enable you to create rules for granular control over the application and API protection strategy. You can configure them to protect your application and APIs based on the source of traffic, specific traffic patterns, whether the traffic carries sensitive data, or the rate at which the application and API are accessed. The custom policies are composed of rule types that define specific security conditions. While collectively referred to as custom policies, each rule type operates independently to address different security concerns.

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

Custom Policies

---

## What will you learn in this topic?

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

- Understand why, when, and how to use Custom policies to enable granular, zero-trust control over API traffic.
- Identify the different rule types available under Custom Policies and their specific security use cases.
- Configure custom rules effectively, including defining intent, criteria, and enforcement conditions.
- Understand how to block and allow priority work.
- Understand how the allow action determines enforcement precedence and interacts with WAP and API Protection policies.

---

## Understand custom policies

Before you configure custom policies, it is important to understand how they translate your application’s security requirements into enforceable protection logic. The table below explains when to use custom policies, why they are essential for addressing gaps that default protections may not cover, and how you can implement them effectively to strengthen your API security posture with greater control and precision.

| Why use it? | When to use? | How can you leverage it? |
| --- | --- | --- |
| Custom Policies enable you to implement a zero-trust application and API protection strategy by applying granular security controls tailored to your application behavior and risk model. They help detect and control suspicious traffic patterns, block high-risk sources, protect sensitive data, and prevent abuse such as automated attacks or excessive application and API usage. | You can use Custom Policies when default protections do not fully address your security requirements. They are useful when you need fine-grained control over application and API traffic, such as restricting access by IP address or region, detecting unusual request patterns, limiting request rates, preventing enumeration attempts, or controlling access to sensitive data. | Define the rule intent (*Allow*, *Monitor*, or *Block*), configure matching conditions, such as traffic source, request attributes, or payload data, and specify enforcement criteria. Once enabled, the policy evaluates incoming app and API traffic and applies the configured action when the rule conditions are met. |

---

## Custom rule creation and rule types

The following table displays each rule type category and its description. Navigate to **Protection** → **Settings** → **Policies** → **Custom Policies** tab and click a particular tab to create the required rule:

| Rule Type | Description |
| --- | --- |
| [Malicious Sources](https://docs.traceable.ai/docs/malicious-sources) | Controls traffic based on high-risk indicators such as suspicious IP addresses, regions, VPNs, bots, or other identified malicious entities. |
| [Custom Signatures](https://docs.traceable.ai/docs/custom-signatures) | Defines precise allow, monitor, or block rules by inspecting specific request or response components against user-configured patterns and conditions. |
| [Rate Limiting](https://docs.traceable.ai/docs/rate-limitting) | Restricts the number of application and API requests within a defined time window to prevent abuse, automated attacks, and excessive resource consumption. |
| [Data Loss Prevention (DLP)](/v1/docs/dlp-1) | Enforces granular control over sensitive data access by defining who can access specific data types, under what conditions, and at what rate. Supports fine-grained configuration based on traffic source, IP address, IP type, user ID, region, attributes, and more. For the steps to create a DLP rule, see [Data Protection](https://docs.traceable.ai/docs/data-protection). |
| [Enumeration](https://docs.traceable.ai/docs/enumeration) | Detects and mitigates application and API Enumeration Attacks that use multiple unique values to perform Systematic Probing of endpoints, preventing data harvesting and unauthorized record discovery. |

> [!NOTE]
> Note
> 
> Before you define the custom policy rules or configure exclusion rules in Protection, make sure you understand how payload matching works. For more information, see [Understand payload match](/v1/docs/custom-policies#understand-payload-match).

---

## Block or allow priority

Traceable decides whether to block or allow user requests based on a defined priority. When you understand this priority, you can confidently configure policies with the right options and ensure your security rules behave exactly as intended. In Traceable, a threat actor can be blocked in either of the following ways:

- Manually move it to deny or suspend
- Rate-limiting rules
- DLP rules
- Enumeration rules
- Malicious source rules
- [Auto-blocking](https://docs.traceable.ai/docs/threat-management#auto-blocking)

In the event of a conflict, the following order of blocking preference is applied in descending order. Allow rules have a higher priority than blocking rules:

| Block or allow priority | Description |
| --- | --- |
| IP address(s) allow | Never block traffic from allowed IP address(s). |
| Threat actor(s) allow | Never block traffic from any IP address(s) the threat actor uses. |
| An email domain allows | Never block traffic for specific email domains. |
| Custom signature rule request allows | Never block traffic if it matches a custom rule. |
| Custom signature rule request blocking | Block an individual request if it matches a custom rule. |
| Signature-based (safe-crs) request blocking | Block individual requests if they match a signature rule. |
| All IP addresses are blocked except | Block all IP addresses except the listed IP address range. |
| IP blocked | Block specific IP addresses or a range of IP addresses. |
| Threat actor blocked | Block IP address(s) ever used by the particular threat actor. |
| Email domain blocked | Block specific email domains. |
| IP type blocked | Block IP addresses of a specific IP type. IP types could be: - Anonymous VPN - Hosting provider - Public proxy - Tor exit node - Bot - Scanner (in Rate Limiting, Data Loss Prevention, and Enumeration Policies only) |
| Block all email domains except | Block all email domains except the ones listed. |
| The region blocked all except | Block all regions except the ones listed. |
| Region blocked | Block specific regions. |
| Rate-limiting, DLP, and enumeration-based actor blocking | Block threat actors if rule conditions are met. |

> [!NOTE]
> Note
> 
> All external IP(s) are considered for blocking. By default, Traceable does not block internal IP(s). To enable blocking, you can contact [support@traceable.ai](mailto:support@traceable.ai) for the required language or gateway agent-specific flags, based on the Traceable Agent (TA) or Traceable Platform Agent (TPA) you have installed.

---

## Understand payload match

Before you proceed to create rules for different custom policies or exclusion rules in protection, make sure you have a fair understanding of payload matching. Traceable supports two types of payload match when evaluating rule criteria, as discussed in the tabs below:

**Static payload match (Default)**

When you proceed to create the rules, in the criteria step, 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. The following table displays the different elements, their descriptions, and those involved in a static payload match:

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

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

Static Matching

**Dynamic payload match**

When you proceed to create the rules, in the criteria step, 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 highlights the different elements, their descriptions, and examples involved in a dynamic payload match:

| **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 scenarios show different attributes, 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:

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

Dynamic Match Request Header Matching Example

****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 below 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:

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

Dynamic Match Request Attribute Example

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:

[Embedded content](https://demo.arcade.software/uDA0WkyKTrBrIsk1hizH)

---

## Allow action behavior across custom policies

When a request matches a rule configured with the *Allow* action in a custom policy, Traceable permits the request and stops further evaluation within custom policies.

### **Effect of allow action**

Once an *Allow* condition is met:

- Other custom policies do not block the request.
- Any *Block* or *Alert* actions in other custom policies are skipped.
- No additional alerts are generated within custom policies.

This behavior applies to all custom policy types that support the *Allow* action, including Malicious Sources and Custom Signatures.

### **Scope of the allow action**

The *Allow* action applies only to custom policies. Policies configured under **Protection → Settings → Policies → WAF** and **API Protection** continue to inspect and act on traffic independently. To exempt traffic from WAF or API Protection detections, configure an appropriate rule on the [Exclusion](https://docs.traceable.ai/docs/protection-exclusions) page.

When attackers systematically probe APIs to gather sensitive information, such as usernames or email addresses, by exploiting predictable responses. These attacks allow bad actors to map out valid data for further exploitation, like brute-force attacks or unauthorized access.

A method used by attackers to methodically test or query an API system, by sending a series of requests with different inputs with the goal to gather sensitive information.

A suspicious or malicious user, IP address, or entity identified by Traceable based on anomalous behavior, security events, and threat activity observed across APIs and applications

A Tor exit node is the final relay in the Tor (The Onion Router) network through which a user's encrypted traffic passes before reaching its destination on the internet. When someone uses Tor to browse the web or communicate online, their internet traffic is routed through several relays (also called nodes) in the Tor network to obscure their origin and enhance privacy. The destination server sees the exit node's IP address, not the user's, as the exit node requests on the user's behalf.

A rule that controls API request volume within defined time windows to improve traffic efficiency, prevent abuse, reduce sudden traffic spikes, and maintain application stability by enforcing configurable request thresholds and actions.