Cómo detectar automatización de navegadores más allá de user agents

Qué es la automatización de navegadores

La automatización de navegadores es la práctica de controlar un navegador real (o casi real) desde un script en lugar de desde una persona. El script abre páginas, pulsa elementos, rellena formularios y lee el DOM a través de un canal de control, normalmente el Chrome DevTools Protocol o un equivalente específico del fabricante. El navegador renderiza. El script decide. El sitio al otro lado debería distinguir las dos cosas y casi nunca puede.

La mayoría de los sistemas de detección de bots empiezan comprobando el user-agent, una etiqueta autodeclarada que cada cliente HTTP envía con cada petición. Cambiar un user-agent cuesta una línea de código. La especificación W3C WebDriver obliga a poner `navigator.webdriver` en `true` cuando el navegador está automatizado. Se suponía una señal fiable. No lo era. Como documentó la investigación de amenazas de DataDome, cuando los bots WebDriver se dieron cuenta de que se les detectaba por `navigator.webdriver`, simplemente lo devolvieron a false.

Por qué la automatización de navegadores importa ahora

La escala de lo que pasa cuesta de exagerar. Imperva midió el 51 % del tráfico web de 2024 como automatizado, la primera vez en una década que los bots superan a los visitantes humanos (Imperva, 2025). Del tráfico malicioso, el 41 % se clasifica ya como avanzado, construido específicamente para imitar comportamiento humano (Imperva, 2025). Estos bots falsifican todo lo que expone la superficie del navegador, no solo el user-agent.

Si las señales que un cliente declara sobre sí mismo no son fiables, la detección tiene que moverse a señales que el cliente no puede controlar. Ese cambio no es opcional a este volumen. Solo el 2,8 % de los sitios web están completamente protegidos frente a bots, frente al 8,4 % del año anterior (DataDome, 2025). El 85 % de las empresas golpeadas por ataques de account takeover ya tenían detección de bots en producción (Kasada, 2025).

Tipos de automatización (Puppeteer, Playwright, Selenium, basada en CDP)

Cuatro familias de herramientas de automatización concentran la mayoría del tráfico de scraping y agéntico en la web de hoy.

**Selenium.** El framework más antiguo y el más enseñado. Controla navegadores vía ChromeDriver o GeckoDriver, que a su vez hablan con el navegador por protocolos de automatización específicos del fabricante. Deja los artefactos más reconocibles: la variable `$cdc_asdjflasutopfhvcZLmcfl_` que ChromeDriver inyecta en cada página se caza con una regex de una línea.

**Puppeteer.** La biblioteca Node.js de Google para controlar Chromium vía Chrome DevTools Protocol. Se usa con plugins stealth (puppeteer-extra-stealth) que sobrescriben artefactos obvios al cargar la página. A principios de 2025, puppeteer-extra-stealth dejó de saltarse Cloudflare de forma fiable y los mantenedores pausaron la actividad.

**Playwright.** El framework multi-navegador de Microsoft, también basado en CDP para Chromium y en protocolos específicos del fabricante para Firefox y WebKit. Forks como Patchright parchean el uso de CDP de Playwright a nivel de C++ para evitar emitir los eventos de efecto secundario que usa la detección.

**Frameworks basados en CDP y post-CDP.** nodriver, zendriver (un fork asíncrono) y rebrowser-patches forman la generación más reciente. O minimizan el uso de CDP (evitando dominios de alto riesgo como `Runtime` y `Console`) o eliminan CDP por completo, controlando el navegador con APIs del sistema operativo, de forma que no hay sesión CDP que un detector pueda observar.

Cómo funciona la automatización de navegadores

Puppeteer, Playwright y Selenium hablan con Chromium por el mismo canal: el Chrome DevTools Protocol (CDP), una interfaz WebSocket que el navegador expone para depuración. Alrededor del 95 % de las acciones automatizadas terminan pasando por `Page.evaluate`, la forma que tiene CDP de ejecutar JavaScript dentro de la página (Rebrowser, 2024).

`Page.evaluate` requiere activar el dominio `Runtime` de CDP. Activarlo emite eventos que la página puede observar. Durante años, el patrón estándar de detección consistía en colocar un objeto Error con un getter personalizado en `.stack`, llamar a `console.debug()` sobre él y ver si el getter se disparaba. Si lo hacía, el dominio Runtime estaba serializando el objeto por el WebSocket.

En mayo de 2025, dos commits de V8 mataron el truco. Uno titulado Avoid error side effects in DevTools aterrizó el 7 de mayo, Apply getter guard throughout error preview lo hizo el 9 de mayo. Juntos evitan que el navegador ejecute getters definidos por el usuario durante la previsualización de errores (Castle, 2025). El check con `console.debug` pasó de fiable a inútil, y la mayoría de proveedores tardaron meses en darse cuenta.

Cómo identificar automatización en tu sitio

La detección tiene que pasar por debajo de la capa que el script controla. Cuatro clases de señal sobreviven a la automatización moderna.

**Fingerprinting TLS y de protocolo.** Antes de que un navegador envíe la primera petición HTTP, realiza un handshake TLS. El ClientHello contiene cipher suites, extensiones, versiones de protocolo y preferencias ALPN. Estos valores los fija el stack de red, no el JavaScript que el script pueda ejecutar después. JA4, desarrollado por FoxIO y adoptado por Cloudflare, resiste la aleatorización de extensiones que rompió a JA3. Cloudflare rastrea más de 15 millones de fingerprints JA4 únicos a partir de más de 500 millones de user-agents (Cloudflare, 2025).

**Frame SETTINGS de HTTP/2.** Cuando se abre una conexión, el cliente envía un frame SETTINGS con parámetros que varían según la implementación. Chrome envía un WINDOW_UPDATE de ~15 MB; Firefox ~12,5 MB. La mayoría de las bibliotecas HTTP envían cero o lo omiten. Una diferencia de 100 veces, visible antes de que se intercambie un solo byte de contenido. El orden de los pseudo-headers (`:method`, `:authority`, `:scheme`, `:path`) está fijado por navegador y no coincide con lo que envían las bibliotecas por defecto.

JavaScript y artefactos CDP

**Señales del entorno JavaScript.** La detección moderna comprueba cómo están definidas las propiedades, no sus valores. Cuando un plugin stealth sobrescribe `navigator.webdriver` para devolver `false`, cambia el descriptor de propiedad. El getter ya no es código nativo, es un proxy. Llamar a `toString()` sobre él devuelve algo sutilmente distinto a lo que devolvería un navegador real. Las salidas de Canvas y WebGL dependen de la GPU. Las herramientas que corren en entornos cloud producen salidas que casan con el hardware del proveedor, no con el hardware que declara el user-agent.

**Artefactos CDP.** Cuando un cliente CDP se conecta y activa el dominio `Runtime`, dispara la serialización de objetos por la conexión WebSocket. El JavaScript de la página puede observar esos comportamientos de serialización, que no ocurren en un navegador sin cliente CDP enganchado. Solo en octubre de 2025, Castle detectó alrededor de 205.000 eventos de Puppeteer stealth, pero diez veces más tráfico de Selenium vanilla (Castle, 2025).

Cómo responder al tráfico automatizado

Cada técnica de detección tiene una contramedida. El fingerprinting TLS generó curl-impersonate y tls-client. La detección CDP generó nodriver y Rebrowser. El fingerprinting JavaScript generó navegadores anti-detect como Multilogin y GoLogin, que mantienen perfiles de navegador separados con fingerprints propios. Una respuesta apoyada en una sola señal envejece deprisa porque el ecosistema de evasión ataca exactamente esa señal.

Lo que sobrevive a la carrera armamentística es la verificación cruzada entre capas combinada con la confirmación conductual. Una petición cuyo fingerprint TLS, settings HTTP/2 y entorno JavaScript coinciden todos con Chrome y cuyas señales conductuales parecen humanas, es probablemente un navegador real. Una petición en la que cualquier capa contradice a las otras, probablemente no. Cuantas más capas se comprueben a la vez, más cara es la evasión.

El análisis conductual recoge lo que el fingerprinting no puede ver. Los bots mueven el ratón en líneas rectas a velocidad constante, con direcciones bloqueadas en ángulos fijos. Los cursores humanos divagan, siguen trayectorias curvas con velocidad variable y pausan de forma irregular. En pruebas controladas, el análisis del timing de tecleo por sí solo clasificó bots con un 99,98 % de precisión (IFIP, 2024). Estas señales funcionan mejor en páginas interactivas como formularios de login, campos de búsqueda y flujos de checkout.

Una vez emitido el veredicto, hay tres respuestas disponibles por petición. Bloquear el tráfico automatizado en el edge para que origen no lo pague. Plantar una challenge no interactiva a sesiones de caso límite para obligar al cliente a ejecutar código. Verificar y permitir a agentes socios e indexadores de búsqueda que se quieren dejar pasar, con un sello firmado y seguimiento de volumen por operador.

Conclusiones clave

- La automatización de navegadores concentra la mayor parte del tráfico de bots que llega a sitios modernos. Los bots maliciosos representaron el 37 % del tráfico de internet en 2024, frente al 32 % del año anterior (Imperva, 2025). - Filtrar por user-agent, listas de reputación de IP y rate limiting por sí solos cazan a los bots más perezosos y se les escapa el resto. El flag `navigator.webdriver` del W3C se devuelve a `false` con trivialidad. - La detección eficaz cruza capas: handshake TLS, SETTINGS HTTP/2, entorno JavaScript, artefactos CDP y comportamiento, cotejadas entre sí en tiempo real. Una contradicción entre dos capas cualesquiera es la señal. - La respuesta es una decisión por petición: bloquear, challengear o verificar. robots.txt se ocupa de los crawlers bien educados. Centinel comprueba cada petición en todas estas capas y decide en menos de 2 ms, antes de que el bot llegue a origen.