Alguém envia o teu formulário com um endereço de email inválido. O teu formulário aceita-o. O email de boas-vindas volta devolvido. A pessoa nunca ouve falar de ti. Outra pessoa envia com campos obrigatórios por preencher. O formulário passa na mesma. A tua equipa fica com dados incompletos. Estas duas falhas acontecem porque a validação falta ou está mal feita.
A validação é o processo de verificar se os dados de um formulário são válidos antes de os aceitar. Acontece em dois sítios: no navegador e no servidor. Os dois contam. Este artigo explica como funciona a validação, porque precisas de ambos e quais são os erros comuns.
O que é a validação?
A validação verifica se os dados de um formulário cumprem os teus requisitos. Os campos obrigatórios têm valores. Os campos de email contêm um símbolo @. Os campos de telefone contêm apenas números. Os ficheiros carregados estão abaixo do limite de tamanho.
Sem validação, entram dados maus no teu sistema. O teu backend falha. O teu serviço de email rejeita mensagens. Perdes tempo a limpar dados sujos.
A validação acontece em dois sítios: no cliente (no navegador, antes do envio) e no servidor (no teu servidor, depois do envio). Ambos são necessários.
Validação no cliente
O navegador pode verificar os dados do formulário antes de os enviar. O HTML tem atributos de validação incorporados. O JavaScript também pode validar.
Validação em HTML
<input type="email" required> valida que o campo tem um valor e parece um email. O navegador mostra uma mensagem de erro se o utilizador tentar enviar um formulário inválido.
Os atributos de validação do HTML incluem required, para garantir que o campo tem um valor, min/max para números, para manter os valores dentro de um intervalo, minlength/maxlength, para impor um número de caracteres, pattern, para corresponder a expressões regulares, e type, para validar o próprio tipo de campo. Por exemplo, type="email" verifica o formato, enquanto type="number" rejeita texto não numérico.
A validação em HTML funciona de imediato, sem precisar de JavaScript, e dá boas mensagens de erro do navegador, com teclados móveis que se ajustam ao tipo de campo. As desvantagens são que as mensagens de erro do navegador são genéricas e por vezes pouco claras, não as podes personalizar sem JavaScript e navegadores diferentes mostram mensagens diferentes.
Validação em JavaScript
Para teres mais controlo, valida com JavaScript usando function validateEmail(email) { const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/; return regex.test(email); } e form.addEventListener('submit', (e) => { if (!validateEmail(input.value)) { e.preventDefault(); showError('Please enter a valid email'); } });. A validação em JavaScript permite escrever regras personalizadas, mostrar mensagens de erro personalizadas e validar os campos enquanto o utilizador escreve, para uma validação em tempo real. As desvantagens incluem exigir JavaScript (não é fiável para segurança), exigir mais código para manter e, possivelmente, mostrar erros antes de o utilizador acabar de escrever, se validares no evento input.
Validação no servidor
Depois de o formulário ser enviado, o servidor verifica os dados outra vez. É aqui que a segurança a sério acontece.
Nunca confies na validação no cliente. Alguém pode desativar o JavaScript. Alguém pode intercetar o pedido e modificar os dados. Alguém pode usar o curl ou outra ferramenta para enviar dados maus sem passar pelo teu formulário.
A validação no servidor é a única proteção que tens. Não é opcional.
Quando o servidor recebe o envio do formulário, verifica se os campos obrigatórios estão presentes, valida o formato do email, do telefone e dos URLs, verifica se os números estão dentro dos intervalos esperados, confirma que os ficheiros carregados são do tipo e tamanho certos, garante que os dados não são demasiado longos e sanitiza os dados para evitar ataques de injeção. Se a validação falhar, envia uma resposta de erro, para que o formulário não seja processado e o utilizador saiba o que está errado. A validação no servidor é mais lenta porque o utilizador tem de esperar por uma resposta, mas é fiável e segura, por isso faz-a sempre.
Quando usar cada tipo de validação
A validação no cliente serve a experiência do utilizador. Diz-lhe de imediato se algo está errado. Não tem de enviar o formulário para descobrir que um email é inválido.
A validação no servidor serve a integridade dos dados e a segurança. Garante que os dados maus nunca entram no teu sistema.
Usa as duas. Validação no cliente para rapidez e feedback. Validação no servidor para proteção e segurança.
Erros comuns de validação
Fazer apenas validação no cliente
Alguém desativa o JavaScript e a tua validação desaparece. Alguém usa o curl para enviar dados maus por POST e a tua validação nunca corre. Acabas com lixo na base de dados.
Valida sempre no servidor. A validação no cliente é um extra.
Validar de forma demasiado rígida
A tua validação de email é tão rígida que emails reais falham. A tua validação de telefone só aceita o formato dos EUA e rejeita números internacionais. O teu campo de nome rejeita hífenes, apóstrofos e outros caracteres válidos.
Testa a tua validação com dados reais. Pede a utilizadores de outros países que testem. Torna as regras de validação o mais permissivas possível, mas sem deixar de apanhar dados maus.
Não mostrar mensagens de erro claras
"Dados inválidos." O que é inválido? Que campo? O que devem fazer?
As mensagens de erro têm de ser específicas: "O email deve ter entre 5 e 254 caracteres." "O telefone deve ter 10 dígitos." "A palavra-passe deve conter pelo menos um número."
Mostra o erro junto do campo que o causou. Não escondas os erros numa lista de resumo onde o utilizador tem de andar à procura deles.
Validar dados sensíveis no cliente
Não envies números de cartões de crédito nem palavras-passe pela validação no cliente. Não os mostres na consola do navegador. Não os registes em logs.
Valida os dados sensíveis apenas no servidor, através de HTTPS.
Não validar os ficheiros carregados
Alguém carrega um ficheiro de 100 megabytes. O teu servidor fica sem espaço. Alguém carrega um ficheiro executável. O teu servidor apanha um vírus.
Valida o tipo e o tamanho do ficheiro no servidor. Verifica se o ficheiro é mesmo do tipo que diz ser. Não confies apenas na extensão do ficheiro nem no tipo MIME.
Validação em tempo real ou validação no envio
A validação em tempo real verifica cada campo enquanto o utilizador escreve. O utilizador vê logo uma mensagem de erro se escrever algo errado. Pode corrigir de imediato.
Desvantagem: se mostrares erros cedo demais, o utilizador fica frustrado. Mostra os erros só depois de o utilizador sair do campo (no evento blur), e não enquanto ainda está a escrever.
A validação no envio verifica tudo quando o formulário é enviado. O utilizador preenche o formulário todo e só depois vê todos os erros de uma vez.
Desvantagem: o utilizador tem de voltar atrás e corrigir erros depois de já ter enviado. Isto interrompe o fluxo.
Boa prática: valida no blur (quando o utilizador sai de um campo) para dar feedback em tempo real. Valida no envio como verificação final. Mostra todos os erros de uma vez, se algum falhar.
Validação para tipos de campo específicos
Validação de email
A validação completa de um email é complexa (a RFC 5322 tem 60 páginas), por isso, na maioria dos casos, verifica se o valor contém um @ e um domínio usando const email = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;. Isto apanha a maioria dos emails inválidos sem ser tão rígido que os emails reais falhem.
Validação de telefone
O formato do telefone varia consoante o país. O formato dos EUA é (123) 456-7890, o do Reino Unido é +44 20 7946 0958 e a Alemanha usa +49 30 123456. Aceita o formato internacional, retira os caracteres não numéricos no servidor e guarda o telefone como texto em vez de número, para preservar os zeros à esquerda em alguns países.
Validação de palavra-passe
Uma boa palavra-passe é longa (pelo menos 12 caracteres) e difícil de adivinhar. Não exijas caracteres especiais nem maiúsculas e minúsculas misturadas, porque estas regras frustram os utilizadores e não melhoram a segurança. Bons requisitos de palavra-passe são pelo menos 12 caracteres e evitar padrões comuns (como "123456" ou o nome do utilizador). Usa um indicador de força da palavra-passe para mostrar ao utilizador quão forte é a dele.
Validação de datas
Verifica se a data está no futuro ou no passado, conforme for preciso. Um formulário de inscrição num evento deve rejeitar datas no passado. Um formulário de data de nascimento deve rejeitar datas no futuro.
Como o WEMASY trata a validação de formulários
Os formulários do WEMASY incluem validação no cliente incorporada (campos obrigatórios, formato de email, etc.) para feedback imediato. Quando os formulários são enviados, os servidores do WEMASY validam todos os dados outra vez antes de os processar. Assim, os utilizadores têm feedback rápido e os teus dados ficam protegidos.
Vê as funcionalidades de validação no teu plano WEMASY.