# Comprobaciones de automatización en el navegador para Verify

> La página del reto y el widget Verify responden ahora a unas pocas comprobaciones de sí o no sobre frameworks de automatización, codificadas por reto, como pistas para la puntuación de riesgo.

Con la [puntuación de riesgo](https://developers.openwaf.dev/es/waf/verify-risk/) activa, el [reto del navegador](https://developers.openwaf.dev/es/waf/browser-challenge/), el [modo bajo ataque](https://developers.openwaf.dev/es/waf/under-attack/) y el [widget Verify](https://developers.openwaf.dev/es/waf/verify-widget/) ejecutan además unas pocas **comprobaciones en el navegador** y envían con la solución un sí o un no por comprobación: un cliente del protocolo DevTools que activó el runtime de JavaScript de la página, funciones propias sustituidas por un script, una ventana headless o emulada, un Web Worker que describe otro navegador que la página y cómo se activó la casilla de verificación. La respuesta se codifica distinta en cada reto, así que una grabada no vale para otro; una respuesta ausente o mal formada cuenta como `client_tampered`. Llenan las señales que hasta ahora estaban reservadas: `cdp_runtime`, `native_patched`, `headless_env`, `worker_mismatch`, `click_dynamics` y `client_tampered`.

Son pistas: sin una señal del servidor su total se queda en el umbral interactivo, así que por sí solas pueden pedir un clic, nunca bloquear, y en modo log (el de por defecto) solo aparecen en la analítica. Lo que comparan se queda en la página; sigue sin haber huellas de canvas, WebGL, audio ni fuentes. Cazan el comportamiento por defecto de los frameworks de automatización habituales, no uno ajustado para imitar a una persona ni la entrada inyectada por el sistema operativo. Ver las [señales](https://developers.openwaf.dev/es/waf/verify-risk/#signals) y los [datos tratados](https://developers.openwaf.dev/es/waf/verify-risk/#data).