If you’re a Bot Manager Premier or Account Protector customer, you can define purposes of your API resources. Resource purpose settings define the expected usage of individual resources to protect your endpoints from bot traffic.
On the API Definitions page, in the Registered APIs section, open the more options menu next to the API configuration you want to configure resource purpose settings for.
From the menu, select Manage versions.
In the Version history panel, open the more options menu next to the API configuration version you want to configure resource purpose settings for.
From the list of delivery options on the left, select Resource purpose settings.
On the Resource purpose settings page, click + to add a new resource purpose configuration.
In the Resource purpose info section, enter the Name of the resource purpose configuration.
If you only specify one purpose of a resource, it’s best to use the same name for the purpose as you did for the resource. This will help you easily identify the purpose in your security configuration. If you specify multiple purposes of a resource (for example, two different purposes for GET and POST), use the name of the resource in combination with the method. For example:
In the Resource purpose info section, from the API resource menu, select the resource that you want to specify the purpose of.
In the Resource purpose info section, from the HTTP method menu, select the HTTP method used in combination with the resource.
In the Resource Purpose Details section, click API Resource Purpose Type and select the task this resource serves.
If you can’t find the exact task on the list, select the most similar option.
If you selected the Login type of resource purpose, in the Login resource details section, from the Username parameter menu, select the login parameter previously defined in the API resource panel.
To capture data on successful and unsuccessful attempts to use the resource, in the Origin Response section, define their traits.
You need to configure origin response for transactional endpoints is you use Account Protector. For Bot Manager Premier this step is optional.
You can set up success and failure reporting for every resource purpose type except Search and Add to cart.
Create your conditions in the Success conditions and Failure conditions sections.
a. In Response Code, select matches or does not match, and enter the code you want to track, like
You can enter multiple codes.
b. In Response Header, enter the header name, select matches or does not match, and enter the value you want to track.
To add another response header, click Add.
c. In Set-cookie, enter the cookie name and select matches or does not match.
You can use * and ? wildcards and you can turn the Case-sensitive switch on.
If you define:
– only failure conditions, then any other activity on the endpoints is treated as success.
– only success, then any other activity is a failure.
– both failure and success, then any other activity is labeled as unknown.
– no conditions, then all activity on the endpoints is labeled as unknown.
After you set the conditions, successes, failures and unknown activity appear in the Bot Endpoint Protection report.
Optional: If requests to protect by Bot Manager Premier always include parameters, then in the Additional required parameters section, do the following for every parameter that you want to configure:
Usually, you won't add parameters here. Do so only if you want to protect ONLY specific requests that include the parameter. Requests without it, won't undergo Bot Manager Premier detection.
a. Click Add parameter
b. From the leftmost drop-down menu, select the parameter that you want to configure.
c. From the rightmost drop-down menu, select the condition that the parameter should meet.
d. If you selected the matches condition, enter the text that the parameter should match.
Do not enter a parameter here unless you want to protect ONLY those specific requests. If your app accepts requests without the parameters you define, those requests would likely bypass bot protections. Proceed carefully. The need to set parameters here is rare (for example, in the case of GraphQL applications).
Updated 9 months ago