El CAPTCHA está ahí, pero no protege nada

Muchos propietarios de sitios web añaden un CAPTCHA a su formulario de contacto, ven aparecer el pequeño distintivo o la casilla y dan por resuelto el problema del spam. Y la basura sigue llegando. A menudo, el CAPTCHA en sí está bien; simplemente no está conectado a nada que pueda detener a un bot. Este artículo repasa las formas típicas en que reCAPTCHA, hCaptcha y Cloudflare Turnstile acaban siendo decoración, y cómo comprobar sus propios formularios.

Dónde se produce realmente la protección

Los tres servicios funcionan según el mismo principio. Un script en el navegador realiza sus comprobaciones y entrega al formulario un token, una breve cadena que dice «este visitante ha superado la prueba». El token viaja con el envío del formulario hasta su servidor. Solo allí se toma la decisión real: su servidor envía el token junto con una clave secreta al proveedor y recibe una respuesta (éxito o fallo y, en el caso de reCAPTCHA v3, también una puntuación). Si falta cualquier eslabón de esta cadena, el widget sigue pareciendo perfectamente normal, pero un bot que envía directamente al gestor de su formulario pasa sin más.

La clave de prueba que lo deja pasar todo

Google, hCaptcha y Cloudflare publican claves de prueba especiales para que los desarrolladores puedan ejecutar pruebas automatizadas sin resolver acertijos. Con el secreto de prueba correspondiente, la verificación siempre tiene éxito: esa es precisamente su finalidad. Están pensadas para entornos locales y de staging, pero sobreviven con frecuencia al paso a producción: un desarrollador las pega durante el desarrollo, el sitio se publica y nadie las cambia. reCAPTCHA al menos muestra en el widget un aviso de que solo sirve para pruebas, pero con una configuración invisible casi nadie se fija. Si tanto la clave de sitio de prueba como el secreto de prueba están activos, todos los envíos pasan, procedan de una persona o de un bot; si solo la clave de sitio es de prueba, la verificación falla en su lugar y pueden rechazarse mensajes reales.

Un token que nadie comprueba

El segundo clásico es un servidor que nunca consulta al proveedor. El widget funciona, se crea y se envía un token, y después el gestor del formulario simplemente lo ignora. Las fuentes típicas son los formularios escritos a mano, los fragmentos copiados que solo cubren la parte del navegador y las configuraciones de plugins a medio terminar. Un pariente cercano: el servidor sí llama al servicio de verificación, pero solo comprueba que la solicitud se ha realizado, no lo que dice la respuesta. O el umbral de puntuación de reCAPTCHA v3 está fijado en 0, lo que acepta cualquier puntuación que pueda devolver el servicio. Algunos gestores también «fallan en abierto»: si falta el token o la verificación falla, aceptan el mensaje igualmente, y un bot simplemente omite el token.

Cuando el widget nunca llega a cargarse del todo

Otras configuraciones erróneas rompen en cambio la parte del navegador. Si la clave de sitio no está registrada para el dominio (algo típico tras pasar de staging a producción, un cambio de dominio o un nuevo subdominio), el proveedor se niega a emitir tokens y muestra un error en el widget o en la consola del navegador. Tras un cambio de tema o la actualización de un plugin, el marcado del widget puede seguir en la página mientras que el script que le da vida ha desaparecido. Una herramienta de consentimiento de cookies puede tener el mismo efecto si bloquea el script del 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 se da cuenta de las consultas perdidas; si no lo exige, los bots pasan libremente.

Hay otros dos casos que es fácil pasar por alto. Con reCAPTCHA v3, el distintivo de la esquina solo muestra que el script está cargado en algún lugar de la página (quizá por el tema o por otro plugin), mientras que la integración en el propio plugin de formularios está desactivada. Y 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 durante unos minutos y solo pueden verificarse una vez, por lo que un token en caché falla para los visitantes reales; la tentadora «solución» de desactivar la comprobación elimina discretamente la protección.

Una breve autocomprobación

1. 1Abra la página del formulario en una ventana privada, abra las herramientas de desarrollo del navegador y busque en la consola errores del script del CAPTCHA.
2. 2Compruebe que el widget aparece realmente (una vez antes y otra después de aceptar el banner de cookies) y que el formulario no puede enviarse mientras falta.
3. 3En la consola de administración del proveedor, compruebe que la clave de sitio incluye su dominio en producción (con variantes como www) y que las claves de su plugin de formularios o de su código coinciden con ella, y no son claves de la documentación o de un entorno de staging.
4. 4En los ajustes del plugin de formularios, asegúrese de que la integración del CAPTCHA está activada para este formulario concreto; en reCAPTCHA v3, compruebe que el umbral de puntuación es superior a 0.
5. 5Si tiene acceso al código, localice la verificación en el servidor y compruebe que rechaza el envío cuando la respuesta es negativa o falta el token.
6. 6Excluya la página del formulario de la caché de página completa o asegúrese de que el token se crea de nuevo en el navegador.
7. 7Envíe un mensaje de prueba real y compruebe que llega; repita la comprobación tras cambios en el tema, los plugins o la herramienta de consentimiento.

Un CAPTCHA es una capa, no toda la protección. Combinado con un campo honeypot, una comprobación de tiempo y un filtrado en el servidor, una configuración errónea en un punto no deja el formulario completamente abierto. Si desea hacerse una idea rápida de la situación de sus formularios, introduzca su dominio en formexposed.com: el informe muestra si las partes de su configuración de CAPTCHA visibles desde fuera están en orden.