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.
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, review the following table to clearly understand their purpose, practical use cases, and implementation approach within your API protection strategy.
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 |
|---|---|
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. | |
Data Loss Prevention (DLP) | 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. |
Blocking or allowing 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:
Blocking or allowing 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:
|
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
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 for the required language or gateway agent-specific flags, based on the Traceable Agent (TA) or Traceable Platform Agent (TPA) you have installed.
Allow action behavior across custom policies
When a request matches a rule configured with the Allow action in a custom policy, Traceable allows it.
What happens when allow matches
Once an Allow condition is met:
Other Custom Policies do not block the request.
Any Block or Alert actions configured in other Custom Policies are skipped for that request.
No additional alerts are generated within Custom Policies.
This behavior applies across all custom policy types that support the Allow action, including Malicious Sources and Custom Signatures.
Allow does not override other policies
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.