Intelligent Rate Limiting

Intelligent Rate Limiting (IntRL) is a feature of our Device Fingerprinting (DFP) product suite.

IntRL adds predictive analysis of device and traffic sub-signals in order to surface relevant trends and automatically rate limit attacks on applications by adding friction to high velocity traffic signals.

High-velocity traffic from a single origin is often an indicator of fraudulent activity. Traditional rate limiting methods rely on simple origin identifiers like IP Address that are both easily circumvented by sophisticated actors and can result in unintended rate limiting of good users sharing common IPs in settings like workplaces or university campuses.

Intelligent Rate Limiting combines signals to create a stable and highly unique targeting method for high velocity attacks and automatically adds increasing levels of friction to those attacks through our verdict response in /lookup calls.

IntRL introduces three new verdict.reasons[] values that map to detected anomalies:

Once the relevant time period has passed, the offending origin, as determined by signals gathered by DFP, will be eligible to move back to a less restrictive status.

{
	"created_at": "2024-08-24T07:00:00Z",
	"expires_at": "2024-08-24T07:05:00Z",
	"fingerprints": {
		"browser_fingerprint": "browser-fingerprint-0b535ab5-ecff-4bc9-b845-48bf90098945",
		"browser_id": "browser-id-99cffb93-6378-48a5-aa90-d680232a7979",
		"hardware_fingerprint": "hardware-fingerprint-4af7a05d-cf77-4ff7-834f-0622452bb092",
		"network_fingerprint": "network-fingerprint-b5060259-40e6-3f29-8215-45ae2da3caa1",
		"visitor_fingerprint": "visitor-fingerprint-6ecf5792-1157-41ad-9ad6-052d31160cee",
		"visitor_id": "visitor-6139cbcc-4dda-4b1f-b1c0-13c08ec64d72"
	},
	"status_code": 200,
	"telemetry_id": "026ac93b-8cdf-4fcb-bfa6-36a31cfecac1",
	"verdict": {
		"action": "BLOCK",
		"detected_device_type": "INTEL_WINDOWS_CHROME",
		"is_authentic_device": true,
		"reasons": ["RATE_LIMIT_EXCEEDED"]
	}
}

Intelligent Rate Limiting is baked into our DFP decisioning framework, and no additional implementation is required.

That said, there are some potential considerations depending on your integration with Device Fingerprinting:

1. If your risk engine today weights different verdict.reasons more than others, you may want to incorporate these new reasons into that framework with relevant weights.
2. These verdict.reasons are dynamic, and change over time. This means that:
   1. We don’t recommend permanently banning via the /rules endpoint for these verdict.reasons, but they do indicate that you should investigate more deeply and potentially take action.
   2. If your risk engine correlates DFP results to IP addresses within your risk framework, we recommend against banning IP addresses permanently based on SRL verdict.reasons as those verdicts may change over time as traffic patterns change.