Lo que Patchright oculta y lo que no: detectar navegadores automatizados sin castigar a las personas

Por qué lo miramos

OpenWAF Verify es el reto que nuestro borde muestra en lugar de un CAPTCHA: una prueba de trabajo que el navegador resuelve en segundo plano y, cuando el riesgo es mayor, un paso de un clic, «Verifica que eres humano». No puede demostrar que alguien es humano; nada en la web puede. Su trabajo es que automatizar salga más lento y más caro que navegar.

El 28 de octubre apuntamos Patchright al widget gestionado de Verify en nuestra propia página de demostración. En los tres modos que probamos pasó sin que se le pidiera el clic. Playwright a secas no: un Chromium en modo automatización lo declara con la bandera estándar navigator.webdriver, y el widget lo subió al clic. Cerrar ese hueco es justo para lo que existe Patchright, así que fuimos a ver qué cambia exactamente.

Solo analizamos código público: el driver de Patchright y sus paquetes de Python y Node tal como están publicados en GitHub, junto a Playwright 1.62.0. Todas las pruebas del laboratorio fueron contra una copia local de nuestro propio reto; no intervino ningún sitio ni servicio de terceros.

Qué cambia Patchright

Patchright es un proyecto de código abierto que aplica unos treinta parches al código del driver de Chromium de Playwright y lo distribuye como sustituto directo. Los cambios que importan aquí:

• El runtime de DevTools. Playwright, como casi todas las herramientas basadas en el Chrome DevTools Protocol, activa el dominio Runtime del protocolo, que tiene efectos secundarios que una página puede observar. Patchright no lo activa nunca, ni tampoco el dominio Console.
• Mundos aislados. Los scripts que ejecuta la automatización van por defecto a un mundo JavaScript aparte, así que no dejan nada en la página.
• Banderas de arranque. Quita las opciones que ponen Chromium en modo automatización, así que navigator.webdriver es falso y desaparece la barra «un software de prueba automatizado está controlando Chrome», junto con otras banderas típicas de las pruebas.

Patchright no falsea las API de JavaScript: no inventa propiedades de navigator, plugins ni tamaños de pantalla. Es una decisión sensata. En nuestro laboratorio, todas las herramientas que parcheaban JavaScript para parecer un navegador normal acababan contradiciéndose en algún sitio.

El laboratorio

Una página local reproducía el paso interactivo de Verify. Cinco herramientas se probaron contra ella en macOS con Google Chrome 156: Playwright; Patchright; Puppeteer con el plugin de sigilo de puppeteer-extra; zendriver, que maneja un Chrome real por el DevTools Protocol sin WebDriver, y Camoufox, un Firefox modificado en C++. Cada una se ejecutó sin interfaz y en ventana, en varias configuraciones, y pulsó la casilla de tres formas: su clic por defecto, el teclado y una trayectoria «humana» programada. En total, 110 ejecuciones automatizadas. Del lado humano, una persona pulsó la casilla 31 veces en el mismo Mac, en Brave y Safari, con trackpad y con ratón. Las observaciones en bruto no salieron de esa máquina.

La configuración recomendada es la que sugieren los mantenedores de Patchright: el Chrome instalado, una ventana real, un perfil persistente y sin viewport emulado. Tres ejecuciones por configuración dicen qué familias ven las comprobaciones, no tasas de detección, y quien tenga empeño afinará más que nosotros.

Qué sigue delatando la automatización

• Cómo se sintetiza la entrada. El navegador da por buena la entrada enviada por el DevTools Protocol (isTrusted vale true), así que una página no puede preguntar sin más si un clic fue real. Pero los métodos de entrada por defecto están escritos para que las pruebas sean fiables, y su movimiento, su posición y sus tiempos se distinguen de forma medible de una mano en un ratón, un trackpad o un teclado. También es la marca más barata de quitar.
• Entornos que no cuadran. Los modos sin interfaz y los viewports emulados describen un navegador que no corresponde a uno de escritorio en una ventana real. El User-Agent se puede cambiar; el resto del navegador sigue diciendo la verdad.
• Parches que se contradicen. Un navegador tiene más rincones de los que cubre cualquier conjunto de parches de sigilo, y los valores falseados acaban chocando con los reales.
• La red frente a lo que se declara. El borde compara el saludo TLS con el navegador que la petición dice ser, antes de que se ejecute JavaScript. Eso caza librerías HTTP disfrazadas de navegador, no a Patchright manejando el Chrome instalado, que usa la pila de red del propio Chrome.
• El comportamiento a lo largo de muchas peticiones. Una visita dice poco. El volumen, los fallos, la reutilización y los patrones de tiempo de los retos de una red dicen mucho más, sea cual sea el navegador.

La base humana

Cada comprobación se probó con personas antes de publicarla. La base es pequeña, pero bastó para descartar varias ideas que parecían sólidas contra las herramientas:

• Pulsaciones cortas. La automatización pulsa rápido, así que una duración mínima de la pulsación parecía obvia. Luego el «tocar para hacer clic» del trackpad dio pulsaciones de pocos milisegundos, tan cortas como las de cualquier script.
• Sin movimiento antes del clic. Los scripts suelen saltar directamente al objetivo. Las personas también: en 14 de las 31 pulsaciones el cursor ya estaba quieto donde apareció la casilla.
• Pulsar demasiado pronto. Un tiempo mínimo antes del clic marcaba a personas cuyo cursor ya estaba en su sitio. Lo quitamos.
• El hardware, no la persona. Una idea resultó medir el ratón y la pantalla del visitante, no al visitante.

Lo que quedó no dio ningún falso positivo en esas 31 pulsaciones: una muestra pequeña, de un solo sistema operativo y todavía sin base de teclado. Hay personas que pueden parecer raras a alguna comprobación: quien tenga abiertas las herramientas para desarrolladores, o use control por voz o acceso por conmutador, cuya entrada puede parecer sintética. Por eso las comprobaciones de navegador, por sí solas, como mucho piden un clic.

Qué sigue pasando

• Patchright en su configuración recomendada, con una entrada que quien lo maneja se haya molestado en humanizar.
• Camoufox, en la mayoría de nuestras ejecuciones.
• Cualquier navegador real cuya entrada venga del sistema operativo y no del protocolo de depuración del navegador.
• Personas a las que se paga por resolver retos.

Las comprobaciones de navegador cazan los valores por defecto. Importan, porque casi toda la automatización a escala funciona con ellos, pero una comprobación que cae con un cambio de una línea en un script es fricción, no una barrera. Las hicimos sabiéndolo.

Por qué el servidor y el coste importan más

Un navegador se puede dejar limpio, así que lo que aguanta es lo que un script no puede cambiar desde dentro de la página:

• La prueba de trabajo. No para a un visitante, pero cambia el precio de un millón.
• Un paso interactivo. Obliga a la automatización a producir entrada real y le cuesta tiempo en cada reto.
• Reputación y red. Las listas de amenazas, el historial que el propio borde tiene de una dirección, si la red es de un proveedor de alojamiento y cómo le han ido sus últimos retos.
• Coherencia de la petición. Cabeceras, client hints y saludo TLS frente al navegador que el cliente dice ser.

Todo esto alimenta la puntuación de riesgo de Verify: una puntuación por reto que, en modo aplicar (enforce), hace más difícil la prueba de trabajo, pide un clic o bloquea. Las comprobaciones de navegador son una entrada más entre muchas y solo pesan lo bastante para bloquear cuando el servidor está de acuerdo. Para un sitio bajo un ataque sostenido, el modo bajo ataque pasa a todos los visitantes por el reto y el clic.

Lo que no recogemos

• Ni huellas de canvas, WebGL, audio o fuentes, ni listas de plugins, ni client hints de alta entropía.
• Cada comprobación contesta sí o no dentro de la página. Solo salen esas respuestas, nunca los valores de los que salen, y nada en ellas identifica a un visitante.
• Solo de primera parte: nuestro borde sirve el reto y sus scripts desde el propio dominio del sitio protegido, sin scripts ni llamadas a terceros.
• Los contadores por red viven unos minutos en la memoria de cada nodo de borde, con un hash del prefijo de red como clave. La analítica recibe niveles, tramos de puntuación y qué señales saltaron, por sitio y minuto, sin direcciones IP.

Primero, modo registro

La puntuación de riesgo, comprobaciones de navegador incluidas, sale en modo registro (log), que es su valor por defecto: cada reto se puntúa y se cuenta, y no se aplica nada. Todavía no aplicamos estas señales.

El motivo es la base humana: un sistema operativo, dos navegadores y nadie con teclado. Antes de que una comprobación pese más o de activar la aplicación, queremos ver con qué frecuencia salta cada una con tráfico real en Windows, Linux, Android e iOS, con ratón, pantalla táctil y teclado. Los dueños de los sitios tienen la misma vista: la analítica de Verify enseña lo que habría hecho cada nivel, así que el paso a aplicar se da con sus propias cifras. Lo siguiente por nuestra parte es una huella TLS más completa en el borde, para los clientes cuyo saludo no corresponde a la versión de navegador que declaran.

Gracias a los proyectos Patchright y Playwright, cuyo código y documentación son públicos y claros. Esto trata de lo que puede ver un borde, no es un juicio sobre ninguno de los dos. Si crees que nos hemos equivocado en algo, escribe a security@openwaf.dev.

Preguntas frecuentes

Fuentes

• Patchright: source code and README Patchright project
• Playwright documentation Microsoft
• Chrome DevTools Protocol: Runtime domain Chrome DevTools
• WebDriver: the navigator.webdriver interface W3C
• Event: isTrusted property MDN Web Docs
• puppeteer-extra-plugin-stealth puppeteer-extra project
• zendriver zendriver project
• Camoufox Camoufox project
• Verify risk scoring OpenWAF, 28 oct 2026