Enumeration

Enumeration is a method attackers use to test APIs with numerous distinct values, such as usernames or object identifiers, to determine which ones are valid. This technique is commonly used to discover sensitive records or confirm the existence of accounts. Traceable detects such patterns by tracking the volume of unique values submitted within a specified time window. When the defined limit is exceeded, Traceable can raise an event, continue monitoring, or enforce blocking based on the configured rule. This protection helps limit large-scale data discovery attempts and reduces the risk of unauthorized disclosure.

What will you learn in this topic?

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

• Understand how Enumeration Attacks work.

• Understand how to configure an enumeration rule.

• Understand how to define detection conditions based on API behavior.

• Understand how to apply actions to monitor or block suspicious activity.

Understand Enumeration

Before you configure enumeration rules, it is essential to understand how attackers probe APIs by sending a large number of unique inputs, such as usernames and email addresses, to identify valid data. Even when individual requests appear harmless, this pattern allows attackers to gradually discover accounts and sensitive records. Traceable detects this behavior by tracking how quickly unique values appear in API traffic and flags activity that deviates from normal usage. The table below explains when to use enumeration protection, why it matters, and how to apply it effectively.

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, it is essential to understand payload match, as described in the subsequent sections of Steps to Create a Rule.  Traceable supports two types of payload match when evaluating rule criteria:

• Static Payload match (default)

  In Step 1 of rule creation, Traceable uses payload match to evaluate request and response data against defined rule criteria. In a static payload match, 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 1 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 match 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

You can configure an enumeration rule to detect and prevent abuse patterns such as credential stuffing or data harvesting by monitoring API activity. These rules help protect sensitive data and prevent unauthorized access by identifying abnormal input patterns. To create an enumeration rule in Traceable, navigate to Protection → Settings → Policies → Custom Policies, open the Enumeration tab, and click + Add Rule. Complete the following steps:

1. Set the Criteria — Define where and how the rule applies by configuring the source, payload conditions, and target API scope.

2. Configure the Conditions — Specify thresholds such as unique values, time range, and evaluation scope to detect enumeration behavior.

3. Configure the Actions — Choose how Traceable should respond when the rule is triggered, such as blocking or monitoring traffic.

4. Review and Submit — Validate the configuration and activate the rule to enforce protection.

Step 1 — Set the criteria

As part of setting up the criteria, you must complete the following:

1. Rule Name — Specify a unique and identifiable name for the rule.

2. Description (Optional) — Provide a summary of the rule, for example, the type of threat it is designed to block.

3. Environment — Select the environment where Traceable should apply the rule according to your requirements.

4. Source Criteria — Define the traffic conditions on which the rule applies, for example, Region → Afghanistan. Traceable supports the following sources for creating an enumeration rule.

   Category	Source	Description
   IP-based	IP Address	Match traffic from specific internal or external IPs.
   	IP Type	Identify traffic from VPNs, bots, scanners, or proxies.
   	IP Organization	Filter traffic from known organizations that generate high request volumes.
   	IP ASN	Match traffic based on network provider (ASN).
   	IP Abuse Velocity	Detect IPs with high API abuse rates.
   	IP Reputation	Filter IPs flagged as high-risk by threat intelligence.
   User-based	User ID	Match specific users or patterns using regex.
   	User Agent	Identify clients, such as browsers, bots, or scripts, using regular expressions.
   Email-based	Email Domain	Match requests from specific or grouped email domains.
   Network context	Connection Type	Filter traffic from corporate or data center networks.
   Automation	Scanner	Detect traffic from automated testing or scanning tools.
   Geographic	Region	Apply rules based on country or geographic location.

   Note

   All Sources, except IP Abuse Velocity and IP Reputation, have an Exclude checkbox corresponding to their value field. When you select that check box, Traceable applies the policy to all values except the ones you choose.

5. Payload  — The payload on which you want to apply the rule. You can create the rule based on the following:

   Payload options	Field	Description
   Request / Response/Attributes	API Interaction	Select whether the rule applies to a request or response.
   	Component	Select API components such as URL, headers, or body.
   	Operator	Define the comparison logic (for example, contains, equals).
   	Value	Specify the value to match (for example, accounts).
   	Key	Select the attribute and operator (for example, authorization with exact match).
   	Value	Define the value for the selected key. Defaults to Any Value, but you can refine it. However, you can select a different one from the drop-down and specify the value accordingly. For more information, see Understand Payload Match.
   Data Sets or Data Types	Data Location	Specify where Traceable identifies the data (for example, request body).
   	Datasets or Datatypes	Select classified data types or datasets for rule evaluation. For more information, see Data Classification.

6. Target — The API endpoints you want Traceable to monitor under this rule. You can select one or more APIs or labels to which the rules should apply. The rule applies to all the underlying APIs when you select a label.

7. Once you have set the above criteria, click Next.

Step 2 — Configure the conditions

Define when the rule should trigger by setting limits on unique values and choosing how Traceable evaluates activity across users and endpoints. These settings help you detect abnormal patterns and differentiate enumeration behavior from normal API traffic. Use the following options to configure these thresholds and evaluation criteria.

1. Request scope — Apply these conditions to specific parts of the API request:

   • Request Body — Evaluate values in the request payload.

   • Path Parameters — Evaluate dynamic values in the URL path.

   • Sensitive Parameters — Evaluate classified or sensitive inputs.

2. Enumeration condition parameters — You can use these parameters to control when the rule triggers:

   Parameter	Description	Example
   Unique Values Exceed	Sets the maximum number of distinct inputs (such as usernames, emails, or IDs) allowed within the defined time window before Traceable triggers the rule.	10 unique usernames
   Time Range	Defines the time window during which Traceable tracks and evaluates unique values.	10 unique values within 5 minutes
   Compute Condition	Defines how Traceable evaluates activity by combining who generates the traffic and where it occurs.	Per user across all endpoints

3. Compute condition options — You can use compute conditions to control how Traceable evaluates activity across users and endpoints.

   Scope	Evaluation	Description	Example
   Per user	Per endpoint	Evaluates each user independently for each endpoint. Triggers the action when a user exceeds the limit on a specific endpoint.	If a user submits 12 unique usernames to /login and the configured limit is 10, Traceable triggers the configured action for that user.
   Per user	Across all endpoints	Evaluates each user across all selected endpoints combined. Triggers the action when a user exceeds the total limit.	If a user submits values across /login and /reset-password that exceed the combined limit, Traceable triggers the configured action.
   All users (aggregate)	Per endpoint	Evaluates the combined activity from all users on each endpoint. Triggers the action when total activity exceeds the limit.	If five users each send 20 unique values to /search within one minute and the combined activity exceeds the configured limit, Traceable triggers the configured action for all users.
   All users (aggregate)	Across all endpoints	Evaluates total activity across all users and endpoints. Triggers the action when overall activity exceeds the limit.	If combined traffic to/login and /signup exceeds the configured threshold, Traceable triggers the action globally for all users.

Step 3 — Configure the actions

As part of configuring the action, you must complete the following:

1. Perform selected action — Traceable provides the following options for handling the event generated by the enumeration rule. The options let you verify your rule, observe the generated events, and then block requests as needed. The following table describes the available event handling options and how Traceable responds when the rule conditions are met.

   Option	Description
   Block indefinitely	Permanently blocks the user when they meet the defined criteria. Prevents all further API requests.
   Block for a fixed duration	Blocks the user for a duration you specify after they meet the criteria.
   Block based on condition duration	Blocks the user for the same duration as the configured time range in the rule conditions.
   Monitor only (Do not block)	Does not block the user. Continues to monitor activity and generates events.
   Mark for Testing	Tests the rule without impact. Generates low-severity events and does not send notifications. View these events in Protection → Threat Activity using the Testing filter.

2. Severity of the generated event — Select the severity level for the generated event Low, Medium, High, and Critical. By default, Traceable assigns Low severity to the event.

   Note

   This option is available for all options except Mark for Testing above.

3. Data Injection — Add custom data to the request header to include additional context. Use this for monitoring and to highlight anomalies in requests.

   Note

   This option is available only when you select the Do not block, monitor only or Mark for Testing options above.

4. Once you have configured the above, click Next.

Step 4 — Review and submit

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