Reviewing Security

Passo 1 — Identificar todas as fronteiras de entrada

Mapear cada ponto onde dados externos entram no sistema através do código alterado:

- Inputs de usuário via formulários, query params, path params, headers, body.

- Dados recebidos de APIs externas ou webhooks. - Conteúdo lido de arquivos, uploads ou banco de dados. - Variáveis de ambiente lidas em runtime. - Dados provenientes de filas ou eventos externos.

Cada fronteira identificada é um vetor potencial de ataque e deve ser verificada nos passos seguintes.

Passo 2 — Verificar injeção de dados

Para cada fronteira identificada no Passo 1, verificar se dados externos são usados sem sanitização adequada em:

**SQL Injection:**

- Queries construídas por concatenação de string com input externo. - Uso de ORM sem parâmetros vinculados (parameterized queries / prepared statements). - Filtros dinâmicos construídos com dados do usuário.

**Command Injection:** - Chamadas a `exec`, `spawn`, `system` ou equivalentes com input externo. - Construção de comandos de shell com dados não sanitizados.

**Template/Expression Injection:** - Renderização de templates com dados externos sem escaping. - Avaliação de expressões dinâmicas (eval, Function constructor, expressões JINJA sem escape).

**Path Traversal:** - Construção de caminhos de arquivo com input externo sem normalização e validação. - Acesso a arquivos fora do diretório permitido.

Passo 3 — Verificar exposição de dados sensíveis

Verificar se o PR pode expor informação que não deveria ser acessível:

- Logs que incluem tokens, passwords, PII, dados de sessão ou stack traces completos.

- Respostas de API que retornam campos sensíveis além do necessário (over-fetching). - Mensagens de erro que revelam estrutura interna, versões de dependências ou detalhes de banco. - Dados sensíveis armazenados em cache sem TTL ou sem controle de acesso. - Secrets hardcoded em código ou comentários. - Dados sensíveis enviados via URL (query params que aparecem em logs).

Passo 4 — Verificar autenticação e autorização

Quando o PR altera fluxos de autenticação ou decisões de acesso:

**Autenticação:**

- Tokens ou sessões são validados antes de qualquer operação privilegiada? - Expiração de token é verificada? - Há bypass de autenticação possível por manipulação de parâmetros?

**Autorização:** - Verificação de permissão ocorre no lado do servidor, não apenas no cliente? - O usuário pode acessar ou modificar recursos de outros usuários (IDOR — Insecure Direct Object Reference)? - Mudanças de papel ou escopo são validadas em cada request, não apenas no login? - Há escalação de privilégio possível através de parâmetros manipulados?

Passo 5 — Verificar dependências introduzidas

Para cada nova dependência adicionada no PR:

- Verificar se a versão fixada tem vulnerabilidades conhecidas (CVE) consultando o nome e versão.

- Verificar se a dependência é amplamente mantida e confiável. - Verificar se a dependência tem acesso a recursos sensíveis (filesystem, network, environment) desnecessários para seu propósito. - Verificar se dependências de desenvolvimento foram erroneamente adicionadas como dependências de produção.

Passo 6 — Verificar uso de criptografia

Quando o PR usa ou altera operações criptográficas:

- Algoritmos fracos ou deprecated estão sendo usados (MD5, SHA1 para passwords, DES, RC4)?

- Chaves criptográficas estão sendo geradas com entropia adequada? - IVs ou nonces estão sendo reutilizados em operações simétricas? - Comparações de hash são feitas com funções de comparação em tempo constante para prevenir timing attacks? - Passwords são armazenadas com algoritmo adequado de hashing (bcrypt, argon2, scrypt) e não com hash simples?

---