Como verificar os formulários do seu site: rótulos, tipos de campo, HTTPS e CSRF

Formulários de contato, cadastros, logins, checkouts e caixas de busca são os pontos em que o seu site pede que o visitante faça alguma coisa. Um formulário confuso, difícil de preencher no celular ou inseguro custa leads e confiança — e os problemas de formulário raramente aparecem antes de alguém reclamar, porque quem desiste não avisa.

A maioria dos problemas de formulário é visível no HTML, então dá para verificá-los sem preencher nada. Veja o que observar.

Usabilidade e acessibilidade

Todo campo precisa de um rótulo

Cada campo precisa de um <label> associado a ele por for e id (ou que o envolva). Os leitores de tela anunciam o rótulo, e clicar nele leva o foco ao campo. Placeholder não é rótulo: ele some assim que a pessoa digita, costuma ter baixo contraste e não é anunciado de forma confiável. Se um design realmente não comporta um rótulo visível, o aria-label é a alternativa, mas rótulos visíveis ajudam todo mundo. Nosso guia de acessibilidade trata dos rótulos com mais profundidade.

Use o tipo de campo correto

type="email", type="tel" e type="url" abrem o teclado certo nos celulares e oferecem a validação básica do navegador. Um campo de telefone com type="text" obriga quem está no celular a caçar os números. Cuidado com type="number": ele foi feito para quantidades, não para telefones, números de cartão ou CEPs.

Adicione dicas de autocomplete

O atributo autocomplete diz aos navegadores e aos gerenciadores de senhas o que é cada campo: name, email, tel, street-address, postal-code, cc-number, current-password, new-password, one-time-code. Ele permite que os visitantes preencham um formulário com um toque e é uma exigência das WCAG 2.1 (critério de sucesso 1.3.5) para campos que coletam informações sobre o usuário. Não coloque autocomplete="off" em campos de senha: isso empurra as pessoas para senhas mais fracas e reutilizadas.

Um botão de envio de verdade e uma validação que ajuda

Use um <button type="submit"> para que o formulário funcione com a tecla Enter e sem JavaScript personalizado. Marque os campos obrigatórios com o atributo required e deixe isso claro no rótulo, e mostre as mensagens de erro ao lado do campo, em palavras simples. Adicionar novalidate desliga as verificações nativas do navegador; isso só é aceitável se você as substituir pelas suas.

Segurança

• HTTPS na página e no action. Um campo de senha em uma página HTTP, ou um formulário cujo action aponta para uma URL http://, envia em texto puro o que as pessoas digitam. Tanto a página quanto o action precisam ser HTTPS.
• Nunca GET para senhas. Com method="get", os valores do formulário vão para a URL — e, de lá, para o histórico do navegador, os logs do servidor e os cabeçalhos referrer. Use method="post" para qualquer dado sensível.
• Proteção contra CSRF. Formulários que alteram alguma coisa (fazer login, atualizar uma conta, fechar um pedido) devem ser protegidos contra a falsificação de requisição entre sites (cross-site request forgery), normalmente com um token secreto em um campo oculto que o servidor confere, além de cookies com SameSite. Veja como verificar a segurança dos cookies.
• Saiba para onde os dados vão. Um formulário que envia para outro domínio, como um provedor de lista de e-mails ou de CRM, pode ser esperado — mas confirme que é intencional e que está coberto pela sua política de privacidade.
• Valide no servidor. A validação do navegador é uma conveniência para visitantes honestos; qualquer pessoa consegue contorná-la. O servidor precisa conferir todos os valores de novo.

Como o Rudra verifica formulários — sem enviá-los

O verificador de links quebrados gratuito e a auditoria de site carregam a sua página em um navegador real e analisam até 10 formulários nela. Eles sinalizam, com os nomes dos formulários e dos campos envolvidos:

• campos de senha em uma página HTTP, formulários que enviam para http:// e formulários de senha que usam GET (cada um custa 10 pontos);
• campos cujo único rótulo é um placeholder (3 pontos);
• campos sem rótulo acessível, tipos de campo que não combinam com o conteúdo (um campo de e-mail usando type="text"), dicas de autocomplete ausentes, autocomplete="off" em senhas, formulários que enviam para outro host, formulários sem botão de envio, campos obrigatórios de e-mail ou telefone sem restrições e novalidate — todos informativos;
• formulários POST sem um token visível no estilo CSRF — com baixa confiança, porque o token pode ser adicionado por JavaScript ou o servidor pode proteger o formulário de outra forma.

Ele também pergunta ao navegador, uma única vez, se ele bloquearia um envio vazio dos campos marcados como obrigatórios — lendo o estado de validação de cada campo, sem dar foco nem preencher nada e sem disparar os manipuladores de validação do próprio site.

Por que nunca enviamos formulários

Enviar um formulário tem efeitos reais: um e-mail chega à caixa de entrada de alguém, uma conta é criada, um pedido ou um chamado de suporte aparece, um limite de requisições ou um filtro antifraude é acionado. Uma ferramenta automatizada não tem como saber quais formulários é seguro enviar, então a nossa não envia nenhum. Os formulários nunca são enviados, clicados, focados ou preenchidos, e os relatórios contêm apenas nomes de campos e rótulos — nunca valores.

A contrapartida é que algumas coisas só podem ser testadas enviando o formulário, e essas ficam por sua conta: se o envio chega, como são as mensagens de confirmação e de erro, se o servidor rejeita entradas inválidas ou vindas de outros sites e se a proteção contra spam funciona.

Um teste manual para cada formulário

1. Preencha-o no celular e confira se cada campo abre o teclado certo e se o preenchimento automático faz sentido.
2. Complete-o usando só o teclado e, depois, com um leitor de tela como o NVDA ou o VoiceOver.
3. Envie-o vazio e com um endereço de e-mail errado e leia as mensagens de erro.
4. Envie-o corretamente e confirme que a mensagem chega aonde deveria.
5. Em logins e formulários de conta, peça a um desenvolvedor que confirme a proteção contra CSRF e a validação no servidor.