Security code review

Nível: C1

Objetivo

Fazer security review de código em C1 com foco em input validation, authorization checks, secrets handling, dependency risk e threat modeling. O foco é review que identifica vulnerabilidades reais com severidade calibrada, não 'isso é inseguro' sem critério.

Explicação

Security review em C1 não é 'isso parece inseguro'; é 'isso tem vulnerabilidade X com severidade Y, e a mitigação é Z'. Cinco eixos:

1. Input validation

Toda entrada é hostil até prova em contrário. C1 cita: 'this endpoint accepts arbitrary user input and passes it to SQL without parameterization' (SQL injection) ou 'this file upload does not check the MIME type' (file upload vulnerability). Review C1 sempre mostra a vulnerabilidade, não 'valide a entrada'.

2. Authorization checks

Quem pode fazer o quê. C1 cita: 'this endpoint returns the user data without checking that the requester is the owner' (IDOR) ou 'this admin endpoint is missing the role check' (missing authorization). Authorization C1 verifica cada endpoint, não só o happy path.

3. Secrets handling

Onde estão as credenciais. C1 cita: 'this code reads the API key from an environment variable, which is good; this code logs the secret, which is bad' ou 'this secret is committed to the repo, which is a P0'. Secrets handling C1 inclui rotação, escopo, e armazenamento.

4. Dependency risk

Bibliotecas de terceiros têm vulnerabilidades. C1 cita: 'this dependency has a known CVE; we need to upgrade to the patched version' ou 'this dependency is no longer maintained'. Dependency review C1 é parte do review de PR.

5. Threat modeling

Quem ataca, o que quer, como. C1 cita: 'a logged-out user can call this endpoint and enumerate IDs' ou 'an attacker with the API key can read all users'. Threat model C1 nomeia o atacante e o objetivo, não 'é seguro?'.

Exemplos

Erros comuns

• Review sem threat model: 'isso é seguro' sem dizer 'para quem?' é opinião.
• Confundir input validation com sanitization: validate (rejeitar entrada ruim) e sanitize (limpar entrada) são diferentes; C1 sempre diz qual é qual.
• Ignorar dependency review: 80% das vulnerabilidades vêm de dependências; sem review, o PR é uma porta aberta.
• Tratar secret leak como P2: secret commit é P0; rotação imediata + gitignore + audit.
• Não calibrar severidade: SQL injection e IDOR são P0; log verboso é P2; sem calibração, tudo vira 'isso é ruim'.

Prática guiada

Reescreva cada crítica de security abaixo no padrão C1.

1. Input validation: cite a vulnerabilidade (SQLi, XSS, file upload) e a entrada que a explora.
2. Authorization: cite o endpoint e o que falta verificar (owner check, role check).
3. Secrets: cite onde o segredo está, a rotação, e a mitigação.
4. Dependency: cite o CVE e a versão corrigida.
5. Threat model: nomeie o atacante, o objetivo, e a mitigação.

Resumo

Security review C1 tem cinco eixos: input validation (vulnerabilidade nomeada), authorization checks (endpoint + check que falta), secrets handling (rotação + armazenamento), dependency risk (CVE + upgrade), threat modeling (atacante + objetivo + mitigação). Sem threat model, é opinião; com severidade calibrada, é segurança.

História: Security code review

Nível: C1

História em inglês

Reviewing a user endpoint with security flaws

On Monday, I had to review a PR for the user endpoint that the team flagged for security review. I opened with SQLi: blocker, the endpoint accepts user_id from the query string and concatenates it into the SQL query without parameterization. I added IDOR: blocker, the endpoint returns user data without checking that the requester is the owner. I questioned the secret: the API key is committed to the repo in plain text; rotate immediately. I closed with threat model: a logged-out user can call this endpoint and enumerate IDs; we need authentication and rate limiting. The team thanked me for the calibrations: now we know what is P0 and what is a P2.

Tradução linha por linha

Notas de vocabulário

• blocker, SQL injection risk = vulnerabilidade nomeada com severidade calibrada.
• without checking that the requester is the owner = IDOR: endpoint + check que falta.
• the API key is committed to the repo in plain text = secret leak: P0, rotação imediata.
• a logged-out user can call this endpoint and enumerate IDs = threat model: atacante + objetivo.
• we need authentication and rate limiting = mitigação: autenticação + rate limiting.

Perguntas de compreensão

1. O que diferencia security review C1 de opinião?
2. Por que threat model é parte do security review?
3. Como priorizar vulnerabilidades em C1?

Prática com a história

1. Escreva um security review C1 para um endpoint com SQL injection.
2. Escreva um security review C1 para um secret commitado.
3. Escreva um threat model C1 para um endpoint de listagem.