Bot-Erkennung

Die Bot-Erkennung von TRACIO identifiziert automatisierte Browser, Headless-Tools und skriptbasierte Angriffe mithilfe einer zweischichtigen Architektur: clientseitige Erfassung im Browser-Agenten und serverseitige Analyse. Sie deckt gängige Automatisierungs-Frameworks, Headless-Browser, KI-Browsing-Agenten und Anti-Detect-Browser mit nahezu null Falsch-Positiven ab und setzt legitime Suchmaschinen-Crawler automatisch auf die Allowlist.

Was TRACIO erkennt

• Automatisierungs-Frameworks — Selenium, Puppeteer, Playwright, Cypress, PhantomJS, NightmareJS und ähnliche Werkzeuge.
• Headless-Browser — Headless Chrome und verwandte Runtimes.
• KI-Browsing-Agenten — Browser-Use, Claude Computer Use, Fellou, Genspark, Skyvern und ähnliche Agent-Runtimes.
• Anti-Detect-Browser — Browser-Builds, deren Zweck es ist, den Fingerabdruck zu fälschen oder zu rotieren.
• Verifizierte Crawler — Googlebot, Bingbot, Applebot, GPTBot, Yandex, DuckDuckGo und weitere, verifiziert, sodass ein gefälschter User-Agent nicht durchkommt.

Wie das Verdict zustande kommt

Der Browser-Agent führt eine breite Menge an Prüfungen aus und meldet deren Ergebnisse. Auf dem Server werden die Ergebnisse zu einem Bot-Score gewichtet, und der Score wird einem Verdict zugeordnet. Eine kleine Zahl eindeutiger Indikatoren ist für sich allein entscheidend und erzwingt unabhängig vom Rest ein bot-Verdict.

Welche Prüfungen laufen, wie sie gewichtet werden und wo die Schwellenwerte liegen, wird nicht veröffentlicht – in keinem Tarif. Eine Dokumentation davon würde Bot-Betreibern genau sagen, was sie ändern müssen, um an der Absicherung vorbeizukommen. Was Sie stattdessen erhalten, ist das Verdict, ein Bot-Typ-Label und – ab Business – Reason Codes, die die Klasse der Beobachtung hinter der Entscheidung benennen.

Ergebnisformat

Jede Identifikation trägt ein Bot-Verdict. Es erreicht Sie als bot.result im Webhook-Payload und als result.bot im Client-SDK.

Verdict-Werte

Dies wird dem geschäftlichen Feld decision.action (real, fake oder suspicious) zugeordnet, das im gesamten Dashboard und im Webhook-Payload verwendet wird.

bot.score begleitet das Verdict. In Webhook-Payload-Version 2 ist es ein Dezimalwert von 0..100 – genau die Zahl, die das Dashboard für diesen Besuch anzeigt. (Im eingefrorenen Schema der Version 1 ist es ein Bruchteil 0..1; siehe Webhooks.)

Bot-Typen

bot.type ist vorhanden, wenn das Ergebnis bot lautet. Es ist entweder der Name eines erkannten Bots oder Runtimes oder eine Familie, wenn das Benennen der konkreten Prüfung Interna des Detektors offenlegen würde:

Die Liste ist bewusst geschlossen: Eine morgen ergänzte Prüfung erscheint als other, statt ihren internen Namen preiszugeben. Behandeln Sie bot.type als Label, an dem Sie verzweigen, nicht als vollständiges Enum, gegen das Sie validieren – im Laufe der Zeit kommen neue benannte Runtimes hinzu.

Reason Codes (ab Business)

In den Tarifen Business und Enterprise enthält der Webhook-Payload ein reasons-Array – höchstens acht Einträge, nach Bedeutung sortiert. Ein Code benennt die Klasse der Beobachtung, niemals die dahinterstehende Prüfung:

severity ist high, medium oder low und beschreibt den Anteil, den diese Klasse am Verdict dieses Besuchs hat – keine feste Eigenschaft des Codes. Derselbe Code kann bei einem Besuch als high und bei einem anderen als low eintreffen; speichern Sie ihn deshalb nicht als Konstante zwischen.

privacy_hardening verdient besondere Sorgfalt: Er löst bei ganz normalen, datenschutzbewussten Besuchern ebenso aus wie bei Umgehungsversuchen. Wägen Sie ihn zusammen mit dem Rest ab, statt allein danach zu handeln.

virtual_environment stammt aus der Emulator-Erkennung. Im Web gibt es kein eigenes Verdict „läuft unter einem Hypervisor“: Die Hinweise, die ein Browser sehen kann – ein generischer Software-Renderer, eine ungewöhnlich niedrige Kernzahl – treten ebenso häufig auf ganz normalen Rechnern ohne GPU-Treiber und in Remote-Desktop-Sitzungen auf; deshalb machen wir daraus kein Verdict, das Sie hinterfragen müssten.

Verfügbarkeit nach Tarif

Das Anti-Detect-Scoring wird noch kalibriert. bot.antidetectScore wird ausgewiesen, damit Sie ihn beobachten und Ihre eigene Policy abstimmen können – behandeln Sie ihn als Eingang in Ihre Risikoentscheidung, nicht als eigenständigen Grund zu blockieren.

Rein mobile Prüfungen sind im Web nicht wirksam. Die Erkennung von Root, Jailbreak, geklonten/dualen Apps und Frida hängt von nativen Signalen ab, die ein Browser nicht erfassen kann. TRACIO liefert ausschließlich Browser-SDKs aus; verlassen Sie sich daher auf die Verdicts zu Automatisierung, Headless, KI-Agenten, Anti-Detect, Emulator und Verhalten, die im Web vollständig aktiv sind.

Verifizierte Crawler

Bekannte gute Bots werden an ihrem User-Agent erkannt und anschließend gegen die verbindende IP verifiziert – ein Reverse-DNS-Lookup auf die IP, eine Prüfung, ob der resultierende Hostname zur Domain des Betreibers gehört, und ein Forward-Lookup, der bestätigt, dass er wieder auf dieselbe IP auflöst. Das ist genau das Verifizierungsverfahren, das die Crawler-Betreiber selbst veröffentlichen.

Ein verifizierter Crawler ergibt human. Eine Anfrage, die vorgibt, Googlebot zu sein, während ihre IP nachweislich jemand anderem gehört, wird als Bot eingestuft – ein lediglich fehlender oder in einen Timeout gelaufener Lookup gilt nicht als Beleg für eine Fälschung.

Verhaltensanalyse

Interaktionsdynamik – Zeigerbewegung, Tastaturrhythmus, Scrollen – fließt als Beleg dafür in das Verdict ein, ob ein Mensch anwesend ist, nicht dafür, welcher Mensch es ist. Ab Business wird der Aggregatwert im behavior-Block des Webhooks geliefert:

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

score läuft von 0..100 (höher = menschlicher), verdict ist human, uncertain oder bot, und confidence (0..1) gibt an, auf wie viel Evidenz das Verdict beruht – ein kurzer Besuch mit zwei Zeigerbewegungen erhält hier einen niedrigen Wert, selbst wenn das Verdict eindeutig wirkt.

Der Block ist nur dann vorhanden, wenn das Verhaltens-Scoring für diesen Besuch tatsächlich gelaufen ist. Ein fehlender Block bedeutet „keine Daten“, niemals „nichts Verdächtiges“ – lesen Sie sein Fehlen nicht als sauberes Signal.

Integrationsbeispiele

Bots beim Login blockieren (Client)

Das Client-SDK stellt einen praktischen Boolean bereit, result.bot.detected, sowie ein confidence auf einer Skala von 0..100:

const result = await tracio.getResult()

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

await login(credentials)

Serverseitige Bot-Prüfung

Reagieren Sie auf Ihrem Server auf die Zustellung des Webhooks. Das Bot-Verdict liegt im Objekt bot – bot.result und 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")
})

Null- und Leerwerte werden aus dem Payload weggelassen; lesen Sie bot.type daher defensiv, statt es in Ihrem Schema zu verlangen.

Umgang mit Falsch-Positiven

Die Bot-Erkennung von TRACIO ist auf nahezu null Falsch-Positive ausgelegt, doch Grenzfälle gibt es:

Wenn Sie Falsch-Positive sehen, prüfen Sie bot.type (und ab Business reasons), um zu verstehen, welche Klasse von Beobachtung ausgelöst hat, und passen Sie dann Ihre Policy an. Siehe Fehlerbehebung für die häufigen Ursachen.