<b>navigator.webdriver — самый дешевый сигнал автоматизации, но детектируется не только им</b>

<b>navigator.webdriver — самый дешевый сигнал автоматизации, но детектируется не только им</b>

navigator.webdriver — флаг из WebDriver spec, который многие антифрод-стэки проверяют первым. Если он true, это не приговор, но уже метка: браузер может быть под управлением Selenium, Playwright или другой обвязки. Если false, это тоже не гарантия — детект часто смотрит на связку признаков, а не на один boolean.

Разберем энтропию данного параметра: важен не сам факт наличия свойства, а способ его экспонирования. В Chromium браузерный контекст обычно получает navigator.webdriver через внутренние флаги автоматизации, а в JS-слое это выглядит как обычное readonly-свойство. Любая грубая подмена через Object.defineProperty оставляет след: дескриптор, прототипная цепочка, несовпадение с поведением соседних API.

Практика проверки проста:
— смотреть descriptor и enumerable/configurable;
— сравнивать поведение в top window, iframe и worker;
— сверять navigator.webdriver с сигналами CDP, permissions, plugins, languages;
— отдельно анализировать TLS Client Hello и паттерны сетевого стека, если нужен полный профиль.

Под капотом Chromium API это лишь один индикатор из набора. Опытные системы сопоставляют его с timing-сигналами, WebGL/Canvas, отсутствием человеческой вариативности и следами автоматизированного ввода. Поэтому спуфинг через инъекцию JS-кода без согласованной подмены остального профиля дает краткосрочный эффект и быстро разваливается на корреляциях.

Вывод простой: navigator.webdriver надо проверять, но не переоценивать. Убирают не флаг, а связность всего отпечатка — от JS-объекта до сетевого поведения.