Request filtering

To provide device intelligence, Fingerprint runs on the client device — inside the browser or a mobile application. Client-side code can be easily examined, therefore, the API key you use to make identification requests to Fingerprint is by definition a public API key.

To prevent malicious actors from misusing your public API key and inflating your Fingerprint costs, you can filter out unwanted identification requests. These requests are not billed and will receive an error instead of the identification result.

• On the web, you can filter requests by origin or HTTP header.
• For mobile applications, you can filter requests by the mobile app package name or bundle ID.

Request filtering for browsers

Inside the Dashboard, navigate to the App settings > Request Filtering.

Filter by website origin

You can create a blocklist or allowlist of specific origins.

• Allowlist: If you only need to use your public API key on a few origins, you should allow only those origins and block all others.
• Blocklist: If you need to use your public API key on many origins, you can choose to only block specific origins you suspect might be stealing your API key.

To filter requests by origin:

1. Navigate to the App settings > Request Filtering.
2. Under Websites, click Configure.
3. To create an Allowlist, set Default behavior to Forbid all besides origins listed below. Then fill in the Exceptions field with your list of allowed origins.
4. Alternatively, to create a Blocklist, set Default behavior to Allow all besides origins listed below. Then fill in the Exceptions field with your list of blocked origins.
5. Click Save.

📘

A website origin is defined by the scheme and the domain name of the URL used to access it.
You can use the wildcard character (*) as a subdomain name.

Filter by HTTP header

You can filter out identification requests by HTTP headers. Requests you might want to filter out include server-side rendering applications, crawlers, search indexing bots, or website availability monitors.

To filter requests by HTTP header:

1. Navigate to the App settings > Request Filtering.
2. Under Forbidden HTTP Headers, click Add rule.
3. Fill in the Header name.
4. Choose your Match Rule.
5. Fill in the Value. You can use regular expressions.

📘

Regular expressions in header rules

The regular expression (regex) match rule is defined by the RE2 notation. To make sure you are using the correct notation, you can:

1. Go to regex101.com.
2. Select the Golang Flavor option on the left.
3. Debug the regular expression to suit your needs.
4. Copy the Regular expression and paste it into the Value field in the rule form as-is.

Rule priority

1. Origin rules are checked first.
2. HTTP header rules are checked second.

Limitations

• The maximum number of request filtering rules on the web is defined by Account limits. If you need more request filtering rules, please reach out to our support team.
• It can take up to 5 minutes to start filtering incoming requests after creating or editing an origin or header rule.

Request filtering for mobile applications

ℹ️

Available only from Android SDK v2.4.0+ and iOS SDK v2.4.0+

You can specify which mobile apps are allowed or blocked from making identification requests using your public API keys. Filtered-out requests are not billed and will receive a PackageNotAuthorizederror instead of the identification result.

You can create mobile request filtering rules from the Fingerprint dashboard by specifying the package names (Android) or bundle IDs (iOS) of the blocked or allowed applications.

1. Navigate to the Dashboard > App Settings > Request Filtering > Mobile Apps.
2. Click Configure.
3. Choose the Default behavior:
   1. Allow all except the ones listed below: Fingerprint will block the specified apps from making identification requests. Requests from all other apps will be allowed.
   2. Forbid all except the ones listed below: Fingerprint will allow only the specified apps to make identification requests. Requests from all other apps will be blocked.
4. Fill in the Exceptions with the package names (Android) or bundle IDs (iOS) of the mobile application you want to allow or block. Wild cards are accepted.
5. Click Save.

For more information on handling errors, see Handling errors in Android SDK and Handling errors in the iOS SDK.

Search bot request filtering

Search bots generate legitimate internet traffic allowing search engines to index your website. But you might not want search bots to trigger Fingerprint Identification or Smart Signals processing.

Although you can filter requests based on the User-Agent header, you would need to manage your list of all different search bot User-Agent strings. Instead, we keep and update our own list of search bot filtering rules that can be turned on or off through a switch in the Dashboard.

Search bots that are filtered through this setting then behave in the same way as other request filtering rules and you don't get billed for them. Keep in mind that we won't return any information except requestId in those cases.

📘

Search bots filtering based on User-Agent is a basic mechanism we provide for free to filter out commonly encountered and generally well behaved search bots.

Because of its simplicity, it might introduce both false positive and false negative cases. If you need better protection against sophisticated bots, check out our Smart Signals that contain a paid Bot Detection product.

Configuration

Search Bots Filtering can be turned on or off in our Dashboard.

1. Navigate to App Settings > Request Filtering and switch to the Bots tab.
2. Enable Exclude Search Bots to start filtering search bots from your billable API calls.

List of Supported Search Bots User-Agent Strings

The list of search bot User-Agent strings we support is public and we keep it updated based on the currently supported User-Agent strings. The following table contains all supported User-Agent strings with their respective information sources.