Вступление

Современный антифрод - это не «проверка на прокси» и не «бан по одному признаку». Это система, которая моделирует реальность пользователя и проверяет, насколько его среда может существовать в реальном мире. Любое несоответствие между слоями - сигнал риска.

Главная цель - не просто детект, а управление риском с минимальным влиянием на UX. Поэтому антифрод - это всегда компромисс: чем больше проверок, тем выше точность, но тем хуже пользовательский опыт.

Ключевая идея всей системы:

Архитектура: как это выглядит в реальности

Любая серьёзная система строится как распределённый pipeline:

• Edge (CDN / WAF)
• Backend (risk engine)
• Client (JS sensor)

На уровне браузера происходит сбор сырых данных: canvas, WebGL, audio, navigator, Intl, performance timing. На уровне сети фиксируются IP, ASN, TLS fingerprint, HTTP поведение. На backend происходит нормализация, агрегация и скоринг.

Важно, что антифрод - это не просто «if (bad) → ban». Это система весов, уверенности и корреляций. Один сигнал редко что-то значит. Значение появляется только в совокупности.

Многоуровневость: как система экономит ресурсы и позволяет обходить антифрод с минимальными усилиями

Современные антифрод-системы не проверяют всё сразу - и это не просто оптимизация, а фундаментальный принцип их работы. Полная глубина анализа слишком дорогая по ресурсам и задержкам, поэтому система вынуждена принимать решение постепенно, по мере накопления сигналов.

На первом этапе выполняются самые дешёвые и быстрые проверки: валидность payload, базовая консистентность браузера и общий IP/ASN контекст. Эти проверки практически ничего не стоят и позволяют быстро отсеять очевидный мусор.

Если профиль выглядит чистым и не вызывает противоречий, пользователь проходит дальше без включения тяжёлых механизмов. Именно здесь возникает ключевая особенность: если на раннем уровне нет триггеров, система часто не доходит до глубоких проверок вообще.

Если же появляются сомнения, антифрод начинает углубляться - подключаются проверки WebGL и Canvas, анализируется TLS fingerprint, ищутся признаки automation. Эти проверки уже значительно дороже и включаются только при наличии подозрений.

И только если риск остаётся неочевидным, система включает самый дорогой уровень - поведенческий анализ и корреляцию (device ↔ IP ↔ аккаунты). Это требует времени, данных и вычислений, поэтому применяется ограниченно.

Из этого вытекает важный практический вывод:
антифрод не видит «всё сразу» - он видит ровно столько, сколько его заставили увидеть.

Если удаётся пройти ранние уровни без триггеров, большая часть сложных проверок просто не активируется. Именно поэтому минимальные, но грамотно выстроенные изменения среды могут оказаться достаточными, чтобы существенно снизить вероятность детекта, не затрагивая более глубокие и сложные уровни анализа.

Таким образом, многоуровневость - это одновременно и способ масштабирования системы, и её ограничение.

Почему IP больше не идентификатор

Раньше антифрод строился вокруг IP - он использовался как основной идентификатор пользователя. Сегодня эта модель перестала работать.

Главная причина - изменение самой сетевой инфраструктуры. В условиях CGNAT один публичный IP может одновременно использоваться тысячами пользователей. В мобильных сетях ситуация ещё более выражена: IP динамически переиспользуются, а в крупных городах один адрес может обслуживать десятки тысяч абонентов. При этом один и тот же пользователь может сменить несколько IP за короткую сессию.

В результате IP потерял свою уникальность и больше не может выступать в роли надёжного идентификатора. Он остаётся важным сигналом, но используется как часть контекста, а не как источник истины.

Современная идентичность пользователя строится на комбинации сигналов:

device fingerprint + network context + behavior

Именно их согласованность, а не сам IP, определяет уровень доверия к пользователю.

Browser-first: где сегодня основной детект

Антифрод начинает с браузера, потому что:

• IP легко менять (VPN, прокси, ротация, NAT/CGNAT).
• Браузерный профиль сложно подделать целиком: можно изменить отдельные поля, но трудно сохранить согласованность всех слоев одновременно.

Система проверяет:

• совпадает ли UA с platform и заявленной ОС;
• совпадает ли platform с реальными браузерными API и supported features;
• соответствует ли GPU-идентичность фактическим WebGL/WebGPU возможностям;
• соответствует ли CPU execution timing заявленному классу устройства;
• совпадают ли intl, locale, timezone, language и сетевой контекст;
• есть ли следы автоматизации (CDP/WebDriver/headless/stack artifacts);
• нет ли внутренних противоречий между несколькими “независимыми” источниками одного и того же сигнала.

Принцип простой:

браузер может соврать в метаданных, но плохо врет в физике исполнения.
Под “физикой” здесь понимаются результаты вычислений, тайминги, ограничения железа и поведение API под нагрузкой.
Именно поэтому в browser-first антифроде главный фокус - не на одном поле, а на кросс-валидации: “что браузер заявил” vs “что реально показали вычисления и capability-тесты”.

Если эти два слоя расходятся, это самый ценный сигнал риска.

Глубокая проверка устройства (как реально ловят антидетекты)

Антифрод не ограничивается чтением “паспортных” полей браузера.
Главный детект начинается там, где система делает активные проверки и смотрит не на заявление клиента, а на фактическое поведение среды.

Что обычно тестируют:

• WebGL/WebGPU: renderer, vendor, limits, extensions, feature flags, shader-capabilities, compute/rt профили;
• Canvas: стабильность и воспроизводимость рендера, хэши, различия между контекстами;
• Audio: floating-point особенности и дрейф в обработке (а не только “поддерживается/не поддерживается”);
• Intl/Locale: реальные результаты форматирования дат/чисел/языковых данных;
• Performance: execution timing, стабильность и профиль задержек в контрольных вычислениях;
• API coherence: согласованность между независимыми источниками (navigator, графический стек, capability probes).

Ключевая логика:

• если браузер заявляет одно, а вычислительные тесты показывают другое - это сильный риск-сигнал;
• если противоречий несколько и они независимы, уверенность в детекте резко растет.

Примеры конфликтов:

• браузер заявляет: GPU = Intel UHD 630,
  а GPU-профиль/лимиты/поведение ближе к дискретной AMD/NVIDIA карте или к другому поколению Intel GPU - конфликт;
• браузер заявляет: 8 CPU cores,
  а execution timing и scaling в контрольных задачах похожи на слабый пк/эмуляцию - конфликт.

Почему это работает:

подделать строки можно, но сложно подделать физику исполнения сразу во всех подсистемах.
Именно поэтому глубокая проверка устройства - основной инструмент против современных антидетектов.

Automation detection: где палятся даже хорошие антидетекты

Современные антифроды действительно проверяют “классический набор”:

• navigator.webdriver;
• признаки CDP и remote debugging;
• patched/native API consistency;
• stack traces и execution frames;
• следы automation-runtime в окружении страницы.

Но сильные системы на этом не останавливаются.
Главный детект смещается из “что браузер говорит” в “как среда исполняет код”.

Что анализируют глубже:

• event loop поведение: джиттер, характерные задержки, блокировки;
• microtask/macrotask timing: очередность и стабильность исполнения;
• async semantics: цепочки Promise, postMessage, requestAnimationFrame, таймеры;
• scheduler profile: как распределяется нагрузка в JS runtime;
• consistency under stress: как среда ведет себя при сериях активных probe-тестов.

Почему это важно:

• метаданные можно подправить;
• один-два API можно замокать;
• но сложно синхронно подделать весь тайминговый и планировочный профиль исполнения без побочных артефактов.

Типичный паттерн палева “хорошего” антидетекта:

1. пассивные проверки выглядят чисто;
2. активные timing-пробы дают нестабильный или “нечеловеческий” профиль;
3. при повторе теста распределение задержек не соответствует нативной среде.

Именно поэтому системы уровня Kasada считаются сложными:
они делают ставку не на отдельные флаги, а на поведенческую физику runtime - то есть на то, как код реально живет во времени, а не на косметику отпечатка.

TLS fingerprint: слой, который ломает многие схемы

TLS fingerprint - один из самых сильных сигналов сетевого уровня, потому что он отражает не “что заявлено”, а как клиент реально строит защищенное соединение.

Обычно анализируют:

• набор cipher suites;
• TLS extensions;
• порядок и структура параметров в ClientHello;
• версии протокола, ALPN, key share и связанные negotiation-детали.

Почему это важно:

если клиент заявляет себя как “обычный Chrome”, но TLS-поведение похоже на Go/OpenSSL/нестандартный HTTP-стек, это сильное противоречие.
В живом трафике такие несовпадения часто являются признаком скриптовой автоматизации, прокси-прослоек или кастомного транспорта.

Именно поэтому TLS-слой активно используется крупными edge-платформами и бот-защитой (включая Cloudflare/Akamai):
он хорошо отделяет нативный браузерный трафик от эмулированного, даже когда заголовки и JS-фингерпринт “причесаны”.

Практический момент, который многим знаком:

многие сталкивались с ситуацией, когда запрос “вроде правильный” (с теми же URL, headers, cookies) отправляется через обычный HTTP-клиент и все равно получает challenge/403 на сайтах под Cloudflare.
Причина часто как раз в том, что header-уровень похож на браузер, а TLS-отпечаток - нет.

Сетевой уровень: что реально анализируется

Система смотрит:

• ASN и провайдера
• тип сети (mobile / residential / DC)
• репутацию подсети
• скорость смены IP
• географию

Дополнительно:

• fake ISP проверки (см. статью: [ссылка])
• исторические данные

Важно: один IP ничего не значит, но его поведение во времени - значит.

Где ломаются прокси (реальная причина)

Современный антифрод ловит не прокси, а невозможные комбинации.

Типичный кейс:

• IP → residential
• TLS → не браузерный
• WebGL → отличается от заявленного GPU
• behavior → слишком идеальный

Каждый сигнал сам по себе допустим.
Но вместе - нет.

Именно это и есть детект.

Разбор популярных антифрод-систем

Современные антифрод-системы, несмотря на схожую архитектуру, сильно отличаются по тому, на каком уровне они принимают основные решения. Это напрямую влияет на то, какие атаки они ловят лучше всего.

Сетевые решения, такие как Cloudflare и Akamai, делают основной упор на инфраструктуру. Они анализируют TLS fingerprint, HTTP-поведение, ASN и репутацию IP. Такие системы хорошо ловят несоответствия между заявленным браузером и реальным сетевым стеком, а также массовые аномалии трафика.

В отличие от них, системы вроде DataDome и Kasada смещают фокус на браузер. Они проверяют не только значения fingerprint, но и реальное поведение среды: WebGL, canvas, execution timing, наличие automation-артефактов. Особенно это заметно в Kasada, где ключевую роль играет не то, что браузер возвращает, а как он выполняет код.

Отдельный класс - поведенческие системы, такие как PerimeterX. Они могут пропустить пользователя с идеальным fingerprint, но зафиксировать неестественные паттерны: одинаковую скорость действий, отсутствие вариативности, повторяемость сценариев. Здесь детект происходит не на уровне устройства, а на уровне действий.

Наконец, есть системы, ориентированные на корреляцию, например ThreatMetrix. Они строят граф связей между устройствами, IP и аккаунтами и выявляют аномалии на уровне всей экосистемы. Даже если отдельная сессия выглядит чистой, связь с другими подозрительными активностями может привести к детекту.

В реальности эти подходы не существуют изолированно. Крупные сервисы комбинируют несколько типов антифрода, чтобы покрыть разные уровни: сеть, браузер, поведение и историю.

Если обобщить, все системы сходятся в одном:

• сетевой слой проверяет откуда пришёл пользователь
• браузерный слой проверяет насколько он реалистичен
• поведенческий слой проверяет как он действует
• корреляционный слой проверяет с кем он связан

Именно комбинация этих уровней даёт итоговый риск.

Главная причина, почему антифрод стал настолько сложным - это распределение детекта по разным слоям. Больше не существует одной точки, которую можно «починить».

Можно пройти сетевой уровень, но завалиться на браузере.
Можно пройти браузер, но спалиться на поведении.
Можно пройти всё это, но попасться на корреляции.

Именно поэтому современный антифрод - это не про поиск одного сигнала, а про проверку целостности всей системы пользователя.

| Антифрод | Browser fingerprint | WebGL / GPU | Automation | TLS fingerprint | IP / ASN | Behavior | Correlation | Execution timing | Основная сила |
|----------|-------------------|------------|------------|----------------|----------|----------|-------------|------------------|--------------|
| Cloudflare | базовый | частично | базовый | очень сильный (JA3/JA4) | очень сильный | средний | средний | слабый | сеть + TLS |
| Akamai | средний | частично | средний | сильный | очень сильный | сильный | сильный | средний | глобальная аналитика |
| DataDome | очень сильный | сильный | сильный | средний | сильный | средний | средний | средний | browser fingerprint |
| Kasada | очень сильный | средний | очень сильный | слабый | слабый | сильный | слабый | очень сильный | execution env |
| PerimeterX | средний | слабый | средний | слабый | средний | очень сильный | средний | средний | behavior |
| ThreatMetrix | средний | слабый | слабый | слабый | сильный | средний | очень сильный | слабый | identity graph |

Типичные ошибки, на которых палятся даже хорошие антидетекты

Большинство детектов происходит не из-за слабого прокси или конкретного инструмента, а из-за несогласованности между слоями.

Один из самых простых и показательных кейсов - несоответствие TLS и браузера. Пользователь может заходить с Chrome, но TLS fingerprint при этом соответствует другому стеку, например OpenSSL или кастомному клиенту. Такая комбинация не встречается в реальной среде и детектится практически мгновенно. На практике это часто связано с тем, что многие антидетект-браузеры при работе с прокси используют локальную прослойку - промежуточный клиент или туннель, через который проходит трафик. В этом случае TLS формируется не самим браузером, а этой прослойкой, и чаще всего там не воспроизводится нативный TLS стек Chrome. В результате возникает рассинхрон между тем, что заявляет браузер, и тем, как выглядит реальное соединение.

Похожая ситуация возникает с GPU. Браузер может заявлять один рендер и характеристики устройства, но реальные результаты WebGL или WebGPU тестов показывают другое поведение: отличаются доступные возможности, лимиты, точность вычислений или поддержка функций. Это часто происходит в антидетектах, где отпечатки подставляются статически, без привязки к реальному поведению среды. В итоге значения выглядят правдоподобно по отдельности, но не совпадают с тем, что браузер реально способен воспроизвести.

На уровне CPU и производительности логика аналогичная. navigator может показывать ожидаемые параметры - количество ядер, память - но execution timing не соответствует этим значениям. Антифрод в этом случае сравнивает не сами цифры, а фактическое время выполнения операций и выявляет расхождение между заявленным и реальным поведением.

Timezone и география сами по себе редко являются причиной детекта, но усиливают другие сигналы. Например, IP может определяться в одной стране, а локаль, язык и поведение соответствуют другой. В изоляции это допустимо, но в комбинации с другими несоответствиями повышает риск.

Поведенческий уровень - отдельный источник детекта. Даже реальные пользователи могут выглядеть подозрительно, если их действия слишком однообразны: одинаковые интервалы, повторяющиеся сценарии, отсутствие вариативности. В этом случае система фиксирует не индивидуальное поведение, а шаблон.

Ещё один частый сценарий - повторное использование одного и того же окружения. Когда один fingerprint появляется на разных аккаунтах, с разными IP и в короткий промежуток времени, это фиксируется на уровне корреляции. Здесь не важно, насколько «чистый» каждый отдельный сигнал - важна связь между ними.

Отдельно стоит ситуация с «идеально собранным» профилем. Полностью стабильные значения, отсутствие отклонений и одинаковое поведение выглядят неестественно, потому что реальные устройства всегда дают небольшую вариативность.

Во всех этих случаях проблема не в конкретном параметре, а в их сочетании. Можно иметь корректный IP, правдоподобный браузер и аккуратно собранный fingerprint, но если они не согласованы между собой, это фиксируется как несоответствие.

Почему большинство “чекеров” ошибаются, и как должна работать глубокая проверка среды

Большая часть публичных чекеров проверяет только базовый слой: пару полей из navigator, тип IP, иногда WebRTC и простые флаги автоматизации.
Проблема в том, что такой подход часто создает ложное ощущение точности: пользователь видит “чисто” или “подозрительно”, но не понимает, насколько вывод вообще надежен.

В чем слабость базовых чекеров

Многие чекеры:

• смотрят только “паспортные” данные браузера (UA, platform, language);
• не делают активных вычислительных тестов;
• не сверяют данные между независимыми слоями;
• не учитывают NAT/CGNAT и ограничения IP-аналитики;
• выдают результат без нормальной объяснимости.

Из-за этого пользователь может быть введен в заблуждение в обе стороны:

• получить “ок” при реально поддельной среде;
• получить “риск” на легитимной конфигурации (VPN, роуминг, корпоративная сеть, нестандартный драйвер и т.д.).

Как должен работать современный чекер

Сильный чекер оценивает не отдельные флаги, а внутреннюю согласованность среды:

• browser/device слой: API-consistency, WebGL/WebGPU, execution timing, automation-артефакты;
• network слой: ASN, тип сети, VPN/Tor/datacenter, провайдерный контекст;
• межслойная корреляция: совпадает ли то, что среда “заявляет”, с тем, что она реально “показывает”;
• риск-модель: не бинарный ярлык, а накопление независимых конфликтов с объяснением.

Что отличает наш чекер

Наш чекер построен именно как глубокая антифрод-проверка:

• проверяет среду по уровням, а не по одной метке;
• делает активные тесты, а не только читает поля;
• учитывает межслойные конфликты (browser ↔ network ↔ execution);
• снижает ложные срабатывания за счет нормализации и контекстной логики;
• отдает объяснимый результат: какие сигналы сработали и почему.

Итог простой:
обычные чекеры часто проверяют “витрину”, а не реальную среду.
Наш чекер проверяет именно поведение и согласованность системы, поэтому дает более надежную картину риска и меньше вводит пользователя в заблуждение.

Примеры результатов с чекера

Как увидеть внутреннюю логику антифрода через скрипты

Один из самых наглядных способов понять, как работает антифрод на странице - использовать скрипт, который перехватывает вызовы browser API в рантайме. Такой скрипт внедряется до выполнения основного кода страницы и позволяет увидеть, какие именно методы вызываются системой для анализа окружения.

Практически это делается через готовый скрипт (например, размещённый в Gist), который логирует обращения к WebGL, Canvas, Audio, navigator и другим API. После установки достаточно открыть сайт, обновить страницу и выполнить обычные действия пользователя - все вызовы будут фиксироваться в консоли DevTools.

Команды для анализа

• __afProbe.dumpTop()
  Показывает, какие API вызываются чаще всего - основной инструмент для понимания приоритетов антифрода.
• __afProbe.recent(50)
  Выводит последние события в порядке выполнения, помогает понять последовательность проверок.
• copy(__afProbe.exportJson())
  Копирует полный лог для анализа или сохранения.
• __afProbe.clear()
  Очищает данные перед новым прогоном.

Как читать результат

• Частые webgl.getParameter / webgl2.getParameter
  → активная проверка GPU и WebGL fingerprint
• Частые canvas.toDataURL / canvas.getContext
  → используется canvas fingerprint
• Частый Intl.DateTimeFormat.resolvedOptions
  → проверка timezone и locale
• Обращения к navigator.webdriver
  → базовый детект automation
• Вызовы offlineAudio.startRendering
  → используется audio fingerprint
• rtc.createOffer / rtc.createDataChannel
  → задействован WebRTC слой

Пример интерпретации результата

• В топе WebGL + Canvas + Intl
  → многоуровневый антифрод с глубокой проверкой среды
• В основном только navigator.*
  → простой уровень детекта
• Есть WebGL + Audio + Timing
  → продвинутый fingerprinting (уровень DataDome / Kasada)
• Добавляется WebRTC
  → проверяется сетевая согласованность

Финальный вывод

Современный антифрод - это не про прокси, не про браузер и не про ботов.

Это система, которая отвечает на один вопрос: может ли вся эта среда существовать в реальности?

Если ответ «нет» - пользователь получает риск.

И именно поэтому сегодня невозможно обойти антифрод одним трюком.
Нужно, чтобы вся система выглядела правдоподобно одновременно.