На нашому тестовому стенді звичайний браузер і скрипт Playwright відкривають ту саму сторінку. Але JavaScript-перевірка бачить різницю: автоматизація повідомляє про себе через navigator.webdriver, інший user-agent та набір доступних можливостей. Після зміни профілю частина індикаторів зникає. Це показує, наскільки обмеженою може бути перевірка за кількома ознаками.
У відео VAPAN про антиботів ми порівнюємо ці запуски, розбираємо браузерні сигнали, перевірки Cloudflare та доступ до сервера за проксі. Тут зібрали пояснення для розробників і власників сайтів: що означають результати демонстрації та де потрібен захист у самому застосунку.
Антибот і антифрод вирішують різні задачі
Автоматичне збирання цін, масові спроби входу та перевірка вразливих плагінів виглядають по-різному, хоча всі можуть виконуватися скриптами. Антибот оцінює автоматизацію запитів. Антифрод оцінює ризик конкретної дії: входу в акаунт, покупки або платежу. Людина теж може виконувати шахрайські дії, а автоматичний запит може бути корисним моніторингом чи пошуковим роботом.
Тому рішення залежить від ресурсу. Для каталогу важливі частота запитів і навантаження. Для входу потрібні обмеження спроб та захист акаунта. Для оформлення замовлення потрібно перевіряти саму операцію, навіть якщо браузер уже пройшов challenge.
Що показав запуск Playwright
На 2:31 у відео запускаємо браузер через Playwright у headless-режимі. На стенді видно navigator.webdriver: true, user-agent з ознакою Headless Chrome та відмінності в інших сигналах середовища. Власна оцінка ризику стенда зростає.
Headless означає роботу браузера без видимого вікна. Це справжній браузерний рушій, який виконує JavaScript і працює з DOM. Його використовують для тестів, створення скриншотів та інших задач автоматизації. Документація Chrome описує сучасний headless як режим того самого браузера.
Властивість navigator.webdriver дає сторінці стандартний сигнал про автоматизоване керування. За документацією MDN, її значення залежить від способу запуску браузера. Значення true корисне для діагностики, але саме по собі не пояснює намір відвідувача. Значення false теж не доводить, що перед вами людина.
Для власної сторінки можна почати з простого огляду середовища:
javascriptconsole.table({
userAgent: navigator.userAgent,
automated: navigator.webdriver,
language: navigator.language,
logicalProcessors: navigator.hardwareConcurrency
});Цей код лише показує доступні значення. Він не є готовим антиботом. Параметри можуть відрізнятися через налаштування приватності, браузер або пристрій користувача.
Чому узгодженість сигналів важлива
На 3:14 змінений браузерний профіль отримує нульову оцінку ризику в нашому стенді. Це результат конкретного набору перевірок у демонстрації. За ним не можна робити висновок про проходження Cloudflare чи іншого сервісу захисту.
Наступна частина відео пояснює узгодженість: чи складаються окремі сигнали в правдоподібну картину. Якщо user-agent описує одну платформу, а доступні браузерні властивості вказують на іншу, це привід для додаткової перевірки. Підміна одного поля може створити нову суперечність.
Водночас незвичайна комбінація не дорівнює атаці. На неї можуть впливати розширення, налаштування приватності й особливості середовища. Правило «одна дивна ознака, одразу блокування» здатне відсікти справжнього клієнта. Для власника сайту важливо дивитися і на підозрілі запити, і на людей, які не можуть завершити нормальну дію.
CDP і межі браузерних пасток
На 4:07 показуємо перевірку, пов’язану з відлагодженням браузера. CDP, Chrome DevTools Protocol, дає інструментам можливість керувати Chromium та спостерігати за його роботою. У демонстрації JavaScript Proxy допомагає помітити звернення до властивостей об’єкта під час обробки консольного повідомлення.
Такі прийоми залежать від версії браузера, підключених інструментів і способу роботи з консоллю. Читання властивостей або довга обробка повідомлення не дають універсального доказу шкідливого бота. Для розробника це допоміжний сигнал, який треба перевіряти на своєму середовищі й оцінювати разом з іншими подіями.
Cloudflare challenge і Turnstile у формі
На 6:26 запит потрапляє на сторінку перевірки Cloudflare. Замість вмісту сайту клієнт отримує проміжну сторінку, яка виконує перевірки в браузері. Звичайний HTTP-клієнт на кшталт curl сам по собі не виконає її JavaScript. Така відповідь ще не означає, що застосунок обробив запит.
Варто розрізняти проміжну Challenge Page та віджет Turnstile, який ви додаєте у власну форму. Видима успішна перевірка у формі дає токен, але сервер має перевірити його через Siteverify, перш ніж приймати захищену дію.
Cloudflare вимагає серверної перевірки токена. Токен діє п’ять хвилин і використовується один раз. Тому приймати заявку лише тому, що браузер надіслав непорожнє поле з токеном, недостатньо.
Практична перевірка форми проста: валідний токен дозволяє продовжити дію; відсутній, прострочений або повторно використаний токен має бути відхилений. Окремо перевірте, що віджет з’являється після переходу на сторінку через меню та після повторного відкриття форми.
Навіщо дивляться на TLS-відбиток
На 9:06 говоримо про JA4. Під час встановлення TLS-з’єднання клієнт надсилає параметри рукостискання. На їхній основі можна групувати клієнтів зі схожими характеристиками. Заміна текстового user-agent не змінює автоматично мережеву поведінку програми.
Cloudflare описує JA3 і JA4 як відбитки TLS-клієнтів. Це допомагає аналізу трафіку, але не є посвідченням конкретної людини: різні запити можуть мати однаковий відбиток. Доступність цих можливостей також залежить від підключеного продукту й тарифу.
Відкритий origin залишає інший шлях до сайту
На 8:39 демонструємо важливу помилку конфігурації. Домен працює через Cloudflare, але сервер, origin, доступний напряму. Якщо він приймає той самий вебзапит поза проксі, перевірки на вході Cloudflare не беруть участі в цьому маршруті.
Знати IP і мати можливість звернутися до застосунку напряму це різні речі. IP може бути відомий, але доступ до вебпортів повинен відповідати вашій архітектурі. Cloudflare рекомендує захищати origin через обмеження доступу, автентифікацію з’єднань або Tunnel. Вибір залежить від того, які сервіси мають лишатися доступними.
Для перевірки власної конфігурації почніть з маршруту запиту: чи доступний вебзастосунок напряму, чи проходить він через запланований захисний шар і чи однаково захищені форми та API. Налаштовуючи firewall, врахуйте моніторинг і адміністративний доступ, щоб не відрізати потрібні з’єднання.
Далі перевірте авторизацію в самому коді. Пройдений challenge не дає користувачу права читати чужі замовлення чи змінювати чужий акаунт. На кожній захищеній операції застосунок має перевіряти доступ. Про таку помилку окремо розповідаємо в глосарії IDOR, а про ризики застарілого WordPress у розборі WP2Shell.
Якщо ваш сайт за Cloudflare усе одно отримує спам або блокує клієнтів, для початку потрібні приклади запитів, логи перевірки токенів та схема доступу до origin. З цим можна звернутися до нас щодо налаштування сервера або автоматизації та інтеграцій. У повному відео видно, як ці сигнали та маршрути поводяться на стенді.
