Como blindar formulários públicos contra bots com Turnstile

O problema: formulários públicos sem proteção

A autora, que lidera produto no DraftKit, conta que a plataforma oferece a cada criador uma página pública de agendamento (draftkit.app/[usuário]) em que qualquer pessoa pode enviar uma solicitação de colaboração sem login. Três semanas após o lançamento, uma criadora reportou pedidos suspeitos na sua fila. Ao inspecionar a tabela collab_requests, a autora encontrou seis envios de endereços terminados em .ru, quatro com texto de preenchimento no campo de mensagem e um que usava test123 como URL de Substack. O sinal decisivo: nenhum havia passado pela etapa de SMART Match AI, indicando que o bot pulou a parte do formulário que depende de JavaScript. Verificações em outras duas páginas de agendamento ativas revelaram mais duas submissões suspeitas. A conclusão da autora: ela havia lançado um formulário público sem qualquer proteção contra bots, e só descobriu por reclamação de usuária.

Por que a lacuna existe

Segundo a autora, ferramentas de construção com IA como o Lovable criam o caminho feliz do formulário - o componente React, a validação de e-mail e a inserção no banco - mas não adicionam proteção contra bots, porque não modelam o risco de o formulário ser indexado por rastreadores de spam. O Cloudflare Radar de 2025 mostra que bots já geram a maioria do tráfego HTML na rede da empresa, com participação crescente a cada trimestre. A autora observa que os produtos que audita lidam com isso de duas maneiras: proteção adicionada antes do lançamento (raro) ou após a primeira reclamação de cliente (quase sempre). O custo de correção é o mesmo, mas o dano à confiança só ocorre no segundo cenário. Ela enfatiza que a falha não é da ferramenta de IA: modelar a ameaça é responsabilidade de quem constrói o produto.

O sistema de proteção em duas camadas

A autora descreve a abordagem que implementou:

• Cloudflare Turnstile em todo formulário público antes do lançamento: gratuito até um milhão de solicitações mensais, invisível para usuários reais e exige apenas uma tag de script e um campo oculto de resposta.
• Verificação do token no servidor: a checagem apenas no cliente é contornada por qualquer bot que gere uma string de token com aparência válida. A verificação precisa acontecer na edge function do Supabase, contra o endpoint siteverify do Cloudflare - etapa que a maioria das primeiras implementações pula e a única que confirma que o token é real.
• Segunda camada no banco de dados: gatilhos (triggers) rodam independentemente de como a linha chega, inclusive chamadas diretas à API que ignoram a edge function. O gatilho validate_requester_substack_url() do DraftKit rejeita envios com URL que não seja de publicação.
• Registro de falhas: quando a verificação do Turnstile falha, gravar IP, timestamp e página de agendamento alvo na tabela analytics_events, útil quando uma campanha de bots mira uma criadora específica.
• Auditoria de endpoints públicos: listar toda rota sem autenticação e, se ela aceitar entrada do usuário que chegue ao banco, aplicar Turnstile antes do domínio ir ao ar.

Conclusão

A tese central é que qualquer produto com formulário público - especialmente os construídos com ferramentas de IA - provavelmente tem a mesma lacuna, e a proteção deve ser implementada antes do lançamento: adicionar Turnstile leva cerca de 30 minutos e não custa abaixo de um milhão de solicitações mensais, enquanto remediar após exposição pública custa mais que o tempo de desenvolvimento.