Rilevamento dei bot

Il rilevamento dei bot di TRACIO identifica browser automatizzati, strumenti headless e attacchi tramite script con un'architettura a due livelli: raccolta lato client nell'agente del browser e analisi lato server. Copre i principali framework di automazione, i browser headless, gli agenti di navigazione IA e i browser anti-rilevamento con falsi positivi quasi nulli, inserendo automaticamente nella allowlist i crawler legittimi dei motori di ricerca.

Cosa rileva TRACIO

• Framework di automazione — Selenium, Puppeteer, Playwright, Cypress, PhantomJS, NightmareJS e strumenti analoghi.
• Browser headless — Chrome headless e runtime correlati.
• Agenti di navigazione IA — Browser-Use, Claude Computer Use, Fellou, Genspark, Skyvern e runtime di agenti analoghi.
• Browser anti-rilevamento — build di browser il cui scopo è falsificare o ruotare il fingerprint.
• Crawler verificati — Googlebot, Bingbot, Applebot, GPTBot, Yandex, DuckDuckGo e altri, verificati in modo che uno user-agent falsificato non passi.

Come viene prodotto il verdetto

L'agente del browser esegue un'ampia serie di controlli e ne riporta gli esiti. Sul server gli esiti vengono ponderati in un punteggio di bot, e il punteggio viene mappato su un verdetto. Un piccolo numero di indicatori inequivocabili è decisivo di per sé e impone un verdetto bot a prescindere dal resto.

Quali controlli vengono eseguiti, come vengono ponderati e dove si collocano le soglie non sono pubblicati, su nessun piano. Documentarli direbbe agli operatori di bot esattamente cosa cambiare per superare la protezione. Ciò che riceve, al loro posto, è il verdetto, un'etichetta di tipo di bot e — da Business in su — codici motivo che nominano la classe di osservazione alla base della decisione.

Formato del risultato

Ogni identificazione porta con sé un verdetto di bot. Le arriva come bot.result nel payload del webhook e come result.bot nell'SDK client.

Valori del verdetto

Questo viene mappato sul campo aziendale decision.action (real, fake o suspicious) usato in tutta la dashboard e nel payload del webhook.

Il verdetto è accompagnato da bot.score. Nella versione 2 del payload del webhook è un decimale 0..100, lo stesso numero che la dashboard mostra per quella visita. (Nello schema congelato della versione 1 è una frazione 0..1; veda Webhooks.)

Tipi di bot

bot.type è presente quando il risultato è bot. È il nome di un bot o di un runtime riconosciuto, oppure una famiglia, quando nominare il controllo specifico rivelerebbe il funzionamento interno del rilevatore:

L'elenco è chiuso per scelta progettuale: un controllo aggiunto domani al rilevatore comparirà come other anziché far trapelare il proprio nome interno. Tratti bot.type come un'etichetta su cui diramare le decisioni, non come un enum esaustivo da validare: nel tempo vengono aggiunti nuovi runtime con nome proprio.

Codici motivo (da Business in su)

Sui piani Business ed Enterprise il payload del webhook porta un array reasons — al massimo otto voci, ordinate per importanza. Un codice nomina la classe di osservazione, mai il controllo che vi sta dietro:

severity vale high, medium o low ed è la quota di verdetto di cui questa classe rende conto in questa visita, non una proprietà fissa del codice. Lo stesso codice può arrivare come high in una visita e come low in un'altra: non lo metta quindi in cache come una costante.

privacy_hardening merita particolare attenzione: scatta tanto per normali visitatori attenti alla privacy quanto per tentativi di elusione. Lo valuti insieme al resto anziché agire soltanto su di esso.

virtual_environment deriva dal rilevamento degli emulatori. Sul web non esiste un verdetto a sé stante «in esecuzione sotto un hypervisor»: gli indizi che un browser può vedere — un renderer software generico, un numero di core insolitamente basso — compaiono altrettanto spesso su macchine ordinarie prive di driver GPU e all'interno di sessioni di desktop remoto, perciò non li trasformiamo in un verdetto che lei dovrebbe poi mettere in dubbio.

Disponibilità per piano

Il punteggio anti-rilevamento è ancora in fase di calibrazione. bot.antidetectScore viene riportato perché lei possa osservarlo e regolare la propria policy: lo tratti come un input della sua decisione di rischio, non come un motivo autonomo di blocco.

I controlli specifici del mobile non sono efficaci sul web. Il rilevamento di root, jailbreak, app clonate/duplicate e Frida dipende da segnali nativi che un browser non può raccogliere. TRACIO distribuisce solo SDK per browser: faccia quindi affidamento sui verdetti di automazione, headless, agenti IA, anti-rilevamento, emulatori e comportamentali, che sono pienamente attivi sul web.

Crawler verificati

I bot buoni noti vengono riconosciuti dal loro user-agent e poi verificati rispetto all'IP che si connette: una risoluzione DNS inversa sull'IP, un controllo che l'hostname ottenuto appartenga al dominio dell'operatore e una risoluzione diretta che conferma che punta di nuovo allo stesso IP. È la procedura di verifica che pubblicano gli stessi operatori dei crawler.

Un crawler verificato risolve a human. Una richiesta che dichiara di essere Googlebot mentre il suo IP appartiene dimostrabilmente a qualcun altro viene classificata come bot; una risoluzione semplicemente assente o andata in timeout non è considerata prova di falsificazione.

Analisi comportamentale

La dinamica di interazione — movimento del puntatore, cadenza della tastiera, scorrimento — alimenta il verdetto come prova del fatto che ci sia una persona, non di quale persona sia. Da Business in su l'aggregato viene consegnato nel blocco behavior del webhook:

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

score va da 0..100 (più alto = più umano), verdict è human, uncertain o bot, e confidence (0..1) indica su quante prove poggia il verdetto: una visita breve con due movimenti del puntatore ottiene qui un punteggio basso anche quando il verdetto sembra decisivo.

Il blocco è presente solo quando il punteggio comportamentale è stato effettivamente calcolato per quella visita. Un blocco assente significa «nessun dato», mai «niente di sospetto»: non interpreti la sua assenza come un segnale pulito.

Esempi di integrazione

Bloccare i bot al login (client)

L'SDK client espone un booleano di comodità, result.bot.detected, più un confidence su scala 0..100:

const result = await tracio.getResult()

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

await login(credentials)

Verifica dei bot lato server

Sul suo server, agisca sulla consegna del webhook. Il verdetto di bot risiede nell'oggetto bot — bot.result e 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")
})

I valori zero e vuoti vengono omessi dal payload: legga quindi bot.type in modo difensivo anziché renderlo obbligatorio nel suo schema.

Gestione dei falsi positivi

Il rilevamento dei bot di TRACIO è progettato per falsi positivi quasi nulli, ma i casi limite esistono:

Se nota falsi positivi, esamini bot.type (e reasons da Business in su) per capire quale classe di osservazione è scattata, poi adatti la sua policy. Veda Risoluzione dei problemi per le cause più comuni.