navigator.webdriver — самый дешевый триггер детекта автотестов и антидетектов

navigator.webdriver — самый дешевый триггер детекта автотестов и антидетектов

Разберем энтропию данного параметра: в стандарте WebDriver это флаг, который должен сигнализировать о контролируемом браузере. Для антифрод-систем он почти всегда рассматривается не изолированно, а в связке с другими признаками: наличием DevTools Protocol, характером event loop, странностями в timing API и несостыковками между JS-слоем и сетевым стеком.

На практике проверяют не только само значение boolean. Смотрят, как ведет себя свойство в descriptor chain: enumerable, configurable, writable, доступно ли через Object.getOwnPropertyDescriptor, не ломается ли прототип при инъекции JS-кода. Если флаг скрыт грубо, детектор часто ловит следы патча: аномалии в toString, различия между frame context и isolated world, несоответствие в worker-контекстах.

Под капотом Chromium API это упирается в то, как браузер объявляет automation state на ранней стадии запуска. Поэтому попытка «просто вернуть undefined» обычно создает больше шума, чем пользы. Стабильная маскировка требует согласованности: navigator, permissions, plugins, error stack, WebGL и network headers должны выглядеть как один и тот же стек, а не набор заплаток.

Если нужен практический чек-лист: проверяйте descriptor свойства, поведение в iframe и worker, результаты в CreepJS и BrowserLeaks, а затем сравнивайте их с базовой отпечатковой моделью конкретного браузерного ядра. Любой ручной патч должен проходить не только JS-проверку, но и корреляцию с TLS Client Hello и остальными сигналами.

Вывод простой: navigator.webdriver — не самостоятельная проблема, а индикатор целостности всей маски. Лечить нужно не флаг, а согласованность окружения.