Fraudsters never stop improving in their quest to remain unblocked. In recent years, bots as a service have helped fraudsters automate their scraping. Over the last few months, however, a new favorite tool has emerged: anti-detect browsers. This kind of software is not new, but recently became more useful when it comes to scraping, scalping tickets, click farming, massive fake account creation, or recommendation farming. While these browsers were historically manually created and used, they are now automated—allowing bots to leverage their features at scale.

This article presents anti-detect browsers, their differences with BaaS, and how to block them.

How Anti-Detect Browsers Differ From BaaS

At first glance, BaaS and anti-detect browsers both aim for easing bot and fraud tasks without being banned. However, the latter is more powerful when it comes to bypassing signature detection.

On one hand, BaaS is a “click and collect” web service to which a fraudster forwards URLs and, if the BaaS is successful, retrieves the content from the responses. On the other hand, an anti-detect browser is software that needs to be installed locally on the fraudster’s device. This slight difference is the key to the power of anti-detect browsers: it allows a deep configuration that BaaS cannot offer.

No Clear Winner: Server-Side Fingerprints

In terms of configuration, fraudsters primarily care for controlling a bunch of parameters—server-side fingerprints—to look human:

• IP Geolocation: Ideally, matches the country of the merchant website.
• Language: Should be consistent with the geolocation.
• Referrer: Consistent with the URL browsed (for example, no referrer on the cart page is abnormal).
• Credible User-Agent: Usually the latest version of Chrome, as it is the most popular browser.
• TLS Fingerprint: Consistent with the device claimed in the user-agent.
• Other: Extra HTTP headers and cookies that websites set for various purposes.

All of these values are configurable by anti-detect browsers or handled by the BaaS provider, so there’s no clear advantage with either technology.

The Advantage of Anti-Detect Browsers: Client-Side Fingerprints

However, forging server-side fingerprints is not enough to bypass anti-bot protections. A browser is not only a set of fields in the HTTP request—it’s also a software humans interact with. As such, anti-bot protections also collect part of the activity in the browser through JavaScript (JS), such as mouse positions and movements, device fingerprints, browser capabilities, etc.

With client-side fingerprints also being scrutinized, fraudsters have two options to mimic multiple real browsers in parallel: either they run a real browser (on a real device or in a virtual machine), or they integrate a headless browser in their script.

This is where anti-detect browsers have a significant advantage over BaaS. Fraudsters don’t directly see how a BaaS simulates a browser and will execute JS (if they do). They send their URLs to the BaaS with some headers for the request and wait for the response. Anti-detect browsers, on the other hand, simulate one complete profile per task:

• One proxy IP per task. For scraping, one task = one URL to scrape; for scalping, one task = one purchase; for fake account creation, one task = one registration attempt; and so on.
• A set of server-side fingerprints, consistent with the device claimed in the user agent.
• A set of device fingerprints, consistent with the server-side ones.

The concept of one task/one profile is important. For example, when it comes to firing thousands of registration attempts, the more a profile (or part of one) is reused, the higher its risk of getting detected and blocked. In other words, anti-detect browsers containerize all signals that could represent one single human in a profile and ensure a profile is unique per task.

The figure below is taken from Dolphin-anty. It shows the creation of a profile where we select every single fingerprint, client- and server-side, for the browser we are creating. For each element, we can choose either the real value—the one from the device—or a fake value—entered manually or generated by the software.

The Secret Weapon of Anti-Detect Browsers: Randomization

In addition, anti-detect browsers handle the randomization of parts of the fingerprints to generate multiple independent profiles, and hence multiple “humans”. For example, anti-bot solutions collect screen sizes, audio, media, graphical capabilities and rendering, and can challenge the supposed browser with a puzzle to build in a canvas HTML tag. All of these signals can be randomized.

# example on randomizable device fingerprints and capabilities
{
"webGL_renderer":"ANGLE (Intel, Intel(R) HD Graphics 6000 Direct3D11 vs_5_0 ps_5_0, D3D11)",
"webGPU_info": "vendor:intel,architecture:gen-12lp",
"screen_height": 1440,
"screen_width": 2560,
"device_memory": 8,
"color_depth": 24,
...
}

Therefore, given an operating system and a browser name, anti-detect browsers generate adequate profiles from their knowledge base on WebGL vendors, graphic cards identifiers, etc. The randomization allows fraudsters to attack with tons of unique profiles and add noise in their fingerprints to avoid creating an abnormal volume of requests from the same profile.

However, the randomization comes with the challenge of remaining consistent: the combination of all the values in a profile should still reflect a browser used by a human on a real device. Otherwise, all the noise added is useless. That’s what detection can leverage to block them.

How to Block Anti-Detect Browsers

The randomization in anti-detect browsers is a challenge for bot protection software: when the unlikely signature is detected, it might be already too late and the fraud is already committed. Nevertheless, DataDome can rely on behavioral detection and inconsistencies to detect them. For example:

• Anti-detect browsers do not handle proxy IPs. Fraudsters provide their lists or API keys to a proxy service and the software uses them. Then, two cases can be observed in the detection:
  • The pool of IPs is insufficient for the anti-detect browser, and the profiles will not be that unique. This creates inconsistencies that can be detected.
  • The pool of IPs is sufficient, but poorly sourced. The standard detection of low-reputation IPs applies in this scenario.
• Anti-detect browsers do not simulate a session. They execute all the requests tied to a task in an isolated profile. Therefore, if the chain of requests is not plausible, behavioral detection will identify the anomaly.
• Randomization might create inconsistent profiles.
  • Identifiers and versions are often generated, but some values do not exist at all, allowing bot protection software to detect and block the requests.
  • Some unlikely combinations of value—like a GPU brand with an inconsistent canvas fingerprint for the brand—can be detected and blocked.

Conclusion

While BaaS offers “click and collect” tools that lower the entry level for fraudsters, anti-detect browsers are one more step in sophistication that require good knowledge to configure it properly. In addition to bringing highly human fingerprints, the randomization increases the chance of staying under the radar. However, randomization is not perfect and a great part of the success relies on the fraudster’s ability to also simulate human behavior.