Схема работы Digital Fraud Protection

Пошагово описываем взаимодействие DFP с вашим сайтом и бэкендом.

Принцип работы, кратко

  1. Вы подключаете JavaScript-скрипт DFP на нужную страницу сайта.

  2. Пользователь просто открывает эту страницу или выполняет на ней действие, для которого нужна проверка (момент срабатывания скрипта вы настраиваете сами).

  3. Скрипт собирает параметры клиентского окружения.

  4. Скрипт отправляет собранные данные на API DFP.

  5. DFP анализирует особенности сетевого взаимодействия при выполнении браузером запроса — например, информацию из TLS хендшейка и с L3/L4 сетевого уровня.

  6. DFP проводит итоговый анализ всех собранных данных. Затем упаковывает результат в JSON. Внутри указаны user_id, результат проверки на активность ботов, включён ли у пользователя VPN, пришёл запрос из хостинговой подсети или обычной и другие параметры. Читать полный список параметров.

  7. DFP шифрует результат и возвращает его в браузер.

  8. Браузер передаёт зашифрованный ответ на ваш бэкенд.

  9. Ваш бэкенд расшифровывает ответ, проверяет результат и применяет вашу бизнес-логику.

Схема взаимодействия

Схема работы DFP

Принцип работы, подробно

1. Вы подключаете скрипт на сайт

Вы встраиваете JavaScript-библиотеку DFP на страницу, где нужно проверить клиентское окружение и вероятность активности ботов.

Например, можно подключить скрипт на странице входа в аккаунт и проверить, со знакомого окружения или нет логинится пользователь.

2. Пользователь открывает страницу

При открытии страницы браузер загружает JavaScript-библиотеку DFP.

Рекомендуем настроить интеграцию так, чтобы сбор данных о клиентском окружении начинался как можно раньше (например, при открытии страницы), а их отправка в API DFP — в момент целевого действия (например, входа в аккаунт, отправки формы или подтверждения операции). Так вы будете получать ответ DFP быстрее и его точность будет выше.

Как это настроить, читайте в инструкции по интеграции.

3. Скрипт собирает данные клиентского окружения

Скрипт собирает параметры, которые помогают описать браузер и устройство пользователя.

Также вы можете передать в скрипте свою строку данных через поле customData. Она не будет включена в отпечаток. Это просто данные, которые DFP примет и вернёт вам в неизменном виде. Через customData можно передать дополнительный контекст запроса, чтобы завязать на него вашу бизнес-логику — например, можно отправить тип события или идентификатор формы, которую заполняет пользователь.

Второй вид данных, которые вы можете отправлять — customID. Как этот поле обрабатывается и как влияет на результат DFP, настраивается индивидуально под вас. Логику нужно согласовать с нашими инженерами отдельно.

4. Скрипт отправляет данные на API DFP, происходит анализ сетевого взаимодействия

После сбора данных скрипт отправляет запрос на API DFP, в инфраструктуру Servicepipe.

Внутри инфраструктуры запрос проксируется через ноды Web DDoS & Bot Protection, где установлено ПО, которое позволяет анализировать телеметрию запроса на L3-L7. Здесь собираются:

  • Данные автоматизации

  • Информация из TLS-хендшейка

  • Информация L3/L4 сетевого уровня

  • Информация об особенностях передачи браузером информации на сервер

Благодаря этому DFP получает более полную картину обращения, чем если бы анализировал только данные из браузера.

5. DFP формирует user_id

DFP создаёт отпечаток клиентского окружения и на его основе формирует user_id — стабильный идентификатор этого окружения.

Говоря проще, user_id — это ID, который описывает связку браузер+устройство. Он остаётся стабильным, даже если пользователь поменяет какие-то настройки устройства/браузера/сети, например:

  • включит VPN,

  • обновит ОС,

  • включит режим инкогнито,

  • поменяет время на компьютере,

  • обновит версию браузера.

ID будет тем же самым, ведь главный критерий выполняется: устройство и браузер остались неизменными.

А вот если пользователь откроет другой браузер или сделает запрос с другого устройства, вы увидите другой ID. Потому что для каждой пары браузер+устройство ID уникален.

Протестировать, как это работает, вы можете в нашем playground: открывайте эту страницу из разных источников, меняйте свои настройки — вы увидите, что User ID не поменяется, пока вы не смените браузер/устройство.

6. DFP формирует результат проверки остальных параметров

На основе анализа собранных данных DFP формирует значения полей:

  • bot_score — вероятность, что запрос отправил бот;

  • engine — движок браузера;

  • os — операционная система;

  • mobile — с мобильного устройства отправлен запрос или нет;

  • incognito — включён ли режим инкогнито;

  • vpn — используется ли VPN;

  • hosting — из хостинговой подсети пришёл запрос или из обычной;

  • bot_hosting — пришёл ли запрос из хостинговой подсети, откуда мы зафиксировали активность ботов или другую подозрительную активность.

Подробное описание полей читайте в статье Что значат поля из ответа DFP.

7. DFP шифрует результат

DFP шифрует payload и возвращает ответ в браузер. Помимо payload, в успешном ответе также есть служебные поля для расшифровки и диагностики:

  • cipher_type — алгоритм шифрования;

  • iv — вектор инициализации;

  • tag — тег аутентичности;

  • request_id — идентификатор запроса на случай, если нужно будет обратиться в поддержку.

Браузер получает ответ.

Сам браузер не должен принимать решение по результату DFP, потому что браузер — недоверенная среда. Логика решения должна быть реализована на вашем бэкенде.

8. Браузер передаёт ответ на ваш бэкенд

Скрипт отправляет зашифрованный ответ DFP на ваш бэкенд.

9. Ваш бэкенд расшифровывает payload

Для расшифровки используется секретный ключ, который вы получили от Servicepipe.

После расшифровки бэкенд получает поля payload в открытом виде.

10. Ваш бэкенд проверяет timestamp

На вашем бэкенде должна быть настроена логика: не принимать ответы DFP старше нескольких секунд. Эта важная мера убережёт вас от replay-атак. Как это работает, читайте в статье Как использовать timestamp для защиты от replay-атак.

Если ответ DFP свежий, обработка продолжается.

11. Ваш бэкенд проверяет user_id и другие поля

Ваш бэкенд проверяет значения полей payload: user_id, bot_score, engine, os, mobile, incognito, vpn, hosting, bot_hosting, custom_data.

Также он сверяет новые значения со старыми. Например, в вашей базе данных могут храниться соответствия аккаунтов и связанных с ними user_id — это удобно использовать, например, чтобы оценить, из знакомого окружения логинится пользователь (риска нет) или нового (появился риск-фактор). В упрощённом виде это может выглядеть так:

user_id user_account last_seen

U_101

account_A

2026-05-28

U_102

account_A

2026-05-28

U_203

account_B

2026-05-27

12. Ваш бэкенд применяет бизнес-логику

Дальше решение зависит от настроенных вами правил. Например:

  • пользователь пришёл из знакомого окружения и bot_score низкий — пропустить действие без дополнительной проверки;

  • пользователь заходит в знакомый аккаунт из нового окружения — запросить дополнительное подтверждение;

  • новое окружение прошло проверку — связать новый user_id с пользователем;

  • один user_id связан с несколькими аккаунтами — использовать как сигнал мультиаккаунтинга;

  • у обращения высокий bot_score и запрос идёт из хостинговой подсети, откуда мы зафиксировали активность ботов или другую подозрительную активность, — ограничить действие или отправить на дополнительную проверку.

Мы подготовили несколько готовых сценариев настройки, которые можно реализовать на вашем бэкенде с помощью данных DFP:

13. Ваш бэкенд сохраняет результат для следующих обращений

После обработки ваш бэкенд сохраняет в базе данных user_id и значения других важных для ваших сценариев полей.

Это пригодится при следующих обращениях. Например, при новом запросе DFP так же user_id, а ваш бэкенд сможет проверить, встречался ли этот ID раньше, с каким пользователем был связан и какое действие нужно выполнить.