Custom Policies
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.
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.
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:
Controls traffic based on high-risk indicators such as suspicious IP addresses, regions, VPNs, bots, or other identified malicious entities.
Defines precise allow, monitor, or block rules by inspecting specific request or response components against user-configured patterns and conditions.
Restricts the number of application and API requests within a defined time window to prevent abuse, automated attacks, and excessive resource consumption.
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.
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.
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
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:
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.
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:
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.
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:
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:
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:
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 page.
Last updated
Was this helpful?