<b>navigator.webdriver — это не флаг, а триггер цепочки детекта в браузере</b>

<b>navigator.webdriver — это не флаг, а триггер цепочки детекта в браузере</b>

В спецификации WebDriver это свойство служит маркером автоматизации: если оно true, фронтенд делает простой вывод о контролируемой сессии. Но на практике детект редко ограничивается одной проверкой. Обычно смотрят связку: наличие флага, поведение объекта Navigator, согласованность с Permissions API, WebGL, PluginArray и timing-паттернами.

Разберем энтропию данного параметра. Для Chromium важен не только сам результат чтения navigator.webdriver, но и то, как он получен: через getter, через дескриптор свойства, через контекст исполнения. Любая попытка примитивного подменивания через JS-инъекцию оставляет следы в структуре объекта и в цепочке прототипов. Скрипт на стороне сайта может сравнить native toString, конфигурацию дескриптора и наличие аномалий в instanceof/hasOwnProperty.

Типовая ошибка — “спрятать” webdriver одним ранним скриптом и считать задачу закрытой. Детект на уровне сетевого стека и рендер-поведения это не отменяет: автоматизация часто проявляется через несоответствие между navigator, canvas, медиа-устройствами и вводом. Если webdriver скрыт, но остальная поверхность выдает неестественную комбинацию признаков, риск только растет.

Практически корректный подход — не маскировать один флаг, а добиваться консистентности всей fingerprint-поверхности. Под капотом Chromium API это означает: контролировать контекст запуска, профиль, расширения, permissions, locale, timezone, UA-метрики и поведение DOM API как единый набор. Иначе anti-bot увидит не “браузер без webdriver”, а несогласованный стек.

Проверяйте не только значение свойства, но и соседние сигналы: если они расходятся, именно там и лежит детект.