Muchas implementaciones de CAPTCHA comparten la IP del cliente, la huella del navegador, el conjunto de cabeceras y la telemetría de comportamiento con servicios de terceros en el momento de la verificación. Ese modelo es aceptable en algunos sectores, pero en entornos del sector público, financiero, sanitario y con air-gap crea una exposición seria en términos de residencia de datos y cumplimiento normativo.
Para organizaciones sensibles al cumplimiento, incluso una sola llamada CAPTCHA en una pantalla de inicio de sesión puede desencadenar un debate sobre transferencia de datos personales. Los requisitos de consentimiento explícito, las normas de transferencia transfronteriza, las salvaguardas contractuales y la dependencia del proveedor pueden convertir una simple decisión de protección anti-bots en un largo proyecto de cumplimiento.
Depender de servicios CAPTCHA externos también genera riesgo operacional. Cuando un servicio de verificación de terceros se ralentiza o queda inaccesible, el flujo de inicio de sesión, registro o pago de cada aplicación protegida se ve afectado. La protección anti-bots se convierte en una dependencia externa crítica para la aplicación.
El modelo correcto es realizar la generación, entrega y verificación del desafío dentro de la propia capa ADC de la organización. Los datos del cliente permanecen locales, el proceso de verificación es autocontenido, la dificultad escala con el riesgo del servicio y los intentos fallidos pueden alimentar la escalada a cuarentena.
TR7 CAPTCHA Auto-Alojado ofrece exactamente este modelo: hace que la verificación de bots sea auto-alojada, reduce el riesgo de residencia de datos y se integra directamente con el pipeline de decisiones WAAP.
TR7 implementa CAPTCHA mediante generación local, dificultad ajustable, modos de verificación visible e invisible, y escalada a cuarentena.
La imagen CAPTCHA, el contenido HTML/JS, la firma del token y la verificación de la solución se ejecutan en TR7. No se realiza ninguna llamada HTTP saliente a un servicio externo durante el proceso de verificación.
La dificultad se evalúa junto con la longitud de caracteres, el ruido visual, la carga de trabajo PoW y el tiempo mínimo de resolución. El operador establece el equilibrio correcto entre experiencia de usuario y resistencia a bots con un único ajuste.
La verificación visual puede mostrarse a clientes de alto riesgo. Para clientes de riesgo medio, la validación PoW puede ejecutarse silenciosamente en segundo plano sin presentar una pantalla adicional al usuario.
El CAPTCHA se activa solo cuando se supera un umbral de riesgo. Las respuestas incorrectas se rastrean; una vez superado el umbral, se pueden aplicar acciones de cuarentena como denegar, redirigir, contenido personalizado o un código de estado personalizado.
El CAPTCHA Auto-Alojado combina la generación de desafíos auto-alojada con el scoring de bots, PoW, seguridad de cookies y flujos de cuarentena.
TR7 genera la imagen CAPTCHA internamente, sirve la página de desafío desde su propio servicio y verifica las soluciones mediante un proceso helper local. La IP del cliente, el agente de usuario y el resultado de la verificación nunca se envían a un servicio externo. Este modelo proporciona una ventaja crítica para organizaciones con requisitos de residencia de datos. La protección CAPTCHA se aplica sin ninguna dependencia de servicios externos.
En TR7, la dificultad se selecciona en una escala del 1 al 5. Este valor se corresponde con la profundidad de bits PoW (16–20 bits), la longitud de caracteres CAPTCHA (4–7 caracteres), la densidad de líneas y puntos visuales, y un tiempo mínimo de resolución aplicado por el servidor. El operador gestiona tanto la experiencia humana como el coste para bots con un único slider. Los servicios de mayor riesgo pueden configurarse con mayor dificultad.
La validación PoW se aplica como parte de la verificación CAPTCHA. El navegador debe completar un cálculo definido antes de que se acepte la solución. También se aplica un tiempo mínimo de resolución en el servidor — aunque un bot produzca la respuesta correcta al instante, una solución que llega demasiado rápido se trata como sospechosa. Este enfoque eleva el coste de la automatización mientras añade una carga mínima a los usuarios genuinos.
El token producido tras una verificación exitosa se transporta en una cookie cifrada. El token puede vincularse al contexto de la dirección IP y el agente de usuario del cliente, dificultando significativamente la reutilización de un token de verificación obtenido por un cliente en un contexto diferente. Durante la ventana verifiedTtl, el usuario genuino no tiene que resolver el CAPTCHA en cada solicitud.
TR7 puede asignar un proceso helper dedicado y una ruta de socket dedicada a cada regla CAPTCHA. Este aislamiento reduce el impacto de un fallo o pico de carga en una regla sobre otras reglas. La separación basada en pool significa que los flujos CAPTCHA para distintos servicios se gestionan de forma independiente. scalingCount permite ejecutar múltiples procesos para la misma regla.
Cuando el tipo se establece en text, el usuario se encuentra con un CAPTCHA visual. En el modo invisible, la verificación basada en PoW se ejecuta sin presentar una pantalla de desafío completa. Los clientes de riesgo medio se verifican con menos fricción, mientras que los de mayor riesgo reciben CAPTCHA visual para aumentar el coste para bots.
El color de fondo, el color del texto, el tema y el tamaño pueden definirse por servicio. Los tamaños de CAPTCHA pequeño, mediano y grande se adaptan a distintas interfaces de usuario. La pantalla de verificación no parece desconectada de la experiencia de marca de la organización. En escenarios B2B SaaS de marca blanca, cada tenant puede ofrecer una experiencia que se ajuste a su propia identidad visual.
Los títulos de CAPTCHA, el texto descriptivo y los mensajes de error pueden vincularse a una estructura multilingüe. El idioma puede seleccionarse por servicio o según el contexto del cliente. Esto proporciona un flujo de verificación más claro en servicios del sector público, financiero y multirregionales. Añadir un nuevo idioma no requiere cambiar la lógica de verificación.
No es necesario mostrar el CAPTCHA a todos los usuarios por defecto. El scoring de bots, la reputación de IP, las señales de comportamiento y las condiciones DDoS de TR7 pueden restringir la presentación del desafío únicamente a clientes de riesgo. Esto reduce la fricción para los usuarios genuinos. El tráfico de confianza continúa por la ruta normal mientras el tráfico sospechoso se enruta hacia la verificación.
Las respuestas CAPTCHA incorrectas pueden rastrearse, y una vez superado el umbral definido el cliente queda en cuarentena. La acción de cuarentena puede configurarse como deny, redirect, customContent o customStatusCode. Esto evita que los bots consuman desafíos de forma continua para agotar el sistema. A medida que aumentan los fallos, una acción más contundente reemplaza al desafío.
Cuando un usuario supera el CAPTCHA con éxito, puede considerarse verificado durante un período configurado. Al mismo usuario no se le muestra CAPTCHA de nuevo hasta que expire verifiedTtl. Esto preserva la experiencia del usuario genuino mientras mantiene la barrera de verificación inicial contra los bots. El enlace IP+UA dificulta que el estado de verificación sea robado y reproducido en un contexto diferente.
El CAPTCHA no es una pantalla independiente — es una de las acciones en el pipeline de decisiones de TR7. La protección DDoS, la protección anti-bots, la reputación de IP y las políticas de account takeover pueden todas activar la acción showCaptcha. Cada módulo de seguridad puede conectar su propia señal de riesgo al flujo de verificación CAPTCHA. El operador utiliza una única infraestructura de desafío auto-alojada en diferentes escenarios de riesgo.
El CAPTCHA auto-alojado se opera junto con procesos helper, gestión de secretos, enlace de tokens, una máquina de estados de cuarentena, soporte multilingüe y registros de auditoría.
Cada regla CAPTCHA puede ejecutarse con un proceso helper dedicado. Si el proceso termina inesperadamente, puede reiniciarse automáticamente. Un fallo en una regla no afecta a la verificación CAPTCHA en otros servicios.
Puede crearse una ruta de socket dedicada para cada pool y regla CAPTCHA. Esta estructura separa el tráfico de verificación de desafíos entre servicios. Cuando la configuración se reproduce, se preserva la correspondencia entre la misma regla lógica y la misma estructura de socket físico.
Puede generarse un secreto distinto para cada regla, y los tokens de verificación se firman con ese secreto. Cuando se rota un secreto, los tokens verificados existentes pueden invalidarse. Este comportamiento puede aprovecharse para renovaciones de seguridad planificadas.
La resolución PoW puede utilizar APIs más eficientes en navegadores modernos. En entornos sin soporte, se aplica un fallback JavaScript más lento pero compatible. En clientes móviles, el proceso de resolución se ejecuta de forma asíncrona para que la interfaz de usuario no se bloquee.
Las respuestas fallidas a desafíos se rastrean por separado. Cuando se supera el umbral, el cliente se dirige a una acción de cuarentena durante un período configurado. Durante ese período, se aplica directamente deny, redirect o contenido personalizado en lugar de presentar otro CAPTCHA.
Para cada desafío, pueden registrarse la marca de tiempo, la IP de origen, el agente de usuario, el ID de regla, el nivel de dificultad, el tipo de desafío y el resultado. El tiempo de resolución PoW también produce una señal valiosa para la investigación de incidentes. Estos registros apoyan los flujos de análisis de bots y forensia de fraude.
Los bancos pueden verse obligados a evitar transmitir la IP del usuario o la información del navegador a servicios externos durante la verificación CAPTCHA. Con TR7 CAPTCHA Auto-Alojado, el proceso de desafío permanece dentro del ADC y la protección del inicio de sesión opera en línea con los requisitos de residencia de datos.
Los organismos gubernamentales que operan en entornos sin acceso a servicios de verificación externos pueden igualmente aplicar protección anti-bots. La generación y verificación de CAPTCHA de TR7 funcionan sin requerir resolución DNS externa ni llamadas HTTP salientes.
Para fraude de cupones, creación de cuentas falsas o ataques de registro automatizado, el endpoint de registro puede colocarse tras CAPTCHA basándose en la puntuación de bots. Los intentos fallidos se vinculan a cuarentena, impidiendo que los bots consuman desafíos de forma continua.
Los portales sanitarios pueden verificar a los usuarios en flujos de reserva de citas o acceso a pacientes que involucran datos sensibles sin depender de un servicio CAPTCHA externo. El proceso de verificación del usuario permanece bajo control organizacional.
Durante una oleada DDoS o de bots, TR7 puede aplicar CAPTCHA o PoW invisible solo a los clientes con una puntuación de riesgo elevada. La mayoría de los usuarios genuinos continúan sin fricción adicional mientras se eleva el coste para los bots.
Los proveedores B2B SaaS pueden configurar los ajustes de color, tema y tamaño por separado para cada tenant. La pantalla CAPTCHA no lleva ningún logotipo de terceros y se aproxima más a la experiencia del usuario propio del cliente.
CAPTCHA auto-alojado que mantiene los datos en local — integrado con los flujos WAAP, DDoS y ATO. Recorramos juntos una configuración en vivo en su propio entorno.