Anti bot vendors explained

Why this matters if you run scraping infrastructure

Anyone who runs a scraping pipeline at any real scale eventually stops thinking about “getting blocked” as a single event and starts thinking about it as a vendor. A 403 on one site, a CAPTCHA wall on another, a silent shadow-ban on a third, these usually trace back to one of a small number of companies whose entire business is telling websites which requests are human and which aren’t. Understanding what those companies actually sell, and how their systems work, changes how you read your own error logs. It also matters if you’re on the defending side, deciding what to put in front of your own site or API.

This is not a guide to getting past any of these systems. It’s an explanation of what they are, what signals they collect, and why a request that looks fine to you can still get flagged. That’s the part worth understanding whether you’re running proxies, building a scraper, or trying to keep bots off your own checkout page.

What an anti bot vendor actually sells

An anti bot vendor doesn’t sell a firewall rule. It sells a risk score. The product sits between the origin server and the internet, usually as a reverse proxy or a CDN-layer module, and for every request it computes a probability that the request came from a script rather than a person. That score then drives a decision: pass, challenge, throttle, or block.

The reason this became a standalone industry instead of something every site builds in-house is that the signal set needed to score traffic accurately keeps expanding and keeps going stale. A fingerprinting technique that worked in 2023 gets adapted around within months, so vendors run this as a continuously updated service, not a static ruleset. Cloudflare, Akamai, DataDome, HUMAN Security (formerly PerimeterX), Kasada, and Imperva are the names an operator runs into most often, each with a different mix of the techniques below and a different appetite for how aggressively to challenge borderline traffic.

Network and transport layer signals

Before a single byte of your request payload matters, the vendor’s edge has already looked at how the connection itself was made. TLS handshakes have a fingerprint, commonly referred to by the shorthand JA3 or the newer JA4, built from the cipher suites, extensions, and elliptic curves a client offers in a specific order. Real browsers produce a fairly narrow, predictable set of these fingerprints because there are only a handful of browser engines in wide use. HTTP libraries and headless automation frameworks often produce a fingerprint that doesn’t match any real browser release, or matches a browser version that’s inconsistent with the User-Agent header sent later in the request. That mismatch alone is a strong signal.

IP reputation sits alongside this. Vendors maintain databases scored on the history of an IP or subnet: how much traffic it’s sent, whether it’s a known data center range, whether it’s previously triggered CAPTCHAs or been associated with credential stuffing. This is exactly why residential and mobile IP space behaves differently from data center IP space in front of these systems, a data center /24 has no cover traffic, while a carrier-grade NAT range on a mobile network carries thousands of real subscribers behind it, which changes the baseline probability the system assigns to any single request from that range.

Browser and device layer signals

For traffic that reaches a JavaScript challenge, the vendor’s script runs in the client and collects a much deeper fingerprint: canvas rendering output, WebGL renderer strings, installed fonts, screen and viewport dimensions, audio context fingerprints, the exact set and order of navigator properties, and timing characteristics of how the browser executes certain operations. None of these individually proves automation. Together, compared against the enormous baseline of real browser sessions the vendor has observed, they form a distribution, and headless or automated browser environments tend to sit at the tails of that distribution rather than in the middle of it.

This is also where a lot of automation tooling gets caught not because it’s doing anything malicious, but because it’s internally inconsistent. A browser automation stack that reports itself as Chrome 124 on Windows but exposes WebGL renderer strings associated with a Linux software renderer is flagging a mismatch that a real user’s machine would never produce. Vendors build detection around these inconsistencies precisely because they’re cheap to check and expensive for automation frameworks to fully eliminate.

Behavioral signals

The layer above device fingerprinting is behavioral: how the mouse moves before a click, the timing and rhythm of keystrokes, scroll velocity, and the sequence of pages visited relative to what a human shopping or browsing pattern usually looks like. This is the piece that’s hardest to fake convincingly at scale, because it’s not a static value to spoof once, it’s a continuous stream that has to look statistically like a human across an entire session, not just at the login page. DataDome, HUMAN Security, and Kasada in particular lean heavily on this layer, running models that score the entire session rather than a single request.

Honeypots are a low-tech but effective companion to behavioral scoring: hidden form fields or links that are invisible to a real browser rendering the page normally but visible to something parsing raw HTML. Filling in a field a human would never see, or following a link that’s positioned off-screen, is close to a guaranteed automation signal because there’s essentially no legitimate way for a human to trigger it.

Risk scoring and challenge escalation

None of these signals work in isolation. Vendors combine them into a composite score, typically through machine learning models trained on enormous volumes of labeled traffic across their entire customer base, which is part of why the large vendors have an advantage smaller in-house solutions don’t: they see patterns across thousands of sites, not just one. A session that scores low risk passes silently. A session in the middle gets an interactive challenge, a CAPTCHA, a proof-of-work puzzle, or a JavaScript computation that has to complete correctly and within a plausible time window. A session that scores high risk gets blocked outright, sometimes with a generic error page that gives no indication a bot system was even involved, which is itself a deliberate design choice, giving less feedback makes it harder to iterate against the system.

A brief note on the major vendors

Cloudflare’s Bot Management is deployed at the edge across a huge share of the web simply because Cloudflare is a CDN first, so its bot product benefits from visibility into an enormous volume of baseline traffic. Akamai’s Bot Manager has a similarly broad footprint through its CDN business and has historically focused heavily on the network and TLS layer. DataDome and HUMAN Security market themselves specifically as bot and fraud protection specialists rather than CDNs, and lean hard into behavioral and session scoring. Kasada is known for aggressive JavaScript-based challenges that are deliberately expensive to solve programmatically. Imperva rounds out the group with a product that sits alongside its WAF offering. None of these should be described as unbeatable or as a guaranteed wall, and none of them should be described as weak, either. What each one actually stops depends on the traffic pattern, the target site’s configuration, and how much of the vendor’s default tuning the site operator has left in place versus customized.

What this means in practice

If you operate scraping infrastructure, the practical takeaway is that a block is rarely explained by one bad thing you did. It’s usually a combination: an IP with poor reputation, a TLS fingerprint that doesn’t match the declared browser, a session with no mouse movement before a form submission, or a request rate inconsistent with how a human browses. If you operate a site and you’re evaluating one of these vendors, the questions worth asking are about false positive rates on real users, latency added to legitimate traffic, and how much visibility you get into why a given session was challenged, not just whether the vendor’s marketing claims a high block rate.

We write about this side of the infrastructure regularly at Data Research Tools because we run proxy fleets and scraping pipelines ourselves and deal with these systems as a daily operational reality, not a theoretical one.

Read more breakdowns of scraping infrastructure, proxy setups, and bot detection systems on our site here.

Get new guides and videos first — join the Telegram channel.