Checklist de Segurança de Formulários

8 itens para o seu formulário público não virar porta aberta para abuso.

Essa lista não é teórica — vem de um achado real: formulários públicos sem rate limit e sem honeypot já foram identificados em produção durante uma auditoria técnica de projetos avaliados pela Alta Cloud, antes de serem corrigidos.

0 de 8 concluídos0%

Todo formulário público tem rate limiting real, aplicado no servidorPor IP ou outro identificador — não só um limite visual no navegador, que qualquer requisição direta contorna.
Existe um campo honeypot (invisível para humano) contra bot genéricoBots simples preenchem todos os campos do formulário, incluindo os que deveriam ficar vazios.
A validação de entrada acontece no servidor, não só no navegadorValidação só no navegador pode ser contornada enviando a requisição direto pela API.
HTTPS é obrigatório em toda página que tem formulário, sem exceçãoInclusive em ambiente de homologação/staging, não só em produção.
Nenhum e-mail ou dado sensível fica exposto direto no HTMLNem em atributos visíveis, nem em comentários deixados no código.
Mensagens de erro não revelam se um e-mail/usuário já existeEvita um bot descobrir, por tentativa e erro, quais e-mails já estão cadastrados na sua base.
Tentativas suspeitas ficam registradas para auditoriaSem guardar dado sensível desnecessário — só o suficiente para investigar um abuso depois.
As bibliotecas usadas no formulário (validação, envio de e-mail) são atualizadas periodicamenteDependência desatualizada é uma das portas de entrada mais comuns para vulnerabilidade conhecida.