Como proteger um formulário público numa aplicação autoalojada contra spam

Comece pelo objetivo do formulário e pelos abusos prováveis

A proteção adequada depende da função do formulário. Um formulário de contacto, um inquérito a clientes, um formulário de criação de conta e um pedido de orçamento têm consequências diferentes quando são alvo de abuso — e custos diferentes quando uma submissão real é rejeitada.

Identifique quem utiliza o formulário, que informações recolhe, onde chegam as submissões e o que acontece depois. Se uma submissão enviar um e-mail, criar um registo num CRM ou iniciar outro fluxo de trabalho, o abuso pode afetar esses sistemas também.

• Considere os utilizadores legítimos, incluindo pessoas que utilizam tecnologias de apoio ou dispositivos com os quais não estão familiarizadas.
• Assinale os campos essenciais e evite recolher informações que não contribuam para o objetivo do formulário.
• Registe os abusos prováveis, como mensagens indesejadas, submissões repetidas, texto sem sentido, dados de contacto inválidos ou tentativas de desencadear ações subsequentes.
• Compare o impacto do spam com o de rejeitar uma submissão legítima.

Verifique o que a aplicação protege — e o que não protege

Comece pela documentação oficial da aplicação e da versão que utiliza. Procure controlos documentados, como CAPTCHA, revisão de submissões, validação de campos ou restrições a determinados domínios de e-mail. Não parta do princípio de que uma opção existe só porque outro produto a oferece.

Distinga os controlos da aplicação das proteções da infraestrutura envolvente. Confirme onde as submissões são validadas e onde o tráfego abusivo pode ser limitado: um controlo numa camada não significa que todas as camadas estejam protegidas.

As [orientações da HubSpot sobre prevenção de spam em submissões de formulários](https://knowledge.hubspot.com/forms/prevent-spam-form-submissions) documentam o CAPTCHA e o bloqueio de domínios de e-mail específicos ou de fornecedores de e-mail gratuitos como opções. Referem também o reCAPTCHA e a deteção de texto sem sentido para determinados comportamentos ou tipos de spam. São exemplos, não uma garantia de que a sua aplicação disponibilize os mesmos controlos.

• Consulte a documentação oficial da aplicação para a versão e configuração implementadas.
• Determine se a validação ocorre no servidor e no navegador; não trate as verificações feitas apenas no navegador como uma barreira de segurança.
• Verifique se a infraestrutura disponibiliza limites de pedidos ou outros controlos relevantes e se estes abrangem o ponto de acesso do formulário.
• Registe os controlos ativados, onde funcionam e quem é responsável por os rever.

Crie um conjunto proporcional de controlos

Não atribua a um único filtro a responsabilidade de impedir todos os tipos de abuso. Um ponto de partida é validar no servidor os campos e formatos esperados e combinar essa validação com um limite moderado para submissões repetidas, quando a aplicação ou a infraestrutura o permitirem. As regras devem corresponder ao objetivo do formulário, sem pressupor que todas as pessoas legítimas escrevem da mesma forma.

Use indicadores de abuso quando ajudarem a tomar uma decisão. Tentativas repetidas, padrões de campos implausíveis ou conteúdo que não corresponda ao propósito do formulário podem justificar uma revisão ou verificação adicional. Um indicador isolado, como uma rede partilhada ou um nome invulgar, não prova que há abuso.

Proteja também as ações subsequentes. Se o formulário enviar uma resposta automática, não inclua automaticamente nessa mensagem o texto submetido pelo público. A [Postmark alerta para o risco de um formulário desprotegido ser usado para enviar spam através de respostas automáticas que incluem conteúdo fornecido pelos utilizadores](https://postmarkapp.com/blog/when-spambots-attack-protecting-your-forms-from-abuse).

• Torne obrigatórios os campos essenciais e valide-os no servidor; explique como corrigir dados inválidos.
• Ajuste os limites de pedidos à utilização legítima e tenha em conta que várias pessoas podem partilhar a mesma rede.
• Reveja o que desencadeia e-mails, registos ou outras ações automatizadas.
• Quando o custo de um falso positivo for elevado, encaminhe as submissões incertas para revisão ou verificação, em vez de as descartar silenciosamente.

Escolha CAPTCHA, campos honeypot e verificação a pensar nos utilizadores

O CAPTCHA pode criar uma barreira para algumas submissões automatizadas, mas também exige mais esforço aos utilizadores legítimos. Avalie se o desafio é acessível, funciona em dispositivos móveis e disponibiliza uma alternativa utilizável. Consulte as informações de privacidade do fornecedor antes de enviar dados ou sinais de interação dos visitantes a terceiros.

Um campo honeypot destina-se a ficar oculto para os utilizadores comuns, mas alguns preenchimentos automatizados de formulários podem detetá-lo. A [Postmark descreve o honeypot como um complemento à proteção do formulário](https://postmarkapp.com/blog/when-spambots-attack-protecting-your-forms-from-abuse), não como uma defesa completa. Teste-o com o tema, os scripts, o preenchimento automático do navegador e as tecnologias de apoio.

A verificação por e-mail ou por outros meios pode justificar-se quando o objetivo do formulário compensa a etapa adicional; pode ser excessiva para um simples pedido de contacto. Se restringir fornecedores ou domínios de e-mail, considere quem poderá ficar excluído.

• Compare cada opção em função da redução provável do abuso, do atrito, da acessibilidade, da privacidade e da manutenção.
• Adicione um controlo quando conseguir explicar que problema resolve; não combine vários desafios por predefinição.
• Teste a navegação por teclado, as tecnologias de apoio, a utilização em dispositivos móveis e o preenchimento automático.
• Disponibilize uma alternativa para quem não consiga concluir o desafio.

Prepare a revisão e a recuperação de submissões

Qualquer filtro pode rejeitar uma submissão real. A [Postmark alerta para o facto de uma filtragem agressiva poder bloquear utilizadores legítimos](https://postmarkapp.com/blog/when-spambots-attack-protecting-your-forms-from-abuse). Antes de ativar uma regra rigorosa, decida como vai identificar erros e ajudar os visitantes a resolvê-los.

Explique ao utilizador o que fazer se uma submissão for rejeitada ou exigir outra etapa, sem revelar detalhes internos de segurança. Se o formulário for importante, mantenha uma forma alternativa de contacto e certifique-se de que alguém a verifica.

Conserve apenas as informações necessárias para investigar problemas. Defina quem pode aceder às submissões e durante quanto tempo são guardadas, de acordo com os seus requisitos de dados e governação.

• Se a configuração o permitir, identifique as submissões rejeitadas ou colocadas em quarentena.
• Reveja as regras de bloqueio de domínios e de conteúdo para detetar exclusões involuntárias.
• Defina quem analisa os casos suspeitos de falso positivo e em quanto tempo deve agir.

Monitorize padrões e reveja as definições

Um controlo adequado para um formulário pode deixar de o ser quando o formulário ganha visibilidade ou muda de finalidade. Reveja os padrões de submissão e os relatos dos utilizadores; volte a avaliar os controlos quando mudarem o volume, o público, os dados recolhidos ou as ações subsequentes.

Procure tendências, em vez de tratar uma submissão invulgar isolada como prova. Um aumento de entradas indesejadas repetidas pode justificar um ajuste específico; relatos de utilizadores que não conseguem submeter o formulário podem indicar que é preciso rever uma regra. Registe as alterações para perceber se ajudaram.

• Acompanhe, quando possível, o número de submissões aceites, rejeitadas e analisadas.
• Investigue relatos de submissões em falta e confirme se foram filtradas ou se não chegaram a ser recebidas.
• Reveja as definições após alterações ao formulário, à aplicação, ao público ou às ações desencadeadas por uma submissão.
• Volte a verificar os avisos de privacidade, o acesso aos dados e as opções de conservação à medida que o formulário evolui.

Lista de verificação antes do lançamento

Teste todo o percurso da submissão, desde o formulário até ao local onde a equipa recebe ou analisa as entradas. Inclua casos que representem utilizadores legítimos e os padrões de abuso que pretende reduzir. Confirme que as rejeições são explicadas e que as submissões aceites chegam ao destino pretendido.

O alojamento pode tratar de partes da infraestrutura sem assumir as decisões sobre os dados do formulário, o acesso ou a moderação. Por exemplo, a Airbip disponibiliza a implementação gerida de aplicações empresariais como cargas de trabalho Docker nos seus servidores na nuvem, com encaminhamento e certificados TLS automatizados através do Traefik e do Let’s Encrypt. Estas capacidades de alojamento não demonstram que uma determinada aplicação tenha controlos contra spam; consulte a documentação da aplicação e decida como gerir as submissões.

• Submeta exemplos válidos que representem diferentes utilizadores, dispositivos e estilos de escrita.
• Teste campos em falta, formatos inválidos, tentativas repetidas e os padrões de abuso que identificou.
• Verifique a navegação por teclado, as tecnologias de apoio, a utilização em dispositivos móveis, as alternativas aos desafios e a mensagem de confirmação.
• Confirme que as submissões, as entradas rejeitadas e as respostas automáticas funcionam como esperado.
• Registe os controlos, os resultados dos testes, a pessoa responsável pela revisão e o processo de recuperação.