Tipos de CAPTCHA: qué revela una casilla

Los tipos de CAPTCHA no pueden identificarse de forma fiable solo por una casilla, una cuadrícula de imágenes o un widget invisible. Esos elementos describen cómo aparece un control; no revelan todos sus mecanismos ni la regla de aceptación del sitio. Clasifica por separado la interacción, el control documentado, su ubicación y la decisión del servidor. BotBrowser ofrece controles del navegador basados en perfiles y configuración de proxy, pero no resuelve desafíos, no expone la puntuación privada de un proveedor ni garantiza que un sitio acepte una sesión.

Resumen

• Una casilla, una tarea con imágenes y la ausencia de un widget visible describen interacciones; ninguna explica por completo el sistema de verificación.
• La puntuación de riesgo, la prueba de trabajo y la atestación describen mecanismos o evidencias diferentes. Pueden coexistir con interacciones visibles o invisibles.
• Un token de respuesta generado en el navegador sigue necesitando la validación del lado del servidor que exige el proveedor. La autorización de la aplicación continúa siendo una decisión independiente.
• Identifica un producto desplegado mediante su integración documentada y la configuración del propietario, no mediante una captura que simplemente se parezca al desafío de otro proveedor.
• Registra como desconocidos los mecanismos desconocidos. En un trabajo automatizado autorizado, pausa las tareas dependientes cuando un desafío sustituya el resultado esperado de la aplicación.

Contenido

• Clasifica los tipos de CAPTCHA en cuatro ejes independientes
• Qué demuestran las tareas visibles
• Qué pueden medir los controles en segundo plano
• Sigue un token hasta la decisión del servidor
• Redacta una observación sin inventar una puntuación
• Elige la siguiente acción según tu función
• Conclusión práctica

Clasifica los tipos de CAPTCHA en cuatro ejes independientes

Una lista que coloca «casilla», «invisible», «puntuación de riesgo» y «prueba de trabajo» en cuatro filas excluyentes mezcla preguntas diferentes. Una casilla describe una interfaz. Invisible describe la ausencia de un widget visible. Una puntuación describe una evaluación devuelta por un servicio concreto. La prueba de trabajo describe una tarea computacional. Elegir una etiqueta no descarta las demás.

Utiliza cuatro campos en vez de intentar identificar un único tipo universal. Los valores siguientes son opciones de clasificación, no mediciones de un proveedor en funcionamiento. Completa el campo del mecanismo solo cuando lo establezca una descripción oficial del producto o el propietario del despliegue.

Eje	Pregunta	Ejemplos de valores	Qué no puede demostrar el campo
Interacción	¿Qué ve o hace la persona?	Casilla, tarea con imágenes, tarea de texto, ningún widget visible	Qué entradas privadas se evaluaron
Mecanismo	¿Qué evidencia o control está documentado?	Evaluación de riesgo, prueba computacional, mecanismo de atestación	Sus ponderaciones no divulgadas o el resultado de esta solicitud
Ubicación	¿Dónde se integra el control?	Widget integrado en la aplicación, página intersticial de desafío	Si el resto de la aplicación autorizó la operación
Decisión	¿Qué componente acepta qué?	El proveedor verifica un token; el sitio aplica su propia política	Si un éxito en el navegador significa un éxito de la operación de negocio

Estos ejes también explican por qué un desafío puede cambiar de aspecto durante una misma visita. Google documenta que una casilla de reCAPTCHA v2 puede superarse inmediatamente o presentar un desafío. Es una bifurcación admitida dentro de una misma integración, no una prueba de que el sitio haya cambiado de proveedor de CAPTCHA. La cronología de un incidente necesita la transición real, no una nueva categoría deducida de cada pantalla.

El artículo relacionado sobre el diagnóstico de un CAPTCHA durante una ejecución aborda la investigación de la ruta, la sesión del navegador y la carga de trabajo cuando aparece un desafío. La clasificación responde a una pregunta anterior: ¿qué hechos demuestra la pantalla y cuáles requieren documentación del proveedor o evidencia del propietario del sitio? No sustituye esa investigación del incidente por una etiqueta de proveedor.

El alcance de una afirmación importa tanto como la etiqueta. «Este producto documenta un control computacional en segundo plano» se refiere a una familia de productos. «Esta solicitud falló ese control» se refiere a una ejecución y necesita la evidencia correspondiente. La primera afirmación no demuestra la segunda. Mantén las capacidades del producto y las observaciones de la solicitud en columnas separadas en cualquier registro de soporte.

Qué demuestran las tareas visibles

La conocida casilla solicita una interacción visible, pero su posición en la página dice poco sobre el proceso completo de verificación. En la comparación de versiones de reCAPTCHA de Google, el flujo con casilla de v2 puede aceptar la interacción sin otra tarea o exigir un desafío adicional. Por tanto, hacer clic en la casilla no mide una puntuación numérica pública ni demuestra que no haya habido una evaluación en segundo plano.

Una tarea con imágenes también es un formato de interacción. Su aparición demuestra que se presentó una tarea basada en imágenes. No indica a un observador del cliente por qué se eligió esa tarea, si el mismo visitante verá otro formato más adelante o si completarla correctamente satisfará una restricción independiente de la cuenta. Describe la tarea mostrada sin inventar la regla de selección.

Las tareas de introducción de texto y otras tareas visibles encajan en el mismo enfoque de clasificación. Difieren en la interacción exigida, las necesidades de accesibilidad y los posibles errores de entrada. Estas diferencias prácticas importan cuando el propietario de una aplicación prueba el flujo de usuario admitido. No sirven para clasificar la calidad de seguridad de productos enteros ni revelan la evidencia de fondo utilizada para seleccionar una tarea.

«Invisible» también necesita un sujeto preciso. Google describe reCAPTCHA v2 invisible como una integración que no exige hacer clic en una casilla; puede invocarse mediante un botón o una llamada a la API, y el tráfico sospechoso aún puede recibir un desafío. La ausencia de una casilla inicial no promete, por tanto, que nunca vaya a aparecer una tarea visible.

Cloudflare documenta los modos Managed, Non-Interactive e Invisible de los widgets de Turnstile. Managed puede elegir un control sin interacción o solicitar una interacción con una casilla. Non-Interactive muestra un widget sin exigir interacción; Invisible se ejecuta sin mostrar el widget. Un recuadro visible y un clic obligatorio son hechos distintos, incluso dentro del mismo producto.

La guía de modos invisible y pasivo de hCaptcha establece otra distinción útil. Invisible elimina la casilla inicial, mientras que el comportamiento pasivo se refiere a si se presenta un desafío interactivo. La documentación describe la combinación de los modos invisible y pasivo en la oferta Enterprise correspondiente. No generalices una opción de una oferta como si fuera una promesa para todas las cuentas o integraciones.

Observación visible	Descripción respaldada	Deducción sin respaldo
Se muestra una casilla	La integración ofrece una interacción con casilla	Debe existir una puntuación de riesgo pública
Se muestra una tarea con imágenes	El flujo presentó una tarea basada en imágenes	La causó una señal concreta del navegador
Un widget es visible, pero no se pide un clic	La interfaz no exige interacción en este momento	No se está ejecutando ningún control del navegador
No hay un widget visible	No se observó ningún widget en ese estado	No existe ninguna integración de desafíos ni verificación

Para las pruebas de accesibilidad y de la aplicación, registra la interacción realmente exigida, la configuración documentada y el estado pertinente de la página. Una captura puede respaldar el primer hecho. La configuración del propietario puede demostrar el segundo. Ninguna aporta el mecanismo oculto ni un veredicto del proveedor al que el observador no tenga acceso. Evita tratar una captura de pantalla cuidada como evidencia sobre un modelo de puntuación no documentado.

Qué pueden medir los controles en segundo plano

Una evaluación de riesgo no es el mismo resultado que la respuesta a un acertijo. La documentación de reCAPTCHA v3 de Google describe una puntuación para cada solicitud sin introducir fricción para el usuario y deja que el sitio decida qué acción tomar. También describe acciones que aportan contexto para interpretar los resultados. Ese modelo de respuesta documentado no pone una puntuación numérica a disposición de cualquier cliente de navegador.

No debe atribuirse la existencia de una puntuación a todos los widgets. Un producto puede emitir un token de verificación sin exponer una puntuación numérica de riesgo mediante su integración estándar. A la inversa, un producto basado en puntuaciones puede alimentar una política del sitio que solicite otra forma de verificación. El resultado del proveedor, la respuesta elegida por el sitio y la interacción mostrada al visitante son registros separados.

La prueba de trabajo describe un control computacional, no una presentación visible. La descripción general de Turnstile enumera entre sus controles la prueba de trabajo, la prueba de espacio y el sondeo de API web. Varios mecanismos pueden participar en el mismo sistema. Sería incorrecto convertir esa lista en productos CAPTCHA mutuamente excluyentes o concluir que un widget invisible utiliza solo uno de ellos.

Un mecanismo de atestación se refiere a evidencia emitida o comprobada bajo un acuerdo de confianza concreto. La afirmación exacta, el emisor, los requisitos previos y el verificador dependen del esquema documentado. No es otra forma de decir invisible. Si la documentación pública de un proveedor no establece qué mecanismo de atestación corresponde al flujo desplegado, déjalo sin especificar en vez de completar el campo a partir de su apariencia visual.

La palabra «medir» requiere cautela aquí. Una página oficial puede nombrar una categoría de controles sin revelar sus ponderaciones, umbrales, composición o uso en una solicitud concreta. Un cliente puede observar que se ejecutó un script o que un widget cambió de estado. Esas observaciones no permiten reconstruir el procedimiento completo de decisión del servidor. Ninguna expresión en la consola del navegador convierte una evaluación no divulgada del proveedor en un valor de diagnóstico local fiable.

Las características del navegador son entradas potenciales, no explicaciones universales. Un control del navegador basado en perfiles puede cambiar un valor documentado a nivel de navegador; un proxy cambia una ruta de red. Ninguno de esos cambios prueba qué evaluó un proveedor ni demuestra que esas entradas causaran el fallo de una solicitud de la aplicación. Conserva un registro de configuración del navegador para poder reproducir el entorno, pero no presentes las diferencias de configuración como causas de CAPTCHA medidas.

Por eso una etiqueta genérica de «humano o bot» también resulta demasiado imprecisa para un incidente de soporte. Un resultado puede referirse a la verificación del token, a una evaluación contextual o a una regla independiente de la aplicación. La pregunta útil es qué componente devolvió qué campo documentado. Una etiqueta amplia pierde esa distinción y puede dirigir tanto al operador como al equipo de la aplicación hacia una solución que la evidencia no respalda.

Sigue un token hasta la decisión del servidor

Una función de retorno de finalización en el navegador es un evento dentro de un flujo más largo. En las integraciones tratadas aquí, el sitio debe realizar la verificación del lado del servidor exigida por el proveedor antes de confiar en el token de respuesta. Después, la aplicación decide si permite la operación solicitada según sus propias reglas. Un token no es una credencial de autorización general para todas las rutas del sitio.

Utiliza este modelo ordenado al examinar una integración: el navegador ejecuta el flujo de cliente configurado; se entrega un token de respuesta a la aplicación; el backend lo valida con el proveedor; el backend comprueba los campos devueltos pertinentes para su integración; la aplicación aplica su política. Son responsabilidades lógicas, no una traza de paquetes capturada en el despliegue de un cliente real.

La documentación de verificación del lado del servidor de Google exige una solicitud del backend con el secreto y el token de respuesta. Indica que cada token de respuesta es válido durante dos minutos y puede verificarse una vez. El secreto debe estar en el servidor. Un registro del navegador que contenga un token no prueba que una solicitud de verificación posterior haya tenido éxito, y el propio token no debe pegarse en un informe público del incidente.

Para v3, la guía oficial indica que el sitio debe verificar la acción y evaluar la puntuación en su contexto. Es una responsabilidad de integración del propietario. Un visitante que ve fallar el envío de un formulario no puede deducir la puntuación devuelta, la política configurada ni el resultado de esos controles solo por inspeccionar el texto de error del formulario. Solicita una correlación al operador en vez de tratar una puntuación adivinada localmente como evidencia.

La guía de validación del lado del servidor de Turnstile de Cloudflare también exige Siteverify; el widget del cliente por sí solo es insuficiente. Documenta una vigencia del token de 300 segundos desde su generación y un uso previsto de una sola vez. Sin embargo, la detección de reutilización tiene consistencia eventual: validaciones realizadas con muy poca separación temporal pueden tener éxito antes de que se propague el estado de canje. Esto no constituye un contrato de tokens reutilizables. No implementes una caché de tokens reutilizables ni equipares un evento de finalización del widget con una validación correcta en el backend. El comportamiento documentado por el proveedor sigue siendo la referencia para gestionar la reutilización de tokens.

Etapa	Evidencia disponible para el componente responsable	Qué sigue sin probar el éxito
Interacción del cliente	Estado del widget, función de retorno o error documentado del cliente	Que la validación del token en el backend haya tenido éxito
Verificación del proveedor	La respuesta real de Siteverify	Que la aplicación permita la operación de negocio
Política de la aplicación	Controles configurados por el propietario y registros de solicitudes	Que se vaya a aceptar toda operación futura
Resultado de la aplicación	El resultado autenticado o transaccional esperado	Que otra sesión tenga la misma evaluación

Un widget integrado y una página de desafío en el perímetro también ocupan lugares diferentes en la ruta de una solicitud. Turnstile puede integrarse sin exigir que el tráfico del sitio pase por la CDN de Cloudflare. Las Challenge Pages de Cloudflare pueden, en cambio, sustituir por HTML la respuesta esperada de un recurso. El diagnóstico de un scraper bloqueado por capas distingue las observaciones de solicitud, transporte y aplicación; utiliza esa investigación cuando cambie el propio cuerpo de la respuesta, en vez de suponer que todo control relacionado con Cloudflare corresponde a la misma integración.

Redacta una observación sin inventar una puntuación

Un registro de observación útil indica cómo se estableció cada campo. Separa la evidencia visible de una capacidad oficial del producto y de los hechos que solo conoce el propietario. El texto siguiente es una plantilla en blanco que puedes copiar, no el resultado de una prueba de un proveedor. Sustituye cada elemento entre corchetes por un valor verificado o déjalo como desconocido.

interaction_observed: [checkbox / image task / no visible widget / unknown]
product_identification: [documented integration or owner confirmation / unknown]
mechanism_documented: [official source and applicable mode / unknown]
placement_observed: [embedded / interstitial / unknown]
client_completion_observed: [yes / no / unknown]
backend_verification: [owner-confirmed result / unknown]
application_result: [expected result / refused / unknown]
correlation_reference: [redacted request reference / unavailable]

Como ejemplo concreto de razonamiento, supongamos que una persona autorizada para realizar pruebas ve una casilla integrada en un formulario de inicio de sesión y, más tarde, un error genérico del formulario. Es un escenario hipotético. El campo de interacción puede indicar casilla; el de ubicación, integrada. Sin los detalles de integración, el producto y el mecanismo siguen siendo desconocidos. Sin evidencia del backend, la verificación sigue siendo desconocida. El error del formulario demuestra un resultado fallido de la aplicación, no una puntuación concreta ni un fallo de una prueba.

Supongamos ahora que el propietario del sitio confirma el producto y proporciona una respuesta de verificación fallida, con los datos sensibles ocultos, para esa solicitud exacta. Con esa evidencia, el campo del backend puede actualizarse y dejar de ser desconocido. Aun así, no demuestra por qué el proveedor produjo el resultado más allá de los campos documentados de la respuesta, ni demuestra que cambiar de navegador lo solucionaría. Cada afirmación adicional necesita su propia fuente.

Registra el alcance de una observación además de su contenido. Una solicitud de producción, una clave oficial de prueba y una función de retorno simulada localmente tienen objetivos diferentes. Una simulación puede probar cómo gestiona una aplicación una función de retorno, pero no puede demostrar el comportamiento del proveedor. Un recurso de prueba del proveedor puede ejercitar la ruta de integración documentada bajo sus condiciones indicadas, pero no mide la evaluación de riesgo de producción habitual. Etiqueta esos entornos explícitamente.

Mantén los secretos, los tokens de respuesta completos, las cookies y los datos personales fuera de un registro compartido. Una referencia mínima de correlación y un error documentado con los datos sensibles ocultos suelen ser más útiles que un volcado completo del navegador. El propietario puede conservar los detalles necesarios conforme a las reglas de acceso y retención de la propia aplicación. Recopilar más datos no produce automáticamente una explicación más precisa.

Elige la siguiente acción según tu función

El propietario de un sitio puede inspeccionar la configuración y los registros de verificación del backend. Un operador de automatización autorizado normalmente no puede. Elige el siguiente paso a partir de ese límite de acceso, en vez de basarte en la promesa de que un «tipo» concreto de CAPTCHA tiene una solución universal. La clasificación es útil cuando dirige la solicitud al responsable del componente adecuado y evita experimentos locales sin respaldo.

Tu función y la situación observada	Siguiente acción acotada	Evita concluir
Propietario del sitio; el flujo del cliente termina, pero la aplicación rechaza la operación	Correlacionar los registros exactos de validación del backend y de política de la aplicación	Que completar el widget garantice permiso
Responsable de pruebas de integración; no se ve ningún widget	Confirmar el producto y el modo configurados con la guía oficial de integración	Que el control no exista o se base exclusivamente en atestación
Operador autorizado; los datos esperados se convierten en un desafío	Pausar la extracción dependiente y conservar un registro mínimo de la transición	Que el proveedor haya identificado un valor concreto del navegador
Revisor de soporte; solo hay una captura disponible	Clasificar la interacción y solicitar la evidencia que falta del lado del propietario	Que se conozca la puntuación oculta o el mecanismo exacto de prueba

La referencia de coherencia de automatización de BotBrowser documenta controles a nivel de navegador basados en perfiles, incluidas las superficies especificadas relacionadas con la automatización. Su referencia de configuración de proxy abarca la configuración de enrutamiento admitida. Estos controles ayudan a describir un entorno reproducible; no validan tokens del proveedor, no cambian la política de autorización de una aplicación ni demuestran un resultado libre de desafíos. Ninguna de las dos referencias documenta una solución CAPTCHA de uso general.

Para una integración existente, termina con una pregunta que pueda responderse: ¿qué componente es responsable del primer paso no verificado? Si el resultado del backend no está disponible, interpretar más la casilla no lo proporcionará. Si la validación del token tuvo éxito, pero la aplicación rechazó la acción, investiga la decisión de la aplicación a través de su responsable autorizado. Si un sitio de terceros exige un desafío, utiliza su vía admitida de recuperación humana o por operador, en vez de tratar la tabla de clasificación como permiso para continuar la extracción.

Preguntas frecuentes

¿Un CAPTCHA invisible es lo mismo que reCAPTCHA v3?

No. reCAPTCHA v2 invisible, reCAPTCHA v3, Turnstile Invisible y los modos invisibles de hCaptcha tienen modelos de integración documentados diferentes. «Invisible» describe la presentación, no una interfaz de puntuación común. Identifica el producto y el modo reales antes de aplicar su documentación de verificación.

¿Una casilla significa que el servicio midió una puntuación de riesgo?

Una casilla por sí sola no demuestra la existencia de una puntuación numérica expuesta al sitio. Lee el contrato de respuesta del producto desplegado. Incluso cuando un servicio devuelve una puntuación, la interacción visible no revela el valor de la solicitud concreta.

¿Puede un mismo sistema utilizar prueba de trabajo y un widget visible?

Sí, los mecanismos y los modos de interacción no tienen por qué ser excluyentes. Turnstile documenta controles computacionales junto con varios modos de widget. Esa afirmación a nivel de producto no prueba que una solicitud concreta utilizara todos los mecanismos documentados; la ejecución exacta sigue siendo desconocida salvo que la evidencia aplicable la establezca.

Fuentes

• Google: versiones de reCAPTCHA
• Google: reCAPTCHA v3
• Google: verificación de la respuesta del usuario
• Cloudflare: Turnstile
• Cloudflare: modos del widget
• Cloudflare: validación del lado del servidor
• hCaptcha: modos invisible y pasivo
• BotBrowser: coherencia de automatización
• BotBrowser: configuración de proxy

Conclusión práctica

Describe la interacción que realmente observaste, añade solo mecanismos documentados, localiza la integración y deja la decisión del backend como desconocida hasta que su responsable la confirme. Una casilla no es una puntuación, invisible no es atestación y un token no es autorización de la aplicación. Empieza con la clasificación de cuatro campos y pide al responsable del primer paso no verificado la evidencia necesaria para continuar.