Secção 1: Por que os bots atacam os widgets de prova virtual
Os widgets de prova virtual são um alvo atraente para bots porque fornecem geração gratuita de imagens por IA. Um endpoint de prova virtual aceita uma foto e uma imagem de produto e devolve um resultado composto por IA — do ponto de vista de um bot, esta é uma API de geração de imagens por IA gratuita e acessível ao público. Scripts automatizados podem atingir o endpoint milhares de vezes por hora para gerar imagens de produtos, fotos de perfil ou dados de treino sintéticos com custo zero para o atacante e custo total do limite mensal para si, o comerciante.
O incentivo económico é significativo: uma API de geração de imagens por IA de qualidade custa normalmente entre 0,05 $ e 0,20 $ por imagem. Um endpoint de widget de prova sem proteção contra bots está efetivamente a oferecer este serviço gratuitamente a qualquer pessoa que faça engenharia reversa do formato do pedido. À escala, uma única campanha de bots pode esgotar toda a quota mensal de provas de um comerciante em poucas horas, deixando os compradores reais com um serviço degradado durante o resto do período de faturação.
Secção 2: A stack de defesa de cinco camadas do Photta
O Photta implementa cinco defesas independentes, cada uma capturando um vetor de ataque diferente. Camada 1 — hCaptcha: cada pedido de prova deve incluir um token hCaptcha válido gerado no navegador. Bots headless e clientes HTTP automatizados não conseguem resolver o hCaptcha sem interação humana, bloqueando ataques simples por script. Camada 2 — fingerprinting BotD: o SDK executa o BotScore da FingerprintJS para detetar navegadores headless, frameworks de automação (Puppeteer, Playwright) e ambientes de navegação suspeitos antes mesmo de o comprador enviar uma foto.
Camada 3 — Lista de permissões de domínios: a sua chave pk_live_ apenas aceita pedidos de domínios que registar em Definições → Domínios Permitidos. Pedidos de qualquer outra origem devolvem HTTP 403 imediatamente, antes de ocorrer qualquer processamento de IA. Camada 4 — Limitação de taxa de IP: mais de 10 pedidos de prova por minuto a partir de um único endereço IP acionam a limitação automática; mais de 30 por minuto acionam um bloqueio temporário. Camada 5 — Limite mensal: o limite mensal de provas do seu plano (500/2.000/10.000 dependendo do nível) é limitado rigidamente no lado do servidor. Esgotar o limite interrompe todas as provas durante o resto do ciclo de faturação, evitando cenários de custos descontrolados.
Secção 3: Monitorizar tentativas de bots no seu painel
Inicie sessão no business.photta.app e navegue até Segurança. O painel de Segurança mostra três gráficos atualizados em tempo real: Tentativas Bloqueadas (total por hora), Distribuição de Motivos de Bloqueio (falhas hCaptcha vs. deteções BotD vs. incompatibilidades de domínio vs. gatilhos de limite de taxa) e Principais IPs Bloqueados (os endereços IP que geraram mais pedidos bloqueados nas últimas 24 horas). Uma loja saudável mostra normalmente quase zero tentativas bloqueadas durante as horas normais de funcionamento.
O painel de Segurança inclui também uma secção de Alertas de Anomalias. A camada analítica do Photta monitoriza picos súbitos no volume de provas ou tentativas bloqueadas que se desviem mais de três desvios padrão da sua linha de base de 7 dias. Quando uma anomalia é detetada, recebe uma notificação por e-mail em 15 minutos e o alerta aparece no painel. Pode configurar os limites de notificação em Definições → Notificações → Alertas de Segurança.
Secção 4: Responder a atividades suspeitas
Quando vir padrões invulgares no painel de Segurança — um pico em pedidos bloqueados, um conjunto de tentativas de uma gama de IPs ou uma queda súbita na sua quota mensal — tome estas medidas por ordem. Primeiro, verifique a lista de Principais IPs Bloqueados. Se um ou um pequeno número de IPs for responsável pela maioria das tentativas bloqueadas, clique em 'Bloquear IP' ao lado de cada um para bani-los permanentemente na camada Photta. Os bloqueios aplicam-se imediatamente e persistem até que os remova manualmente.
Segundo, se o ataque estiver a usar vários IPs (uma botnet distribuída), contacte o suporte do Photta através do chat do painel com o seu ID de comerciante e o intervalo de tempo do ataque. A equipa de segurança do Photta pode aplicar um bloqueio ao nível do CIDR na sub-rede atacante em poucas horas. Terceiro, se a sua quota mensal tiver sido significativamente reduzida por atividade de bots, abra um ticket de suporte — o Photta oferece a restauração da quota por uma única vez para ataques de bots documentados. Anexe uma captura de ecrã do alerta de anomalia do seu painel de Segurança como prova.
Secção 5: Quando adicionar um CAPTCHA personalizado
O hCaptcha integrado do Photta funciona de forma invisível — a maioria dos compradores legítimos nunca vê um desafio CAPTCHA. Em casos muito raros (lojas de alto valor, endpoints de widgets indexados publicamente), as defesas integradas podem não ser suficientes se um atacante sofisticado estiver a utilizar quintas de resolução humana de CAPTCHA. Neste cenário, adicione uma segunda camada de CAPTCHA ao nível da sua própria página de produto antes de chamar photta.open(). Verifique o seu CAPTCHA personalizado no seu servidor e, em seguida, passe um token de verificação assinado para o SDK do Photta como photta.open({ verificationToken: 'o_seu_token' }) para garantir que apenas sessões verificadas podem iniciar uma prova.
O CAPTCHA personalizado é o último recurso para lojas que sofreram ataques sofisticados repetidos. Para a grande maioria dos comerciantes, a stack de cinco camadas do Photta fornece proteção suficiente sem qualquer atrito visível para o comprador. Se estiver a avaliar se deve adicionar uma camada personalizada, verifique primeiro a Distribuição de Motivos de Bloqueio no seu painel de Segurança — se as falhas hCaptcha representarem menos de 1% do total de tentativas bloqueadas, a stack está a funcionar e uma camada adicional apenas adiciona atrito sem ganho de segurança significativo.