El CAPTCHA está presente, pero no protege nada
Un widget visible de reCAPTCHA, hCaptcha o Turnstile dice poco sobre si un formulario está protegido. Estas son las configuraciones erróneas habituales y cómo revisar sus propios formularios en minutos.
Muchos propietarios de sitios web agregan un CAPTCHA al formulario de contacto, ven aparecer la pequeña insignia o casilla y dan por resuelto el problema del spam. Después sigue llegando basura. A menudo el CAPTCHA en sí funciona bien, pero no está conectado a nada que pueda detener a un bot. Este artículo recorre las formas habituales en que reCAPTCHA, hCaptcha y Cloudflare Turnstile terminan como decoración y cómo revisar sus propios formularios.
Dónde se produce realmente la protección
Los tres servicios funcionan con el mismo principio. Un script en el navegador ejecuta sus verificaciones y entrega al formulario un token: una cadena corta que indica «este visitante pasó». El token viaja junto con el envío del formulario a su servidor. Solo ahí se toma la decisión real: su servidor envía el token junto con una clave secreta al proveedor y recibe una respuesta de éxito o fallo, y en reCAPTCHA v3 también una puntuación. Si falta algún eslabón de esta cadena, el widget sigue viéndose perfectamente normal, pero un bot que envía directamente al manejador de su formulario pasa sin obstáculos.
La clave de prueba que deja pasar todo
Google, hCaptcha y Cloudflare publican claves especiales de prueba para que los desarrolladores ejecuten pruebas automatizadas sin resolver acertijos. Con la clave secreta de prueba correspondiente, la verificación siempre tiene éxito: esa es precisamente su finalidad. Están pensadas para entornos locales y de staging, pero con frecuencia sobreviven al paso a producción: un desarrollador las pega durante la construcción, el sitio se publica y nadie las sustituye. Al menos reCAPTCHA muestra un aviso en el widget que indica que solo es para pruebas, pero casi nadie lo ve con una configuración invisible. Si tanto la clave de sitio de prueba como la clave secreta de prueba están en producción, todos los envíos pasan, provengan de una persona o de un bot; si solo la clave de sitio es de prueba, la verificación falla y pueden rechazarse mensajes reales.
Un token que nadie verifica
El segundo caso clásico es un servidor que nunca consulta al proveedor. El widget se ejecuta, se crea y envía un token, y luego el manejador del formulario simplemente lo ignora. Las fuentes habituales son formularios escritos a mano, fragmentos copiados que solo cubren el lado del navegador y configuraciones de plugins a medio terminar. Un caso muy parecido es que el servidor sí llame al servicio de verificación, pero solo compruebe que se realizó la solicitud, no lo que dice la respuesta. O que el umbral de puntuación de reCAPTCHA v3 esté en 0, lo que acepta cualquier puntuación que devuelva el servicio. Algunos manejadores también aceptan los envíos ante un fallo («fail open»): si falta el token o falla la verificación, aceptan el mensaje de todos modos, y al bot le basta con omitir el token.
Cuando el widget nunca llega a cargarse realmente
Otras configuraciones erróneas rompen, en cambio, el lado del navegador. Si la clave de sitio no está registrada para el dominio —algo habitual después de pasar de staging a producción, cambiar de dominio o agregar un subdominio—, el proveedor se niega a emitir tokens y muestra un error en el widget o en la consola del navegador. Después de cambiar de tema o actualizar un plugin, el marcado del widget puede seguir en la página aunque haya desaparecido el script que lo hace funcionar. Una herramienta de consentimiento de cookies puede causar lo mismo si bloquea el script de CAPTCHA hasta que el visitante acepta. Lo que ocurre después depende del servidor: si exige un token válido, los visitantes reales ya no pueden enviar mensajes y nadie detecta las consultas perdidas; si no lo exige, los bots pasan libremente.
Hay otros dos casos que pasan desapercibidos con facilidad. Con reCAPTCHA v3, la insignia de la esquina solo indica que el script está cargado en algún lugar de la página, quizá por el tema o por otro plugin, mientras la integración del propio plugin de formularios está desactivada. Además, los plugins de caché pueden almacenar una página junto con un token incrustado en el HTML. Los tokens de CAPTCHA solo son válidos unos minutos y solo se pueden verificar una vez, por lo que un token en caché falla para los visitantes reales; la tentadora «solución» de desactivar la verificación elimina silenciosamente la protección.
- El widget muestra un aviso de «solo para fines de prueba»
- La insignia de v3 está en la esquina
- El widget se renderiza y devuelve un token
- Se detuvo el spam, pero también las consultas reales
- Se están usando claves públicas de prueba y todas las verificaciones tienen éxito
- La integración de reCAPTCHA del plugin de formularios está desactivada
- El servidor nunca envía el token para verificarlo o ignora el resultado
- La clave de sitio no está registrada para el dominio o vencieron los tokens en caché
Una breve revisión por su cuenta
- 1Abra la página del formulario en una ventana privada, abra las herramientas de desarrollador del navegador y busque en la consola errores del script de CAPTCHA.
- 2Compruebe que el widget realmente aparezca, una vez antes y otra después de aceptar el banner de cookies, y que el formulario no pueda enviarse cuando falta.
- 3En la consola de administración del proveedor, compruebe que la clave de sitio incluya su dominio de producción —con variantes como www— y que las claves de su plugin de formularios o código coincidan, en lugar de usar claves de la documentación o de una configuración de staging.
- 4En la configuración del plugin de formularios, asegúrese de que la integración de CAPTCHA esté activada para este formulario en particular; en reCAPTCHA v3, compruebe que el umbral de puntuación sea mayor que 0.
- 5Si tiene acceso al código, localice la verificación del lado del servidor y compruebe que rechace el envío cuando la respuesta sea negativa o falte el token.
- 6Excluya la página del formulario de la caché de página completa o asegúrese de que el token se genere de nuevo en el navegador.
- 7Envíe un mensaje real de prueba y compruebe que llegue; repita la verificación después de cambiar el tema, los plugins o la herramienta de consentimiento.
Un CAPTCHA es una capa, no toda la protección. Al combinarlo con un campo trampa, una verificación de tiempo y un filtrado del lado del servidor, una configuración errónea en un punto no deja el formulario completamente abierto. Si quiere una visión rápida de la situación de sus formularios, ingrese su dominio en formexposed.com: el informe muestra si las partes de su configuración de CAPTCHA visibles desde el exterior están en orden.