A confusão que paga todas as outras
Toda a família de injeção nasce de uma única confusão: tratar como dado o que o destinatário vai tratar como código. O banco recebe uma string e monta SQL com ela. O navegador recebe HTML e executa script embutido. O shell recebe argumento e encontra ponto e vírgula. Em cada caso, o sistema montou uma mensagem que mistura comando e conteúdo, e confiou que o conteúdo nunca imitaria o comando. O atacante faz exatamente isso: fecha a string, fecha a tag, fecha o argumento, e escreve o próprio comando na sequência. É por isso que a defesa raiz é única e estrutural: separar código de dado no momento de montar a mensagem. Parametrizar a consulta, codificar a saída conforme o contexto, invocar o comando com lista de argumentos. As ferramentas ajudam, os testes acham, mas é essa separação que fecha a porta.
XSS: o script que roda na sua origem
O Cross-Site Scripting acontece quando a aplicação devolve ao navegador dado do usuário sem codificar, e esse dado carrega script. O comentário salvo com <script> vira parte da página, executando na origem da vítima com acesso a tudo que a mesma origem permite: cookies, DOM, ações na sessão logada. As três variantes clássicas diferem só em onde o dado retorna. Refletido: a resposta imediata ecoa o parâmetro do pedido, típico de busca e mensagens de erro. Armazenado: o dado fica salvo e executa para todo mundo que abre a página, o pior caso. DOM: o script da própria página escreve dado não confiável no documento sem codificar. A defesa tem duas camadas: codificar na saída conforme o contexto, HTML para corpo, atributo, JavaScript e URL, cada um com regras próprias, e a Content-Security-Policy do módulo final como rede que limita o que executa mesmo quando a codificação falha.
SQL injection: o banco que aceita opinião
Na injeção de SQL, a aplicação monta a consulta concatenando texto do usuário, e o banco executa o resultado completo. O campo de login clássico envia ' OR '1'='1 e a consulta retorna a primeira linha da tabela de contas. As consequências escalam com o banco: leitura de tabelas inteiras, autenticação contornada, e nos casos graves escrita e execução. A defesa canônica é a consulta parametrizada: o SQL sai pronto com marcadores de posição, o driver envia os valores separadamente, e o banco nunca mistura os dois planos. Proibições de lista de palavras, escapes manuais e oração não substituem: a parametrização é o mecanismo, o resto é superstição. Consultas que não podem ser parametrizadas, como ordenação dinâmica de coluna, usam lista branca de valores permitidos, porque aí a escolha é estrutura, não dado.