Detectar navegadores headless: Playwright, Puppeteer y más allá

Los navegadores headless son el arma preferida para el web scraping sofisticado, el credential stuffing y las operaciones de fraude. A diferencia de los clientes HTTP simples, los navegadores headless ejecutan JavaScript, renderizan páginas y admiten APIs web modernas, lo que los hace mucho más difíciles de detectar. Nuestro motor de Bot Detection usa múltiples métodos de detección independientes para identificar más de 15 frameworks de automatización con falsos positivos casi nulos.

La evolución de la automatización de navegadores

La automatización de navegadores ha recorrido un largo camino desde los simples scripts de curl. Herramientas modernas como Playwright, Puppeteer y Selenium WebDriver controlan motores de navegador reales —Chromium, Firefox o WebKit— en modo headless. Ejecutan JavaScript, procesan CSS, renderizan elementos canvas y gestionan consultas de WebGL igual que los navegadores con interfaz. Esto los hace invisibles para los métodos de detección que simplemente comprueban la capacidad de ejecutar JavaScript.

La última generación de herramientas ha ido más allá. El modo sigilo de Playwright parchea muchas de las señales en las que se apoya la detección de bots tradicional. Puppeteer-extra-plugin-stealth modifica las propiedades del navigator, sobrescribe las cadenas de fabricante de WebGL y falsea eventos de interacción del usuario. Estas medidas anti-detección han creado una carrera armamentística entre los operadores de bots y los sistemas de detección.

Método de detección 1: análisis de la bandera WebDriver

La propiedad navigator.webdriver se establece en true cuando un navegador está controlado por automatización. La detección temprana era tan sencilla como comprobar esta propiedad. Pero las herramientas de sigilo modernas la eliminan o la sobrescriben. Nuestra detección va más allá: comprobamos no solo el valor de la propiedad, sino su descriptor de propiedad, su presencia en la cadena de prototipos y si se ha intentado redefinirla. También comprobamos propiedades relacionadas, como anomalías en la longitud de navigator.plugins que acompañan a las sobrescrituras de WebDriver.

Método de detección 2: artefactos del Chrome DevTools Protocol

Playwright y Puppeteer controlan los navegadores a través del Chrome DevTools Protocol (CDP). Incluso cuando el modo sigilo está activo, CDP deja artefactos en el runtime: variables globales específicas, funciones getter modificadas y descriptores de propiedad alterados en los objetos Window y Navigator. Sondeamos estos artefactos con técnicas resistentes a las sobrescrituras simples.

Método de detección 3: fingerprinting de navegadores headless

Chrome headless tiene un conjunto de capacidades distinto del de Chrome con interfaz. Carece de ciertos plugins de navegador, presenta características de renderizado diferentes para algunas propiedades CSS y reporta valores distintos para algunos resultados de MediaQuery. Mantenemos una base de datos de características conocidas de navegadores headless y comparamos las huellas entrantes contra ella.

Los indicadores clave de headless incluyen: la ausencia de chrome.runtime (presente en Chrome con interfaz pero ausente en headless), un array navigator.plugins de longitud cero, patrones específicos de user agent que se han asociado al modo headless en versiones anteriores y diferencias en cómo Chrome headless gestiona los contextos de seguridad de los iframe.

Método de detección 4: análisis de la longitud de eval

Los distintos motores de JavaScript tienen implementaciones diferentes de las funciones integradas, y esas implementaciones tienen representaciones en cadena distintas. Al comprobar la longitud de Function.prototype.toString.call(eval) y compararla con los valores conocidos de cada motor de navegador, podemos detectar la suplantación del entorno; por ejemplo, una instancia de Chrome headless que finge ser Firefox.

Método de detección 5: validación cruzada de TLS

Como se explica en nuestro artículo sobre fingerprinting de TLS, el mensaje TLS Client Hello revela el navegador o la librería HTTP que realmente establece la conexión. Cuando un script de Playwright controla Chrome, la huella de TLS coincide con Chrome: eso es lo esperado. Pero cuando un bot personalizado usa una librería requests de Python o el net/http de Go, la huella de TLS revela el engaño sin importar qué cadena de user agent se envíe.

Método de detección 6: análisis de temporización y comportamiento

Los usuarios reales muestran una variación natural en la temporización de sus interacciones. Mueven el ratón en curvas, no en líneas rectas. Hacen una pausa antes de hacer clic. Se desplazan a velocidades variables. Las herramientas automatizadas, incluso las que simulan comportamiento humano, producen patrones estadísticamente distinguibles: una temporización demasiado constante, trayectorias de ratón perfectamente lineales y velocidades de scroll poco naturales.

Recopilamos señales de comportamiento mínimas durante el propio proceso de fingerprinting: la temporización de las llamadas a las APIs, el orden de recopilación de señales y la capacidad de respuesta de ciertas APIs del navegador. Estas microseñales de comportamiento son difíciles de falsear para las herramientas de automatización porque dependen del entorno de ejecución real, no de propiedades sobrescribibles.

Método de detección 7: inconsistencia de permisos y APIs

Los navegadores reales tienen estados de permisos y disponibilidad de APIs consistentes. Un navegador que afirma admitir notificaciones pero no tiene un constructor Notification, o que reporta una resolución de pantalla específica pero devuelve valores diferentes desde window.screen y las media queries de CSS, muestra inconsistencias que indican manipulación o emulación.

Comprobamos docenas de estos puntos de validación cruzada, en busca de contradicciones que surgen cuando las herramientas de automatización sobrescriben selectivamente algunas señales sin mantener la consistencia entre todas las APIs relacionadas.

Método de detección 8: detección de máquinas virtuales y emulación

Muchas operaciones de bots se ejecutan dentro de máquinas virtuales o instancias de nube. Aunque esto por sí solo no es prueba de automatización, es una señal fuerte cuando se combina con otros indicadores. Detectamos máquinas virtuales a través de cadenas de renderizador de WebGL que contienen palabras clave asociadas a máquinas virtuales (como «llvmpipe» o «SwiftShader»), características de hardware inconsistentes con dispositivos de consumo (exactamente 2 núcleos de CPU y 2GB de memoria, valores por defecto habituales de las máquinas virtuales) y rangos de IP conocidos de proveedores de nube.

La ventaja multimétodo

Cada método de detección tiene, de forma individual, sus limitaciones: un operador de bots sofisticado podría evadir cualquier método aislado. Pero evadir todos los métodos a la vez, manteniendo la consistencia en la validación cruzada entre todos ellos, resulta prohibitivamente caro. El coste de desarrollar y mantener un bot que supere todas las comprobaciones supera el valor económico de la mayoría de las operaciones de bots.

Falsos positivos casi nulos

Nuestra detección opera con un modelo de lista blanca para los bots de motores de búsqueda (Googlebot, Bingbot, etc.) verificados mediante reverse DNS, y un modelo multiseñal para el resto del tráfico. Exigimos múltiples señales corroborantes antes de clasificar el tráfico como automatizado. Este enfoque conservador garantiza una tasa de falsos positivos por debajo del 0,1%, verificada en miles de millones de eventos de producción.