Conceito e mecanismo
Autenticar um utilizador não torna válidos todos os pedidos que envia. A aplicação deve verificar direitos, limites e transições de estado no servidor. Uma quantidade negativa pode violar um invariante financeiro mesmo quando o pedido passa pelo login. A interface não é uma fronteira suficiente porque a API pode receber pedidos diretamente. Na construção de SQL, parâmetros protegem valores, mas nomes de colunas concatenados precisam de um desenho controlado, como mapear escolhas permitidas para identificadores definidos pelo servidor. Para XSS, o contexto de saída importa: tratamento de texto HTML não deve ser considerado proteção universal para JavaScript inline ou outros contextos de interpretação.
Aplicação guiada
Num projeto fictício de reembolsos, usa contas e saldos sintéticos para retestar valores inválidos, limites e operações autorizadas. Corrigir apenas o formulário não demonstra a correção da API. Para operações por cookie que alteram estado, POST não constitui proteção anti-CSRF por si só; valida os mecanismos adequados do framework e a origem conforme o desenho. Num serviço que consulta URLs, controla os destinos realmente contactados, incluindo redirecionamentos, em vez de validar apenas a primeira ligação. Cada reteste deve conter um pedido legítimo que continua a funcionar e um pedido indevido que é recusado. Regista a versão e a fronteira testada para a equipa de produção reproduzir a evidência.
Formulário corrigido e API não retestada: a aceitação da correção continua pendente.
Armadilhas comuns
Login como validade do pedido; parâmetros como proteção de toda a sintaxe; POST como anti-CSRF; primeiro URL como cadeia completa.
Tópicos relacionados: Âmbito, autorização e relatório de risco · Reconhecimento e limites da observação · Sistemas, vulnerabilidades e evidência
Aceita a correção quando o controlo do servidor foi demonstrado.
Referência: SQL injection prevention · CEH 312-50, Exam Blueprint v5.0 effective2024-04-10; Candidate Handbook v7.3 (2026-09-21)