Wykrywanie botów

Wykrywanie botów w TRACIO identyfikuje zautomatyzowane przeglądarki, narzędzia headless i ataki skryptowe dzięki dwuwarstwowej architekturze: zbieraniu danych po stronie klienta w agencie przeglądarkowym oraz analizie po stronie serwera. Obejmuje popularne frameworki automatyzacji, przeglądarki headless, agentów AI przeglądających sieć oraz przeglądarki anti-detect przy niemal zerowej liczbie fałszywych alarmów, a jednocześnie automatycznie dodaje legalne crawlery wyszukiwarek do listy dozwolonych.

Co wykrywa TRACIO

• Frameworki automatyzacji — Selenium, Puppeteer, Playwright, Cypress, PhantomJS, NightmareJS i podobne narzędzia.
• Przeglądarki headless — headless Chrome i pokrewne środowiska uruchomieniowe.
• Agenci AI przeglądający sieć — Browser-Use, Claude Computer Use, Fellou, Genspark, Skyvern i podobne środowiska agentów.
• Przeglądarki anti-detect — kompilacje przeglądarek, których celem jest podrobienie lub rotowanie odcisku.
• Zweryfikowane crawlery — Googlebot, Bingbot, Applebot, GPTBot, Yandex, DuckDuckGo i inne; weryfikacja jest tak skonstruowana, że podrobiony user-agent jej nie przejdzie.

Jak powstaje werdykt

Agent przeglądarkowy uruchamia szeroki zestaw kontroli i raportuje ich wyniki. Na serwerze wyniki są ważone we wskaźnik bota, a wskaźnik mapowany jest na werdykt. Niewielka liczba jednoznacznych wskazań rozstrzyga samodzielnie i wymusza werdykt bot niezależnie od reszty.

To, które kontrole są uruchamiane, jak są ważone i gdzie leżą progi, nie jest publikowane — w żadnym planie. Udokumentowanie tego powiedziałoby operatorom botów dokładnie, co zmienić, żeby ominąć ochronę. Zamiast tego otrzymujesz werdykt, etykietę typu bota oraz — w planie Business i wyższym — kody przyczyn, które nazywają klasę obserwacji stojącą za decyzją.

Format wyniku

Każda identyfikacja niesie werdykt dotyczący bota. Dociera do ciebie jako bot.result w payloadzie webhooka oraz jako result.bot w kliencie SDK.

Wartości werdyktu

Mapuje się to na biznesowe pole decision.action (real, fake lub suspicious), używane w całym panelu i w payloadzie webhooka.

Werdyktowi towarzyszy bot.score. W wersji 2 payloadu webhooka jest to liczba dziesiętna w skali 0..100 — dokładnie ta sama, którą panel pokazuje dla tej wizyty. (W zamrożonym schemacie w wersji 1 jest to ułamek w skali 0..1; zobacz Webhooks.)

Typy botów

bot.type jest obecny, gdy wynikiem jest bot. To albo nazwa rozpoznanego bota lub środowiska uruchomieniowego, albo rodzina, jeśli nazwanie konkretnej kontroli zdradziłoby wewnętrzną budowę detektora:

Lista jest domknięta celowo: kontrola dodana do detektora jutro pojawi się jako other, zamiast ujawnić swoją wewnętrzną nazwę. Traktuj bot.type jako etykietę do rozgałęzienia logiki, a nie jako wyczerpujący enum do walidacji — nowe nazwane środowiska dochodzą z czasem.

Kody przyczyn (Business i wyżej)

W planach Business i Enterprise payload webhooka niesie tablicę reasons — najwyżej osiem pozycji, posortowanych według istotności. Kod nazywa klasę obserwacji, nigdy kontrolę, która za nią stoi:

severity przyjmuje wartości high, medium lub low i oznacza udział tej klasy w werdykcie dla tej wizyty, a nie stałą właściwość kodu. Ten sam kod może przy jednej wizycie przyjść jako high, a przy innej jako low — nie buforuj go więc jako stałej.

Na szczególną ostrożność zasługuje privacy_hardening: uruchamia się zarówno przy zwykłych odwiedzających dbających o prywatność, jak i przy próbach obejścia. Waż go razem z resztą, zamiast działać wyłącznie na jego podstawie.

virtual_environment pochodzi z wykrywania emulatorów. W sieci nie ma osobnego werdyktu „działa pod hypervisorem”: poszlaki, które widzi przeglądarka — generyczny renderer programowy, nietypowo mała liczba rdzeni — równie często pojawiają się na zwykłych maszynach bez sterownika GPU oraz w sesjach pulpitu zdalnego, więc nie zamieniamy ich w werdykt, który trzeba by później podważać.

Dostępność w planach

Wskaźnik anti-detect jest wciąż kalibrowany. bot.antidetectScore jest raportowany po to, żebyś mógł go obserwować i dostrajać własną politykę — traktuj go jako wejście do swojej decyzji o ryzyku, a nie jako samodzielny powód do blokady.

Kontrole przeznaczone wyłącznie dla urządzeń mobilnych nie działają w sieci. Wykrywanie roota, jailbreaka, sklonowanych/zdublowanych aplikacji i narzędzia Frida opiera się na natywnych sygnałach mobilnych, których przeglądarka nie jest w stanie zebrać. TRACIO dostarcza wyłącznie SDK przeglądarkowe, więc opieraj się na werdyktach dotyczących automatyzacji, przeglądarek headless, agentów AI, kompilacji anti-detect, emulatorów i zachowania — te są w sieci w pełni aktywne.

Zweryfikowane crawlery

Znane „dobre” boty rozpoznawane są po swoim user-agencie, a następnie weryfikowane względem adresu IP połączenia — odwrotne zapytanie DNS o ten adres, sprawdzenie, czy uzyskana nazwa hosta należy do domeny operatora, oraz zapytanie w przód potwierdzające, że rozwiązuje się z powrotem na ten sam adres. To dokładnie ta procedura weryfikacji, którą publikują sami operatorzy crawlerów.

Zweryfikowany crawler daje wynik human. Żądanie, które twierdzi, że pochodzi od Googlebota, podczas gdy jego adres IP w sposób dowiedziony należy do kogoś innego, klasyfikowane jest jako bot — samo brakujące zapytanie lub zapytanie zakończone przekroczeniem czasu nie jest traktowane jako dowód podszywania się.

Analiza behawioralna

Dynamika interakcji — ruch wskaźnika, rytm pisania na klawiaturze, przewijanie — zasila werdykt jako dowód na to, czy obecny jest człowiek, a nie na to, który to człowiek. W planie Business i wyższym agregat dostarczany jest w bloku behavior webhooka:

{
  "behavior": {
    "score": 87,
    "verdict": "human",
    "confidence": 0.92
  }
}

score przebiega w skali 0..100 (wyżej = bardziej po ludzku), verdict przyjmuje wartości human, uncertain lub bot, a confidence (0..1) mówi, na jak dużej liczbie przesłanek werdykt się opiera — krótka wizyta z dwoma ruchami wskaźnika dostaje tu niską wartość nawet wtedy, gdy sam werdykt wygląda jednoznacznie.

Blok jest obecny tylko wtedy, gdy scoring behawioralny faktycznie został wykonany dla tej wizyty. Brak bloku oznacza „brak danych”, nigdy „nic podejrzanego” — nie czytaj jego nieobecności jako czystego sygnału.

Przykłady integracji

Blokowanie botów przy logowaniu (klient)

Klient SDK udostępnia wygodną wartość logiczną result.bot.detected oraz confidence w skali 0..100:

const result = await tracio.getResult()

if (result.bot.detected) {
  console.warn(`Bot detected (confidence ${result.bot.confidence})`)
  showCaptcha()
  return
}

await login(credentials)

Sprawdzanie botów po stronie serwera

Na swoim serwerze działaj na podstawie dostarczenia webhooka. Werdykt dotyczący bota znajduje się w obiekcie bot — bot.result i bot.type:

// `event` is the webhook delivery body (/docs/webhooks)
app.post("/webhook/tracio", async (req, res) => {
  const event = req.body

  if (event.bot?.result === "bot") {
    await db.blockedRequests.insert({
      visitorId: event.visitorId,
      botType: event.bot.type,
      ip: event.ip,
      timestamp: new Date(),
    })
  }

  res.status(200).send("OK")
})

Zerowe i puste wartości są pomijane w payloadzie, więc czytaj bot.type ostrożnie, zamiast wymagać go w swoich schematach.

Postępowanie z fałszywymi alarmami

Wykrywanie botów w TRACIO zaprojektowano tak, by fałszywych alarmów było niemal zero, ale przypadki graniczne się zdarzają:

Jeśli widzisz fałszywe alarmy, przejrzyj bot.type (a w planie Business i wyższym także reasons), żeby zrozumieć, która klasa obserwacji zadziałała, i dostosuj swoją politykę. Typowe przyczyny opisuje sekcja Rozwiązywanie problemów.