Privacidade e segurança em API de cadastro com dados pessoais
Uma startup expõe uma API REST de cadastro de usuários. O endpoint GET /usuarios/{id} retorna nome completo, CPF, e-mail, telefone e endereço, autenticado apenas por um token fixo embutido no aplicativo móvel. Os IDs são sequenciais (1, 2, 3…). Logs da aplicação gravam a resposta completa do endpoint, incluindo CPF, em texto claro, com retenção de 12 meses. O app também envia a senha do usuário no corpo de uma requisição HTTP sem TLS em uma rede Wi-Fi pública, e armazena o token em armazenamento não protegido do dispositivo. A empresa é brasileira e trata dados de clientes no Brasil.
1. Identifique as vulnerabilidades e os problemas de conformidade, explicando o impacto de cada um.
Read the worked answer
(1) Token fixo embutido no app: não é segredo - qualquer pessoa que extraia o binário obtém acesso; não há identidade por usuário nem revogação. (2) IDs sequenciais + autorização ausente: permite IDOR (enumeração de /usuarios/1..N), expondo dados de todos. (3) HTTP sem TLS: senha e dados trafegam em texto claro, sujeitos a interceptação em Wi-Fi público (MITM). (4) Logs com CPF em texto claro por 12 meses: exposição desnecessária e prolongada de dado pessoal. (5) Token em armazenamento não protegido: roubo por malware ou acesso físico. Conformidade (LGPD): CPF é dado pessoal; o tratamento exige base legal, finalidade, minimização e segurança (arts. 6º e 46). Registrar CPF em log sem necessidade viola minimização; a falta de controles de segurança pode configurar incidente com dever de comunicação. Note que a LGPD não exige TLS explicitamente, mas exige segurança adequada - TLS é o meio técnico esperado.
2. Proponha um conjunto priorizado de correções técnicas.
Read the worked answer
Prioridade por risco: (1) forçar HTTPS/TLS em todas as rotas, com HSTS, e nunca enviar senha em claro; (2) substituir o token fixo por autenticação por usuário (OAuth2/OIDC ou JWT de curta duração com refresh), com autorização por recurso - o usuário só acessa o próprio registro, salvo perfis administrativos; (3) eliminar IDOR: usar identificadores opacos (UUID) e verificar propriedade no servidor; (4) sanitizar logs: remover ou mascarar CPF (ex.: exibir só os 3 últimos dígitos), reduzir retenção ao mínimo necessário; (5) armazenamento seguro no dispositivo (Keychain/Keystore), não em armazenamento comum; (6) rate limiting e monitoramento de enumeração. Ordem: TLS e autenticação/autorização primeiro (risco imediato de vazamento), depois logs e retenção, depois endurecimento do cliente.
3. Discuta o trade-off entre mascarar dados nos logs e a capacidade de investigar incidentes.
Read the worked answer
Mascarar reduz exposição, mas pode dificultar correlação em investigações. Solução equilibrada: não logar o dado pessoal em si, mas um identificador interno (user_id) que permita reconstruir o caso com acesso controlado; para CPF, guardar apenas hash com sal ou os últimos dígitos, suficientes para suporte e insuficientes para identificação plena. Logs com dados sensíveis, quando indispensáveis, devem ter acesso restrito, criptografia e retenção curta. O princípio é minimização com rastreabilidade: manter o que serve à operação e à segurança, descartar o resto. Vale registrar a decisão e revisá-la periodicamente.