Should you block antidetect browsers or send them to review?

An antidetect browser signal deserves a stronger response than a VPN signal, but not an automatic one. A VPN says where the visitor is connecting from; a spoofed browser says the visitor is misrepresenting what they are. That difference is why Maskbreak’s base policy blocks on browser tampering and only reviews a VPN. This guide is about the exceptions: when review is the safer decision, where privacy tools cause false alarms, and how to measure what a policy costs before you tighten it.

If you are still deciding whether the signal is real in your traffic, run the antidetect detection test plan first. This guide assumes the check is in place and asks what to do with the result.

Why a fake browser is not a VPN

Millions of people use a VPN for privacy, for work or because their phone came with one. Almost nobody uses an antidetect browser (a “fake browser” in Maskbreak’s console) by accident: the product exists to run many separate identities from one machine and to make each look like a different person. That is the working method of multi-accounting, bonus abuse, referral fraud and card testing, described in preventing multi-accounting and aged account farming. So the prior is different: a VPN-only visit is usually a customer, an antidetect visit usually is not. A base policy should reflect that prior and leave room for the cases where it is wrong.

Block, review, allow: what each costs

“Review” only means something if your application enforces it. Maskbreak returns a recommendation; the integration guide shows how to hold the action on the server, verify the next step and refuse a test-mode result on a production action.

Where false alarms come from

A tampering signal means the browser did not behave like the product it claims to be. Three kinds of honest visitors can produce that:

• Privacy browsers. Firefox’s fingerprinting protection and Brave’s fingerprinting defences deliberately randomise or blank the same surfaces antidetect tools spoof. Tor Browser does the same on purpose. These users are rarely fraudsters, and they are also the users most likely to complain publicly when blocked.
• Blocked checks. Content blockers and strict shields can stop the browser check from running at all. That is not tampering; it is a missing result. Maskbreak reports which checks completed in device.checked_signals and whether the set was complete in device.complete, so a blocked check is not mistaken for a positive one.
• Unusual but legitimate environments. Virtual desktops, kiosk builds, enterprise images with hardware acceleration off, and your own QA automation. Automation is reported separately (automation_detected) from tampering (antidetect_browser), which matters here.

None of this means the signal is unreliable. It means the response must leave honest visitors a way through, and that you should count how often they need it.

A base policy that holds up

1. Block on tampering, automation or emulator signals for anonymous, first-contact actions: signup, trial start, bonus or referral claims, guest checkout. There is no relationship to protect yet and the abuse is cheapest to attempt here. This is Maskbreak’s default.
2. Review when the visitor has history. A signed-in customer with a verified email, past orders or a payment method on file who suddenly looks like a fake browser is more likely a new privacy setting than a takeover. Ask for a step-up (a code to the known email, a re-authentication) and continue if they pass. Maskbreak’s rules list fake browser (antidetect), tampered browser and bot/automation as separate signals, so you can move one to review while the others stay on block, and a combined rule covers VPN plus fake browser on the same visit.
3. Pin exceptions per visitor, not per country or network. When support confirms a real person, the event page’s “always allow” pin applies to that visitor’s future visits. Broad allow-lists by address or region are what proxy pools are built to exploit.
4. Never allow on a VPN plus tampering combination. Each alone has innocent explanations; together they are the profile-and-proxy pair described in how antidetect browsers and proxies give each other away.
5. Enforce on the server. A decision read only in the browser can be edited by the same tool that spoofed the browser.

Measure the cost before tightening

Before moving a signal from review to block, or a decision from allow to review, know three numbers from your own traffic: how many visits fire the signal, how many of those complete the step-up when offered, and how many of the completed ones later turn out to be abuse anyway. A high completion rate with low later abuse means review is working and block would cost real customers. A low completion rate means the visitors were not customers, and block is cheap. Rolling out fraud detection covers the monitor-then-enforce sequence, and risk score thresholds covers choosing cut-offs from your own distribution rather than a vendor’s example.

What to tell the person

Whatever the decision, the message should be short, neutral and actionable. Do not name the tool, the vendor or the signal; a real customer learns nothing from “antidetect browser detected” and a fraudster learns exactly what to change. For review: “We need one more step to continue. We’ve sent a code to your email.” For block: “We couldn’t complete this request. If you think this is a mistake, contact us with the reference below.” Include a reference the person can quote and keep the request ID from the API response in your logs next to it. The VPN false-positives guide has the same pattern for the review step, and the two decisions should read the same to the visitor even though your reasons differ.