Validação de Input e Codificação de Output

Vulnerabilidades de injeção — SQL, comandos, LDAP, XPath e outras — surgem quando entradas não confiáveis são interpretadas como código. A validação de entradas garante que os dados estejam em conformidade com os tipos, comprimentos e formatos esperados antes de serem processados, armazenados ou retornados.

A validação por lista de permissões (lista branca) define o que é aceitável: apenas caracteres alfanuméricos, apenas números inteiros no intervalo de 1 a 100, apenas formatos de e-mail válidos. A lista de bloqueio (lista negra) tenta bloquear entradas maliciosas conhecidas e está sempre incompleta. Prefira listas de permissões.

A validação no lado do cliente melhora a experiência do usuário, mas não oferece nenhuma segurança — invasores a contornam facilmente usando as ferramentas de desenvolvedor do navegador ou curl. Sempre valide no lado do servidor. O lado do cliente é uma conveniência; o lado do servidor é o controle de segurança.

Números: verifique o tipo e o intervalo. Cadeias de caracteres: verifique o comprimento e o conjunto de caracteres. Datas: faça o processamento estrito e verifique o intervalo. Arquivos: verifique a extensão AND os bytes mágicos/o tipo MIME — nunca confie apenas na extensão. URLs: analise e valide o esquema, o host e os componentes do caminho.

O resultado mais importante da validação de entradas para bancos de dados é nunca concatenar entradas do usuário em SQL. Use consultas parametrizadas (instruções preparadas), nas quais a entrada do usuário é passada como um parâmetro, e não interpolada na cadeia de caracteres de query.

A mesma cadeia de caracteres exige uma codificação diferente dependendo do contexto. Corpo HTML: faça a codificação HTML (< > &). Atributo HTML: codificação de atributos HTML. JavaScript: faça o escape em JS. Parâmetro de URL: codificação de URL (codificação percentual). Usar a codificação errada deixa brechas que os invasores exploram.

Nunca insira dados do usuário diretamente no HTML. Use um mecanismo ou uma biblioteca de modelos que faça o escape automático de HTML. No React, {value} é seguro; dangerouslySetInnerHTML ignora o escape. No Django, os modelos fazem o escape automático, a menos que você use explicitamente o filtro safe.

Quando inserir dados em JavaScript (por exemplo, uma variável inicializada com dados do usuário), a codificação HTML é insuficiente. Use codificação JSON: JSON.stringify(value). Isso impede que os dados saiam do contexto literal de uma cadeia de caracteres JS.

Dados fornecidos pelo usuário inseridos em URLs devem ser codificados em percentual usando encodeURIComponent() (JS) ou urllib.parse.quote() (Python). Dados não codificados podem manipular a estrutura da URL, levando a redirecionamentos abertos ou travessia de caminho.

CSP adiciona uma segunda linha de defesa contra XSS. Uma CSP rigorosa que usa nonces impede a execução de scripts embutidos mesmo se uma carga útil de XSS for injetada, porque o navegador se recusa a executar scripts sem o atributo nonce correto.

XSS baseado em DOM ocorre quando JavaScript lê de fontes controladas pelo invasor (location.hash, document.URL, cookie) e grava em destinos perigosos (innerHTML, document.write, eval). Audite todos os fluxos de dados das APIs do navegador para os destinos do DOM usando ferramentas de análise estática.

Por que a validação de entradas no lado do servidor é essencial mesmo quando a validação no lado do cliente está implementada?

A validação de entradas (listas de permissões, verificação de tipos, limites de comprimento), combinada com a codificação de saída sensível ao contexto (HTML, JS, URL, parametrização de SQL), é a principal defesa contra ataques de injeção e XSS. Ambas devem ser aplicadas no lado do servidor, sem exceção.