Detección de bots

La detección de bots de TRACIO identifica navegadores automatizados, herramientas headless y ataques con scripts mediante una arquitectura de dos capas: recopilación en el cliente dentro del agente de navegador y análisis en el servidor. Cubre los frameworks de automatización más habituales, los navegadores headless, los agentes de navegación con IA y los navegadores anti-detección con falsos positivos casi nulos, a la vez que incluye automáticamente en la allowlist a los rastreadores legítimos de motores de búsqueda.

Qué detecta TRACIO

• Frameworks de automatización — Selenium, Puppeteer, Playwright, Cypress, PhantomJS, NightmareJS y herramientas similares.
• Navegadores headless — Chrome headless y entornos de ejecución relacionados.
• Agentes de navegación con IA — Browser-Use, Claude Computer Use, Fellou, Genspark, Skyvern y entornos de agente similares.
• Navegadores anti-detección — compilaciones de navegador cuyo propósito es falsificar o rotar la huella digital.
• Rastreadores verificados — Googlebot, Bingbot, Applebot, GPTBot, Yandex, DuckDuckGo y otros, verificados de modo que un user-agent falsificado no pase.

Cómo se obtiene el veredicto

El agente de navegador ejecuta un amplio conjunto de comprobaciones y comunica sus resultados. En el servidor, esos resultados se ponderan en una puntuación de bot, y la puntuación se traduce en un veredicto. Un pequeño número de indicadores inequívocos son decisivos por sí solos y fuerzan un veredicto bot con independencia del resto.

Qué comprobaciones se ejecutan, cómo se ponderan y dónde se sitúan los umbrales no se publican, en ningún plan. Documentarlo indicaría a los operadores de bots exactamente qué cambiar para sortear la protección. Lo que usted recibe, en cambio, es el veredicto, una etiqueta de tipo de bot y —en Business y superiores— códigos de motivo que nombran la clase de observación que hay detrás de la decisión.

Formato del resultado

Cada identificación lleva un veredicto de bot. Le llega como bot.result en el payload del webhook y como result.bot en el SDK de cliente.

Valores del veredicto

Esto se corresponde con el campo de negocio decision.action (real, fake o suspicious) que se utiliza en todo el panel y en el payload del webhook.

El veredicto va acompañado de bot.score. En la versión 2 del payload del webhook es un decimal 0..100, el mismo número que el panel muestra para esa visita. (En el esquema congelado de la versión 1 es una fracción 0..1; consulte Webhooks.)

Tipos de bot

bot.type está presente cuando el resultado es bot. Es o bien el nombre de un bot o de un entorno de ejecución reconocido, o bien una familia, cuando nombrar la comprobación concreta revelaría el funcionamiento interno del detector:

La lista es cerrada por diseño: una comprobación que se añada mañana al detector aparecerá como other en lugar de filtrar su nombre interno. Trate bot.type como una etiqueta sobre la que ramificar, no como un enum exhaustivo contra el que validar: con el tiempo se añaden nuevos entornos de ejecución con nombre propio.

Códigos de motivo (Business y superiores)

En los planes Business y Enterprise, el payload del webhook incluye un array reasons: ocho entradas como máximo, ordenadas por importancia. Un código nombra la clase de observación, nunca la comprobación que hay detrás:

severity es high, medium o low, y representa la parte del veredicto que corresponde a esa clase en esa visita, no una propiedad fija del código. El mismo código puede llegar como high en una visita y como low en otra, así que no lo almacene en caché como una constante.

privacy_hardening merece especial cuidado: se activa tanto con visitantes normales preocupados por su privacidad como con intentos de evasión. Sopéselo junto con el resto en lugar de actuar únicamente en función de él.

virtual_environment procede de la detección de emuladores. En la web no existe un veredicto aparte de «se ejecuta bajo un hipervisor»: las pistas que un navegador puede ver —un renderizador por software genérico, un número de núcleos inusualmente bajo— aparecen con la misma frecuencia en equipos corrientes sin controlador de GPU y dentro de sesiones de escritorio remoto, así que no las convertimos en un veredicto que usted tuviera que poner en duda.

Disponibilidad por plan

La puntuación anti-detección todavía se está calibrando. bot.antidetectScore se comunica para que pueda observarlo y ajustar su propia política: trátelo como una entrada más de su decisión de riesgo, no como un motivo autónomo para bloquear.

Las comprobaciones exclusivas de móvil no son efectivas en la web. La detección de root, jailbreak, apps clonadas o duales y Frida depende de señales nativas que un navegador no puede recopilar. TRACIO publica únicamente SDK para navegador, así que apóyese en los veredictos de automatización, headless, agentes de IA, anti-detección, emuladores y comportamiento, que están plenamente activos en la web.

Rastreadores verificados

Los bots buenos conocidos se reconocen por su user-agent y después se verifican contra la IP que establece la conexión: una consulta DNS inversa sobre la IP, una comprobación de que el nombre de host resultante pertenece al dominio del operador y una consulta directa que confirma que resuelve de vuelta a la misma IP. Es el procedimiento de verificación que publican los propios operadores de los rastreadores.

Un rastreador verificado se resuelve a human. Una petición que dice ser Googlebot mientras su IP pertenece demostrablemente a otro se clasifica como bot; una consulta que simplemente falta o que ha agotado el tiempo de espera no se considera prueba de falsificación.

Análisis comportamental

La dinámica de interacción —movimiento del puntero, cadencia del teclado, desplazamiento— alimenta el veredicto como evidencia de si hay una persona presente, no de qué persona es. En Business y superiores, el agregado se entrega en el bloque behavior del webhook:

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

score va de 0..100 (cuanto más alto, más humano), verdict es human, uncertain o bot, y confidence (0..1) indica sobre cuánta evidencia se apoya el veredicto: una visita corta con dos movimientos de puntero puntúa bajo aquí aunque el veredicto parezca decisivo.

El bloque está presente solo cuando la puntuación de comportamiento se ha ejecutado realmente en esa visita. Un bloque ausente significa «sin datos», nunca «nada sospechoso»: no interprete su ausencia como una señal limpia.

Ejemplos de integración

Bloquear bots en el login (cliente)

El SDK de cliente expone un booleano de conveniencia, result.bot.detected, además de un confidence en una escala 0..100:

const result = await tracio.getResult()

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

await login(credentials)

Comprobación de bots en el servidor

En su servidor, actúe sobre la entrega del webhook. El veredicto de bot vive en el objeto bot: bot.result y 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")
})

Los valores cero y vacíos se omiten del payload, así que lea bot.type de forma defensiva en lugar de exigirlo en su esquema.

Gestión de falsos positivos

La detección de bots de TRACIO está diseñada para tener falsos positivos casi nulos, pero existen casos límite:

Si observa falsos positivos, revise bot.type (y reasons en Business y superiores) para entender qué clase de observación se activó y ajuste después su política. Consulte Resolución de problemas para conocer las causas más habituales.