Muitas implementações de CAPTCHA compartilham o IP do cliente, fingerprint do navegador, conjunto de headers e telemetria comportamental com serviços de terceiros no momento da verificação. Esse modelo é aceitável em alguns setores, mas para ambientes de setor público, financeiro, de saúde e redes isoladas cria séria exposição de residência de dados e conformidade.
Para organizações sensíveis à conformidade, até mesmo uma única chamada de CAPTCHA em uma tela de login pode desencadear uma discussão sobre transferência de dados pessoais. Requisitos de consentimento explícito, regras de transferência transfronteiriça, salvaguardas contratuais e dependência de fornecedor podem transformar uma simples decisão de proteção de bots em um longo projeto de conformidade.
Depender de serviços externos de CAPTCHA também cria risco operacional. Quando um serviço de verificação de terceiros fica lento ou inacessível, o fluxo de login, registro ou pagamento de cada aplicação protegida é afetado. A proteção de bots torna-se uma dependência externa crítica para a aplicação.
O modelo correto é realizar a geração, entrega e verificação do desafio dentro da própria camada ADC da organização. Os dados do cliente ficam locais, o processo de verificação é autocontido, a dificuldade escala com o risco do serviço e as tentativas falhas podem alimentar a escalação de quarentena.
O TR7 Self-Hosted CAPTCHA oferece exatamente esse modelo: torna a verificação de bots self-hosted, reduz o risco de residência de dados e integra-se diretamente ao pipeline de decisão do WAAP.
TR7 implementa o CAPTCHA por meio de geração local, dificuldade ajustável, modos de verificação visível e invisível, e escalação de quarentena.
A imagem de CAPTCHA, o conteúdo HTML/JS, a assinatura do token e a verificação da solução rodam no TR7. Nenhuma chamada HTTP externa a um serviço externo é feita durante o processo de verificação.
A dificuldade é avaliada junto com comprimento do caractere, ruído visual, carga de trabalho PoW e tempo mínimo de resolução. O operador encontra o equilíbrio correto entre experiência do usuário e resistência a bots com um único ajuste.
A verificação visual pode ser exibida para clientes de alto risco. Para clientes de risco médio, a validação PoW pode rodar silenciosamente em segundo plano sem apresentar uma tela adicional ao usuário.
O CAPTCHA é acionado apenas quando um limiar de risco é ultrapassado. Respostas erradas são rastreadas; ao ultrapassar o limiar, ações de quarentena como negação, redirecionamento, conteúdo personalizado ou código de status personalizado podem ser aplicadas.
O Self-Hosted CAPTCHA combina geração de desafio self-hosted com pontuação de bots, PoW, segurança de cookies e fluxos de quarentena.
O TR7 gera a imagem de CAPTCHA internamente, serve a página de desafio a partir de seu próprio serviço e verifica as soluções por meio de um processo auxiliar local. O IP do cliente, user agent e resultado da verificação nunca são enviados a um serviço externo. Esse modelo oferece uma vantagem crítica para organizações com requisitos de residência de dados. A proteção por CAPTCHA é aplicada sem qualquer dependência de serviços externos.
No TR7, a dificuldade é selecionada em uma escala de 1 a 5. Esse valor mapeia para profundidade de bits do PoW (16 a 20 bits), comprimento de caracteres do CAPTCHA (4 a 7 caracteres), densidade de linhas e pontos visuais, e um tempo mínimo de resolução imposto pelo servidor. O operador gerencia tanto a experiência humana quanto o custo para bots com um único controle. Serviços de maior risco podem ser configurados com maior dificuldade.
A validação PoW é aplicada como parte da verificação do CAPTCHA. O navegador deve completar um cálculo definido antes que a solução seja aceita. Um tempo mínimo de resolução imposto pelo servidor também é aplicado — mesmo que um bot produza a resposta correta instantaneamente, uma solução que chega rápido demais é tratada como suspeita. Essa abordagem aumenta o custo da automação enquanto adiciona carga mínima para usuários genuínos.
O token produzido após verificação bem-sucedida é carregado em um cookie criptografado. O token pode ser vinculado ao endereço IP e ao contexto de user agent do cliente, tornando significativamente mais difícil reutilizar um token de verificação obtido por um cliente em um contexto diferente. Durante a janela verifiedTtl, o usuário genuíno não precisa resolver o CAPTCHA em cada requisição.
O TR7 pode atribuir um processo auxiliar dedicado e um caminho de socket dedicado a cada regra de CAPTCHA. Esse isolamento reduz o impacto de uma falha ou pico de carga em uma regra sobre outras regras. A separação baseada em pool significa que os fluxos de CAPTCHA para diferentes serviços são gerenciados de forma independente. scalingCount permite que múltiplos processos rodem para a mesma regra.
Quando o tipo é definido como texto, o usuário encontra um CAPTCHA visual. No modo invisível, a verificação baseada em PoW roda sem apresentar uma tela de desafio completa. Clientes de risco médio são verificados com menos atrito, enquanto clientes de maior risco recebem CAPTCHA visual para aumentar o custo para bots.
Cor de fundo, cor do texto, tema e tamanho podem ser definidos por serviço. Tamanhos de CAPTCHA pequeno, médio e grande se adaptam a diferentes interfaces de usuário. A tela de verificação não aparece desconectada da experiência de marca da organização. Em cenários de SaaS B2B white-label, cada tenant pode oferecer uma experiência que corresponde à sua própria identidade visual.
Títulos de CAPTCHA, texto de descrição e mensagens de erro podem ser vinculados a uma estrutura multilíngue. O idioma pode ser selecionado por serviço ou com base no contexto do cliente. Isso fornece um fluxo de verificação mais claro em serviços de setor público, financeiro e multirregionais. Adicionar um novo idioma não requer alterar a lógica de verificação.
O CAPTCHA não precisa ser exibido para todos os usuários por padrão. A pontuação de bots do TR7, reputação de IP, sinais comportamentais e condições DDoS podem restringir a apresentação do desafio apenas a clientes de risco. Isso reduz o atrito para usuários genuínos. O tráfego confiável continua no caminho normal enquanto o tráfego suspeito é direcionado à verificação.
Respostas erradas de CAPTCHA podem ser rastreadas e, ao ultrapassar um limiar definido, o cliente é colocado em quarentena. A ação de quarentena pode ser configurada como negação, redirecionamento, customContent ou customStatusCode. Isso impede que bots consumam desafios repetidamente para exaurir o sistema. À medida que as falhas se acumulam, uma ação mais severa substitui o desafio.
Quando um usuário passa no CAPTCHA com sucesso, ele pode ser tratado como verificado por um período configurado. O mesmo usuário não recebe o CAPTCHA novamente até que verifiedTtl expire. Isso preserva a experiência do usuário genuíno enquanto mantém a barreira de verificação inicial contra bots. A vinculação de IP+UA torna mais difícil roubar e reproduzir o estado de verificação em um contexto diferente.
O CAPTCHA não é uma tela independente — é uma das ações no pipeline de decisão do TR7. Proteção DDoS, proteção de bots, reputação de IP e políticas de account takeover podem acionar a ação showCaptcha. Cada módulo de segurança pode conectar seu próprio sinal de risco ao fluxo de verificação CAPTCHA. O operador utiliza uma única infraestrutura de desafio self-hosted em diferentes cenários de risco.
O CAPTCHA self-hosted é operado em conjunto com processos auxiliares, gerenciamento de segredos, vinculação de token, máquina de estados de quarentena, suporte multilíngue e registros de auditoria.
Cada regra de CAPTCHA pode rodar com um processo auxiliar dedicado. Se o processo terminar inesperadamente, pode ser reiniciado automaticamente. Uma falha em uma regra não afeta a verificação de CAPTCHA em outros serviços.
Um caminho de socket dedicado pode ser criado para cada pool e regra de CAPTCHA. Essa estrutura separa o tráfego de verificação de desafio entre serviços. Quando a configuração é reproduzida, o mapeamento entre a mesma regra lógica e a mesma estrutura de socket físico é preservado.
Um segredo distinto pode ser gerado para cada regra, e os tokens de verificação são assinados contra esse segredo. Quando um segredo é rotacionado, os tokens verificados existentes podem ser invalidados. Esse comportamento pode ser aproveitado para renovações de segurança planejadas.
A resolução PoW pode usar APIs mais eficientes em navegadores modernos. Em ambientes sem suporte, um fallback JavaScript mais lento, mas compatível, é aplicado. Em clientes móveis, o processo de resolução roda de forma assíncrona para que a interface do usuário não congele.
As respostas de desafio com falha são rastreadas separadamente. Ao ultrapassar o limiar, o cliente é direcionado a uma ação de quarentena por um período configurado. Durante esse período, a negação, o redirecionamento ou conteúdo personalizado é aplicado diretamente em vez de apresentar outro CAPTCHA.
Para cada desafio, timestamp, IP de origem, user agent, ID da regra, nível de dificuldade, tipo de desafio e resultado podem ser registrados. O tempo de resolução PoW também produz um sinal valioso para investigação de incidentes. Esses registros suportam fluxos de trabalho de análise de bots e forense de fraudes.
Bancos podem ser obrigados a evitar transmitir IP do usuário ou informações do navegador a serviços externos durante a verificação de CAPTCHA. Com o CAPTCHA self-hosted do TR7, o processo de desafio permanece dentro do ADC e a proteção de login é operada em conformidade com os requisitos de residência de dados.
Agências governamentais operando em ambientes sem acesso a serviços de verificação externos ainda podem aplicar proteção de bots. A geração e verificação de CAPTCHA do TR7 funcionam sem exigir resolução DNS externa ou chamadas HTTP de saída.
Para fraude de cupons, criação de contas falsas ou ataques de registro automatizado, o endpoint de inscrição pode ser colocado atrás do CAPTCHA com base na pontuação de bots. As tentativas falhas são vinculadas à quarentena, impedindo que bots consumam desafios continuamente.
Portais de saúde podem verificar usuários em fluxos de agendamento de consultas ou acesso a pacientes que envolvem dados sensíveis sem depender de um serviço CAPTCHA externo. O processo de verificação do usuário permanece sob controle organizacional.
Durante uma onda de DDoS ou bots, o TR7 pode aplicar CAPTCHA ou PoW invisível apenas a clientes com alta pontuação de risco. A maioria dos usuários genuínos continua sem atrito adicional enquanto o custo para bots é aumentado.
Provedores de SaaS B2B podem configurar cor, tema e tamanho separadamente para cada tenant. A tela de CAPTCHA não carrega logotipo de terceiros e aparece mais próxima à experiência de usuário do próprio cliente.
CAPTCHA self-hosted que mantém os dados locais — integrado com fluxos de WAAP, DDoS e ATO. Vamos percorrer uma configuração ao vivo no seu próprio ambiente.