Como proteger um formulário web (spam, injeções, RGPD)
Um formulário web mal protegido expõe a três riscos distintos: o spam automatizado que satura a caixa de correio, as injeções de código que comprometem a base de dados e o incumprimento do RGPD na recolha de dados pessoais. Estes três riscos exigem medidas diferentes e complementares; nenhuma substitui as outras.
O verdadeiro problema: um formulário é uma porta aberta para o servidor
Ao contrário de uma página de conteúdo estático, um formulário aceita uma entrada externa e transmite-a ao servidor para processamento (envio de um email, registo numa base de dados). É precisamente esta interação que o torna um alvo privilegiado: cada campo de entrada é um ponto de acesso potencial para conteúdo malicioso, seja uma simples mensagem de spam ou uma tentativa de exploração mais avançada.
Os robôs que percorrem a web não visam sites específicos: testam sistematicamente todos os formulários que encontram, à procura de uma falha explorável. Um formulário de contacto deixado sem proteção costuma receber spam poucos dias, por vezes poucas horas, após a sua publicação.
Proteger-se do spam automatizado
- Adicionar um campo honeypot: um campo invisível para um humano (oculto em CSS) mas preenchido automaticamente pelos robôs, o que permite rejeitar silenciosamente o seu envio sem gastar recursos num captcha.
- Integrar um captcha (reCAPTCHA, hCaptcha ou equivalente) nos formulários mais expostos, privilegiando as versões recentes que não impõem um teste visual sistemático aos visitantes legítimos.
- Limitar a frequência de envio a partir de um mesmo endereço IP, para bloquear envios massivos automatizados.
- Verificar o formato dos campos (email válido, número de telefone plausível) antes de aceitar o envio.
- Filtrar links e palavras-chave suspeitas no conteúdo da mensagem, técnica complementar mas nunca suficiente por si só.
Evitar injeções de código
Uma injeção ocorre quando um atacante insere código executável num campo de formulário previsto para texto simples, com o objetivo de manipular a base de dados (injeção SQL) ou de executar código no navegador de outros visitantes (injeção XSS). A defesa assenta em dois princípios não negociáveis:
- Validar e filtrar sempre os dados no servidor, nunca apenas no navegador: uma validação no navegador pode ser facilmente contornada por um atacante que não utilize o formulário tal como apresentado.
- Utilizar consultas preparadas no código que processa os dados do formulário, uma prática padrão que impede estruturalmente a injeção SQL, em vez de tentar "limpar" manualmente cada campo.
Num CMS como o WordPress, estas proteções são geralmente asseguradas pelo núcleo do software e pelos plugins de formulários reconhecidos, desde que se mantenham atualizados. Um formulário desenvolvido à medida sem estes cuidados continua a ser a configuração mais arriscada.
Cumprir o RGPD sobre os dados recolhidos
Qualquer formulário que recolha dados pessoais (nome, email, telefone) está sujeito ao RGPD, independentemente da dimensão do site. Os pontos concretos a verificar:
- O formulário só pede os dados estritamente necessários à sua finalidade (um formulário de contacto não precisa da data de nascimento).
- Uma menção clara especifica por que motivo os dados são recolhidos e quem os trata.
- Um link para a política de privacidade está acessível a partir do formulário.
- O consentimento para uma utilização secundária (uma newsletter, por exemplo) é distinto e não vem pré-assinalado.
- Os dados são conservados por um período definido e eliminados depois, salvo obrigação legal em contrário.
O que torna um formulário vulnerável na prática
- Ausência total de validação no servidor, com uma confiança excessiva depositada na validação do navegador.
- Um campo de anexo de ficheiro que aceita qualquer formato, permitindo o carregamento de scripts maliciosos disfarçados de anexo.
- Mensagens do formulário exibidas em texto simples sem escaping numa página de administração, abrindo a porta a uma injeção XSS diferida.
- Endereço de email de receção exposto em texto simples no código-fonte da página, facilitando a recolha por robôs de spam.
O que reter
- Um formulário acumula três riscos distintos (spam, injeção, RGPD), cada um exigindo uma resposta específica.
- O honeypot e o captcha reduzem o spam automatizado sem nunca o eliminarem por completo.
- A validação dos dados deve ocorrer sempre no servidor; a validação apenas no navegador pode ser contornada.
- As consultas preparadas são a proteção de referência contra injeções SQL, não a filtragem manual de cada campo.
- A conformidade com o RGPD exige recolher apenas os dados necessários, com uma finalidade clara e um prazo de conservação definido.
Perguntas frequentes
Um captcha basta para proteger um formulário do spam? Reduz significativamente o spam automatizado sem o eliminar por completo. Combinado com um honeypot e uma validação no servidor, cobre a maioria dos casos num formulário padrão.
O que é uma injeção SQL num formulário? Uma técnica em que um atacante insere código num campo para manipular a base de dados. Evita-se validando sistematicamente os dados no servidor e utilizando consultas preparadas.
O RGPD exige um consentimento explícito para cada formulário? Exige um consentimento claro e informado, com uma finalidade especificada. Isto não significa uma caixa de verificação para cada campo, mas o visitante deve saber por que motivo os seus dados são recolhidos.
É preciso encriptar os dados enviados por um formulário? O HTTPS já encripta o transporte, o que cobre o essencial para um formulário padrão. Uma encriptação adicional no armazenamento justifica-se sobretudo para dados sensíveis.
Em resumo
Proteger um formulário web exige tratar separadamente o spam, as injeções de código e a conformidade com o RGPD, em vez de contar com uma única proteção para cobrir os três. As bases (honeypot, validação no servidor, recolha mínima de dados) estão ao alcance sem necessidade de uma perícia avançada e bastam para a maioria dos formulários de contacto profissionais. A fórmula website por subscrição da VeryAppi inclui formulários seguros e conformes desde o lançamento.
Perguntas frequentes
›Um captcha basta para proteger um formulário do spam?
Um captcha reduz significativamente o spam automatizado, mas não o elimina por completo, sobretudo face a serviços baratos de resolução manual. Combinado com um campo honeypot e uma validação do lado do servidor, cobre a maioria dos casos num formulário de contacto padrão.
›O que é uma injeção SQL num formulário?
É uma técnica em que um atacante insere código num campo do formulário (em vez de uma resposta normal) para manipular a base de dados do site: extrair, alterar ou eliminar dados. Evita-se validando e filtrando sistematicamente os dados no servidor, nunca apenas no navegador.
›O RGPD exige um consentimento explícito para cada formulário?
O RGPD exige um consentimento claro e informado para qualquer recolha de dados pessoais, com uma finalidade especificada. Isto não significa necessariamente uma caixa de verificação separada para cada campo, mas o visitante deve saber por que motivo os seus dados são recolhidos e poder opor-se facilmente.
›É preciso encriptar os dados enviados por um formulário?
O HTTPS já encripta o transporte dos dados entre o navegador e o servidor, o que cobre o essencial para um formulário padrão. Uma encriptação adicional no armazenamento justifica-se para dados sensíveis (saúde, dados bancários), raramente para um simples formulário de contacto.