Validar a entrada: a muralha de defesa

Nunca confie no que vem de fora

Se existe uma única frase para levar da robustez, é esta: nunca confie nos dados que vêm de fora. Tudo que o programa recebe do mundo externo, o que o usuário digita, o que lê de um arquivo, o que chega pela internet, pode vir errado, vazio, fora de faixa ou até malicioso. O usuário digita letras onde você esperava um número, deixa o campo em branco, coloca uma data impossível, ou tenta de propósito quebrar o sistema. Um programa ingênuo pega esse dado e o usa direto, e é aí que nascem a maioria dos erros de execução e das brechas de segurança. Um programa robusto faz diferente: ele confere cada dado que entra, na porta, antes de deixá-lo circular por dentro. Essa conferência é a validação de entrada, e é a defesa mais importante que existe.

Validar é fazer uma série de perguntas ao dado antes de aceitá-lo, e você já sabe fazê-las desde o módulo de strings. O campo está vazio quando não deveria? O número está dentro da faixa permitida? A data existe de verdade? O e-mail tem o formato certo? O texto não passou do tamanho máximo? Cada pergunta é uma regra, e o dado só entra se passar por todas. A ferramenta perfeita para isso é a cláusula de guarda do módulo de decisões: logo no começo, você testa cada regra e, se alguma falhar, avisa o usuário com uma mensagem clara e recusa o dado ali mesmo. Quando o dado passa por todas as guardas, o resto do programa trabalha em segurança, sabendo que a entrada é confiável.

função cadastrarIdade(texto)
  se texto está vazio então
    retorne "Informe a idade"
  fim
  se texto não é um número então
    retorne "A idade deve conter apenas números"
  fim
  idade <- converterParaNumero(texto)
  se idade < 0 ou idade > 130 então
    retorne "Idade fora de uma faixa válida"
  fim
  // daqui para baixo, a idade é confiável:
  salvar(idade)
  retorne "Cadastro concluído"
fim

Guardas validam a entrada uma regra por vez. Só depois de passar por todas o dado é usado, com segurança.

Validação também é segurança

Validar a entrada não previne só erros acidentais; é a primeira linha de defesa contra abusos intencionais. Alguém mal-intencionado pode digitar um texto gigantesco para tentar travar o programa, ou inserir comandos disfarçados num campo esperando que o sistema os execute. Programas que não validam a entrada são a porta de entrada da maioria dos ataques a aplicações. Por isso, a mesma disciplina que barra o campo vazio também barra o texto absurdamente longo, os caracteres estranhos onde só deveriam existir números, e os conteúdos suspeitos. A regra prática é limitar tudo: tamanho máximo, faixa de valores, tipo esperado, formato. Quanto mais estreita a porta, menos coisa ruim entra. Neste curso você foca na robustez, evitar que o programa quebre com dados ruins, mas vale saber que a mesma validação é o alicerce da segurança de qualquer aplicação séria.

Validar cedo, validar sempre

A hora de validar é o mais cedo possível, na porta de entrada, assim que o dado chega. Validar cedo tem duas vantagens: barra o problema antes que ele se espalhe pelo código, e concentra as regras num lugar só, fácil de achar e manter. Um erro comum é validar tarde, deixar o dado ruim circular e só perceber lá no fundo, quando o programa quebra num lugar distante da causa; caçar esse tipo de bug é penoso. Outra armadilha é validar num lugar e esquecer em outro: se o mesmo dado entra por dois caminhos, os dois precisam validar, ou um vira brecha. A mentalidade defensiva que amarra tudo isso é o assunto da próxima aula, mas o princípio já vale: trate a fronteira do seu programa como uma alfândega rigorosa, onde todo dado é revistado antes de entrar, e você terá evitado uma legião de erros antes mesmo de eles nascerem.