Checklist de revisão de código focada em segurança para mudanças em fronteiras de confiança

Objetivo

Detectar os defeitos de segurança que uma revisão geral deixa passar porque são código correto fazendo a coisa errada: uma verificação de autorização ausente, uma saída sem escape, uma URL buscada a partir de entrada do usuário.

Pré-requisitos

Uma descrição da mudança que indique as fronteiras de confiança afetadas, uma revisão geral de design e correção já concluída e os artigos da wiki vinculados, com os detalhes de cada controle. O OWASP Code Review Guide (citado) é a referência extensa para a mesma atividade.

Passos

1. Decida se o checklist se aplica: a mudança lê entrada de fora do processo, altera quem pode fazer o quê, toca em banco de dados ou sistema de arquivos, faz requisições de saída, lida com credenciais ou chaves, ou adiciona uma dependência? Se nenhuma dessas condições se verifica, pare.
2. Entrada: para cada novo ponto de entrada, encontre onde os dados são validados (tipo, tamanho, lista de permissão) e onde são usados. Todo uso que monte uma consulta, comando, caminho, URL ou marcação deve passar por parametrização ou codificação, e não por concatenação de strings.
3. Autenticação e sessões: todo novo endpoint fica atrás da mesma autenticação que os endpoints vizinhos. O código de login, redefinição de senha, MFA e tokens regenera identificadores e expirações onde os artigos existentes assim indicam.
4. Autorização: para cada objeto acessado por um identificador vindo da requisição, localize a verificação de que o principal atual pode acessar esse objeto, e não apenas o endpoint. Procure a verificação ausente no segundo caminho (em lote, exportação, administração, webhook).
5. Acesso a dados e armazenamento: consultas parametrizadas; novas colunas com dados pessoais classificadas e cobertas por uma política de retenção; arquivos gravados com nome aleatório em um local sem permissão de execução.
6. Requisições de saída: qualquer URL construída a partir de entrada passa pela lista de permissão contra SSRF; redirecionamentos apontam apenas para caminhos relativos ou hosts da lista; XML, YAML e serialização nativa são processados com o loader seguro.
7. Segredos e configuração: sem credenciais literais, sem segredos em logs ou mensagens de erro; uma nova configuração ausente deve fazer o sistema falhar de forma fechada (fail closed).
8. Dependências: um novo pacote tem uma justificativa, uma versão fixada e um upstream mantido; uma alteração no lockfile é revisada em busca de pacotes inesperados.
9. Logs e erros: ações relevantes para a segurança geram um evento de auditoria; as respostas de erro não expõem stack traces nem hosts internos.
10. Escreva os achados como perguntas, com um link para o artigo pertinente; bloqueie o merge apenas por itens dos passos 2, 4 e 6, aqueles que um atacante alcança primeiro.

Resultado esperado

Mudanças que tocam fronteiras recebem uma segunda análise consistente; os revisores concentram a atenção de segurança onde ela compensa e a dispensam no resto.

Limites e base de verificação

É uma proposta, não uma prática medida. A lista encontra omissões, não falhas de lógica nas regras de negócio, que exigem modelagem de ameaças. Aplicá-la a todas as mudanças a dilui; aplicá-la apenas quando o autor sinaliza uma fronteira depende de o autor perceber que ela existe.