reCAPTCHA v3 vs v2: responsabilidades del sitio

La elección útil entre reCAPTCHA v3 vs v2 depende de qué interacción y responsabilidades del servidor puede asumir un sitio. V2 con casilla presenta una interacción deliberada; v2 invisible aún puede mostrar un desafío; v3 devuelve una puntuación que el sitio debe convertir en una decisión de la aplicación. BotBrowser proporciona controles del navegador basados en perfiles para un entorno de cliente reproducible, pero no puede elegir esa política, verificar un token del proveedor en nombre del sitio ni revelar una puntuación privada a un visitante. Una integración existente necesita un responsable identificado tanto del flujo del navegador como del resultado del backend.

Estos nombres se refieren a integraciones web clásicas existentes, incluidas las integraciones admitidas que se conservan después de migrar una cuenta. La documentación actual de claves de Google Cloud relaciona CHECKBOX con la versión heredada v2 Checkbox, INVISIBLE con la versión heredada v2 Invisible y SCORE con la versión heredada v3. La guía de migración de Google confirma que la instrumentación y las llamadas al backend existentes pueden continuar. El aviso de obsolescencia de las guías clásicas no significa que esos contratos desplegados hayan dejado de funcionar; las nuevas funciones de Cloud y los procedimientos de migración requieren su propia documentación vigente.

Resumen

• Compara las tres integraciones web reales: v2 con casilla, v2 invisible y v3. V2 invisible no es otro nombre de v3.
• Todas las integraciones necesitan verificar el token en el backend. Una función de retorno correcta en el navegador no autoriza el envío de un formulario.
• V3 exige que el sitio compruebe la acción esperada y decida qué significa la puntuación devuelta para esa operación. Eliminar un acertijo no elimina ese trabajo.
• Selecciona una interacción que la aplicación pueda explicar y de la que pueda recuperarse; después, asigna los controles del servidor y el resultado de la aplicación a responsables concretos.
• Las guías clásicas de Google muestran ahora un aviso de obsolescencia. La documentación actual de Cloud relaciona sus nombres heredados y admite las integraciones existentes; confirma la clave y la API desplegadas en vez de aplicar esta comparación a todos los productos actuales.

Contenido

• La matriz de decisión para una integración web existente
• El flujo del navegador cambia la experiencia del usuario
• La verificación del backend sigue siendo obligatoria
• V3 añade una política de acción y puntuación
• La lista de responsabilidades de implementación
• Tres elecciones hipotéticas y sus rutas de fallo
• Conclusión práctica

La matriz de decisión para una integración web existente

La comparación de versiones de Google distingue las modalidades de v2 con casilla e invisible de v3. La comparación se refiere a sus contratos documentados de integración web, no a una clasificación medida de la eficacia de seguridad. Un sitio que ya utiliza uno de estos contratos puede evaluar un cambio preguntándose qué tendrían que asumir después su interfaz y su backend. Un visitante que intenta explicar un rechazo tiene una tarea diferente y normalmente carece de los registros del servidor necesarios para tomar esta decisión.

La terminología tiene un límite actual. La documentación de claves de Google relaciona SCORE con la versión heredada v3, CHECKBOX con la versión heredada v2 Checkbox e INVISIBLE con la versión heredada v2 Invisible. También describe otros tipos de integración. Por tanto, los nombres antiguos siguen siendo útiles para identificar implementaciones existentes, pero no describen toda la gama actual de productos. La siguiente matriz se aplica a los flujos web clásicos indicados y a su modelo documentado de verificación; no recomienda iniciar por defecto un nuevo despliegue de Cloud con una API antigua.

Campo de decisión	V2 con casilla	V2 invisible	V3
Interacción inicial del usuario	Hacer clic en la casilla mostrada	Invocar desde un botón o una API de JavaScript; sin clic inicial en una casilla	Invocar para una acción del sitio sin que una tarea CAPTCHA interrumpa ese flujo
Posible desafío en el flujo documentado	Puede aceptarse inmediatamente o presentar un desafío	Puede presentar un desafío pese al punto de entrada invisible	Devuelve una puntuación; el sitio elige su respuesta posterior
Responsabilidad de integración en el navegador	Mostrar el widget correcto y gestionar finalización, caducidad y errores	Vincular la ejecución a la operación prevista y gestionar finalización, caducidad y errores	Ejecutar para la acción prevista y enviar rápidamente el token al backend
Responsabilidad de verificación del backend	Validar el token de respuesta mediante el endpoint documentado del servidor	Validar el token de respuesta mediante el endpoint documentado del servidor	Validar el token de respuesta y comprobar la acción esperada
Responsabilidad de política de la aplicación	Decidir si la operación verificada está permitida por las reglas de la aplicación	Decidir si la operación verificada está permitida por las reglas de la aplicación	Interpretar la puntuación en el contexto de la operación y aplicar la política del sitio
Una razón para considerar este contrato	Un paso deliberado con casilla encaja en el recorrido actual del usuario	El formulario existente debe activar la verificación desde su propio botón y conservar una ruta de desafío	El sitio puede asumir el tratamiento contextual de puntuaciones y la ruta de usuario o moderación resultante
Una razón para aplazar el cambio	La interfaz no puede admitir la interacción o sus estados de recuperación	El equipo no ha diseñado los posibles estados de desafío y de función de retorno	Nadie es responsable de validar la acción, tratar la puntuación o responder desde la aplicación

Las dos últimas filas son reglas de elección de ingeniería, no afirmaciones de rendimiento de Google. Por ejemplo, un equipo que no ha asignado el tratamiento de puntuaciones no puede hacer desaparecer esa obligación seleccionando un flujo de cliente menos visible. A la inversa, un equipo que mantiene v2 sigue necesitando un verificador real en el backend. El modelo de clasificación de CAPTCHA separa presentación y mecanismo; la decisión adicional aquí es qué contrato documentado implementará y mantendrá la aplicación.

Las claves existentes también necesitan un inventario administrativo. La guía actual de migración de Classic de Google indica que las integraciones existentes admitidas pueden conservar su instrumentación web y sus llamadas al backend, y seguir utilizando siteverify después de la migración. Esa afirmación no convierte la migración de una cuenta en la misma operación que cambiar de v2 a v3. Registra por separado la titularidad de la clave, la integración de cliente desplegada y el endpoint del backend antes de decidir qué responsabilidad está cambiando realmente.

El flujo del navegador cambia la experiencia del usuario

En v2 con casilla, el sitio muestra un widget que pide al visitante hacer clic. La guía de visualización de v2 de Google admite la presentación automática o la presentación explícita después de cargar la biblioteca. La elección afecta a cómo inicializa la aplicación el control, especialmente cuando se monta dinámicamente un formulario. Un recuadro mostrado por sí solo no demuestra que el controlador de envío de la aplicación adjunte el token de respuesta correcto a la operación correcta.

El flujo con casilla puede aceptar la interacción inmediatamente o solicitar otro desafío, según la comparación de versiones. La aplicación debe admitir esa bifurcación en vez de prometer el mismo número de clics a todos los visitantes. El equipo de soporte también necesita distinguir un widget que nunca se inicializó de un visitante que llegó a un desafío. Son estados de usuario diferentes y necesitan explicaciones diferentes; ninguno demuestra la existencia de una puntuación numérica visible para el visitante.

V2 invisible cambia el punto de entrada. La guía de invisible de Google permite vincular automáticamente un botón, vincularlo mediante programación o invocar el control mediante programación. Por tanto, un botón Enviar normal puede iniciar el control sin una casilla previa. Sin embargo, esta integración todavía puede solicitar un desafío. Llamarla invisible no compromete a que todo el recorrido de la aplicación permanezca libre de verificación visible, ni proporciona al sitio el contrato documentado de respuesta con puntuación de v3.

La función de retorno forma parte del flujo de control del formulario. En una integración invisible, la aplicación puede realizar primero su validación habitual de campos, invocar la verificación y enviar después de la función de retorno de finalización. El ejemplo oficial de invisible ilustra esa secuencia. Una aplicación real sigue teniendo que evitar que una función de retorno ajena, una activación repetida del botón o un estado obsoleto del formulario se confundan con la finalización de la operación actual. Es un requisito de asociación de la aplicación, no una afirmación de que la biblioteca cliente de Google proporcione un gestor de transacciones de la aplicación.

V3, en cambio, vincula la ejecución a una acción y devuelve un token para su evaluación en el backend. La guía de v3 describe la vinculación a botones y la invocación mediante programación, y aconseja ejecutar cuando el usuario realiza la acción en vez de hacerlo al cargar la página, porque los tokens caducan. Una página de pago que permanece abierta mucho tiempo no puede tratar su carga inicial como un evento de verificación permanente. El responsable del cliente debe identificar la operación protegida real y el momento en que debe obtenerse su token.

La accesibilidad sigue formando parte del recorrido de la aplicación, sea cual sea el contrato que conserve. La configuración de visualización documenta controles de idioma y tabindex, mientras que la guía de invisible también describe la posición de la insignia y el tratamiento de las funciones de retorno. Estas opciones no certifican que el formulario circundante sea accesible. Prueba el orden de foco, los mensajes de estado y la ruta de recuperación admitida por el sitio con el widget realmente configurado. La ausencia de una tarea CAPTCHA en v3 tampoco demuestra que un paso adicional elegido por la aplicación sea utilizable; el sitio es responsable del comportamiento que añade.

La verificación del backend sigue siendo obligatoria

La obligación compartida del servidor es más concreta y limitada que «el navegador pasó». La guía de verificación de Google exige que el backend envíe un POST a https://www.google.com/recaptcha/api/siteverify con el secreto y el token de respuesta. remoteip está documentado como opcional. Mantener el secreto en el backend forma parte de esta integración; recibir un token mediante una función de retorno es solo la entrega del cliente a la aplicación, no un sustituto de la solicitud al proveedor.

La misma guía limita cada token de respuesta a dos minutos y una verificación. Un backend que coloca un token en una cola de trabajo con demora indefinida no ha conservado una verificación válida solo porque la función de retorno original terminara. Una solicitud ya verificada no puede utilizar ese token de verificación como credencial de sesión reutilizable para operaciones no relacionadas. La aplicación necesita un flujo documentado nuevo cuando se requiere una nueva respuesta, mientras que sus propios controles de sesión y transacción mantienen sus fines independientes.

La referencia de errores del servidor distingue secretos ausentes o no válidos, respuestas ausentes o no válidas, una solicitud mal formada y timeout-or-duplicate. El último error combina dos posibilidades: una respuesta puede ser demasiado antigua o haberse utilizado ya. Por sí solo no identifica cuál de las dos posibilidades ocurrió. Un responsable puede correlacionar los tiempos y sus propias llamadas de verificación para investigar, pero no debe reinterpretar ese error combinado documentado como un fallo específico del navegador sin la evidencia correspondiente.

La verificación también tiene un contrato de respuesta. La respuesta web clásica documenta success, challenge_ts, hostname y error-codes opcionales; la respuesta de v3 documenta además score y action. challenge_ts describe el momento de carga del desafío, no la hora de una transacción de negocio completada. hostname aporta el contexto documentado del sitio, no prueba que la regla de cuenta o de pago de la aplicación autorizara nada. Conserva esos significados de los campos al diseñar los controles del servidor y los mensajes de incidentes.

El responsable del backend necesita un resultado definido para cuando no pueda completarse la verificación. Un tiempo de espera de red agotado hacia el endpoint de verificación, una respuesta con success: false y un token verificado seguido de un rechazo de la aplicación son tres estados diferentes. El protocolo de verificación define el intercambio con el proveedor; el sitio debe decidir cómo comunica y trata cada estado su propio endpoint. Una excepción sin gestionar o un mensaje ambiguo de «inténtalo de nuevo» no deben contarse silenciosamente como acceso verificado.

La autorización de la aplicación viene después de ese intercambio. Un token válido no demuestra que la contraseña fuera correcta, que una cuenta cumpliera los requisitos o que un pedido satisficiera las reglas del sitio. Si una integración existente cambia de versión, conserva estos controles en vez de tratar una nueva función de retorno del cliente como su sustituto. La guía de integración de v3 sitúa explícitamente la acción contextual después de la evaluación devuelta. La elección pertinente es qué resultado verificado recibe el backend y qué hará con él la aplicación.

V3 añade una política de acción y puntuación

El campo action de v3 es un acuerdo de integración entre la invocación del cliente y lo que espera el backend. Google indica que, al comprobar una respuesta, debe verificarse que el nombre de la acción sea el esperado. Su guía sobre acciones también limita los nombres de acción a caracteres alfanuméricos, barras y guiones bajos, e indica que no deben ser específicos del usuario. El sitio debe definir nombres para operaciones en vez de codificar en ese campo una dirección de correo, un identificador de cuenta u otra identidad de usuario.

El valor esperado debe proceder del conocimiento que tiene el servidor sobre la operación. Copiar simplemente el nombre de acción aportado por quien llama en un campo «esperado» no demostraría que coincidiera con el endpoint previsto. Para una operación existente de inicio de sesión, el responsable del backend debe saber qué acción documentada corresponde a esa operación antes de comprobar el valor devuelto. Es una consecuencia del requisito de acción esperada de Google, no una nueva API del proveedor ni una afirmación de que un sitio de terceros concreto lo aplique correctamente.

La puntuación es otro campo devuelto, no un veredicto de la aplicación. La documentación de v3 describe un intervalo de 0.0 a 1.0 y respuestas contextuales, como autenticación adicional o moderación. Por tanto, seleccionar v3 crea una responsabilidad de política del sitio: un responsable debe decidir qué respuesta corresponde a cada acción protegida y quién revisa los resultados inesperados. Ningún umbral universal ni receta de configuración del navegador puede sustituir esa decisión para todas las aplicaciones.

Google también indica que el servicio aprende del tráfico real, de modo que las puntuaciones de un entorno de pruebas o de poco después de la implementación pueden diferir de las de producción. Esa limitación de entorno importa al aceptar un cambio de versión. Un formulario de pruebas que llega a su página de éxito solo prueba el resultado declarado de la integración de pruebas; no establece la distribución de puntuaciones de producción ni la idoneidad de una política de la aplicación. Separa la corrección de la verificación de cualquier evaluación posterior de las decisiones operativas del sitio.

La descripción pública clásica indica que las puntuaciones se basan en interacciones con el sitio y que un contexto más amplio incluye comportamiento legítimo y abusivo. No publica un modelo completo de ponderaciones con el que un cliente de navegador pueda calcular su propia puntuación. La guía de ubicación de v3 describe una integración, no demuestra que cambiar una propiedad del navegador vaya a cambiar un resultado concreto. Mantén esa distinción cuando tanto los ingenieros de la aplicación como los operadores de automatización autorizados utilicen una comparación de versiones.

El resultado visible pertenece a un campo diferente del resultado del proveedor. Por ejemplo, la aplicación puede exigir otro paso de autenticación después de la evaluación; la ausencia de un acertijo no significa que la operación solicitada se concediera inmediatamente. Los ejemplos de interpretación de puntuaciones de Google demuestran esa separación. Una decisión de versión debe nombrar la respuesta prevista de la aplicación y a su responsable antes del despliegue, en vez de dejar el comportamiento del producto a una interpretación no documentada de cualquier número que llegue.

La lista de responsabilidades de implementación

La siguiente lista convierte la matriz en un traspaso entre los equipos de la aplicación. Su resultado esperado es un responsable identificado y una respuesta documentada para cada responsabilidad exigida por el contrato seleccionado. Es una lista de diseño, no una respuesta capturada del proveedor ni una prueba del comportamiento de un sitio desplegado. Los requisitos de verificación y el contrato de acción de v3 de Google aportan las obligaciones del proveedor; la asociación y las opciones de recuperación de la aplicación corresponden al sitio.

Responsabilidad que debe asignarse	Evidencia que debe aportar el responsable	Elección afectada
Inventario de claves e integración	El producto configurado, la titularidad de la clave y los nombres de API del cliente y backend, sin compartir secretos	Confirma qué contrato existente se mantiene
Inicialización del navegador	La ruta de presentación o ejecución del widget, la operación protegida prevista y el tratamiento de finalización, caducidad y errores	Distingue casilla, invocación invisible y ejecución de acción de v3
Verificación del token	Tratamiento en el backend de la solicitud documentada de verificación y de los estados de fallo devueltos	Obligatoria para todas las integraciones comparadas
Acción esperada	La acción controlada por el servidor para cada endpoint protegido y su comparación con el campo devuelto por v3	Exigida por el contrato de v3
Respuesta a la puntuación	El responsable de la política de la aplicación y el resultado admitido para cada operación pertinente	Hace utilizable la evaluación de v3 sin confundirla con autorización
Resultado de la aplicación	Los controles habituales de autenticación o transacción y un resultado inequívoco para el usuario	Sigue siendo responsabilidad del sitio después de la verificación del proveedor
Recuperación y soporte	Una forma de distinguir inicialización del cliente, respuesta caducada, verificación del backend y rechazo de la aplicación	Evita que todos los fallos se conviertan en un error CAPTCHA sin explicación

La inicialización del cliente merece un caso de aceptación específico. La guía de visualización de v2 exige que exista una función de retorno onload para la presentación explícita antes de que se cargue la API. Eso crea un requisito real de orden para las aplicaciones que cargan componentes y scripts de forma asíncrona. El responsable del cliente debe verificar la ruta de presentación elegida en vez de suponer que ver api.js en un panel de red prueba que el control estaba listo cuando el usuario envió el formulario. Un evento de carga de la biblioteca y un estado utilizable del formulario son condiciones de aceptación diferentes.

Las funciones de retorno de caducidad y error también necesitan un tratamiento visible. La configuración de invisible de Google describe esas funciones y hace responsable a la aplicación de informar al usuario de que debe reintentar cuando proporciona una función de retorno de error. Una decisión de mantenimiento debe incluir el mensaje y la acción de recuperación permitida, no solo el nombre de la función de retorno. El backend debe gestionar de forma independiente una respuesta caducada o no válida, aunque el cliente haya presentado un mensaje informativo.

La referencia de coherencia de automatización de BotBrowser puede respaldar una configuración repetible del navegador cuando un equipo ejercita su aplicación autorizada. Esa capacidad ayuda a comparar el mismo comportamiento del formulario en un entorno declarado. No implementa las responsabilidades del servidor de la lista, no emite las credenciales del sitio ni establece una puntuación del proveedor a partir de observaciones locales del navegador. Una prueba del formulario debe comunicar la condición de la aplicación realmente comprobada, registrando la versión de integración seleccionada por separado de cualquier conclusión sobre el acceso.

Tres elecciones hipotéticas y sus rutas de fallo

Considera un formulario de soporte existente hipotético que utiliza v2 con casilla. Su responsable quiere eliminar la casilla inicial, pero mantener un flujo capaz de presentar desafíos. Comparar las variantes documentadas de v2 convierte v2 invisible en un contrato pertinente para evaluar. El trabajo concreto consiste en invocar desde el botón, asociar la función de retorno y permitir la recuperación del usuario, mientras la verificación del backend sigue siendo obligatoria. Llamar a ese cambio «pasar a v3» identificaría mal tanto el flujo de cliente seleccionado como la ausencia de una nueva obligación de política de puntuación de v3.

Considera ahora una aplicación hipotética que quiere v3 para una acción de inicio de sesión. El cliente puede invocar v3, pero el equipo no ha asignado la validación de la acción esperada ni la respuesta a una evaluación que requiera otro paso. La guía de acciones e interpretación de v3 de Google identifica las responsabilidades que faltan. La decisión de la matriz es aplazar el despliegue hasta que existan esos responsables y resultados de la aplicación, en vez de deducir que todo está listo porque aparece un token en una función de retorno del navegador. Este ejemplo no representa ninguna ejecución real del proveedor ni una puntuación medida.

Por último, supongamos que una integración de v3 mantenida hipotética recibe una respuesta del proveedor con success: true, pero la aplicación rechaza el envío. El backend debe distinguir la verificación del token, el control de la acción devuelta y su propio resultado de política. La definición de respuesta de v3 separa esos campos y responsabilidades; success no promete un inicio de sesión correcto. Sin el registro pertinente del servidor, un observador externo no puede decidir si el rechazo se debió a la acción, al estado de la cuenta o a otra regla de la aplicación.

Estos escenarios terminan en responsables diferentes, aunque el usuario vea el mismo error genérico. Una ruta de inicialización rota corresponde a la integración del cliente; una solicitud de verificación no válida, al backend; una evaluación válida seguida de una restricción prevista, al responsable de la política de la aplicación. Si, en cambio, un desafío interrumpe una ejecución de recopilación autorizada en otro sitio, el diagnóstico de CAPTCHA durante una ejecución trata la transición de solicitudes y la recuperación aprobada. La matriz de versiones no autoriza a sondear la política oculta del sitio ni a continuar la extracción después de su decisión de acceso.

Preguntas frecuentes

¿reCAPTCHA v3 es siempre mejor que v2?

Los contratos documentados asignan trabajos diferentes al sitio. V3 elimina la interacción CAPTCHA de su propio flujo, pero exige tratar contextualmente la puntuación y validar la acción esperada. V2 con casilla e invisible conservan sus posibilidades documentadas de desafío. Las descripciones de versiones no establecen una clasificación universal de eficacia para todas las aplicaciones, despliegues y casos de abuso.

¿reCAPTCHA v2 invisible es la misma integración que v3?

No. La guía de invisible describe un flujo de invocación de v2 que aún puede presentar un desafío. V3 tiene su propio contrato de acción y puntuación. Un botón que activa la verificación no identifica qué integración configuró su responsable.

¿Una respuesta correcta de Siteverify permite la operación?

Establece el resultado documentado de verificación. La aplicación sigue siendo responsable de sus controles de acción, de la política de puntuación aplicable y de las reglas habituales de autorización. Los campos de respuesta de v3 de Google deben mantenerse separados del resultado final de la aplicación.

¿Las integraciones clásicas existentes pueden seguir usando estos nombres?

La documentación actual de claves relaciona los nombres heredados, y la guía de migración de Google describe la continuidad de la instrumentación y las llamadas al backend existentes. Comprueba la clave y el contrato de integración reales; esas afirmaciones no extienden esta comparación a todas las funciones de Cloud ni constituyen un procedimiento de migración.

Fuentes

• Google: elegir el tipo de reCAPTCHA
• Google: visualización y configuración de reCAPTCHA v2
• Google: reCAPTCHA invisible
• Google: reCAPTCHA v3
• Google: verificar la respuesta del usuario
• Google Cloud: claves de reCAPTCHA y nombres de integración heredados
• Google Cloud: migrar desde reCAPTCHA Classic
• BotBrowser: coherencia de automatización

Conclusión práctica

Elige el contrato de v2 o v3 que vayas a mantener según la interacción que pueda admitir la aplicación y las responsabilidades del backend que sus responsables puedan implementar. Utiliza la matriz para identificar el flujo de cliente, mantener la verificación obligatoria y asignar explícitamente las decisiones de acción y puntuación de v3. Completa la lista de responsabilidades antes de un cambio de versión y valida después el resultado real de la aplicación. Una etiqueta de versión por sí sola no proporciona una política de autorización ni demuestra que un rechazo existente vaya a desaparecer.