O que o OWASP lista e o que a LGPD exige

O OWASP Top 10 é um catálogo de classes de falha técnica. Ele descreve padrões de erro recorrentes em aplicações web, como quebra de controle de acesso, falhas de criptografia, injeção de comandos e configuração incorreta. Serve para organizar o que costuma dar errado, mas não diz nada sobre quais dados estão em jogo nem sobre a obrigação de protegê-los.

A LGPD parte de outro ponto: o dado pessoal e o direito do titular. Exige base legal, finalidade definida, minimização, controle de acesso, registro das operações e capacidade de responder a incidentes. Um sistema pode passar no scanner e ainda assim violar a lei, por exemplo ao guardar CPF em log de aplicação por tempo indeterminado ou ao exibir dado de um cliente para outro por erro de autorização.

A priorização nasce do encontro entre as duas listas. Nem toda falha do OWASP vira incidente de LGPD, e nem todo risco de LGPD aparece no Top 10.

Como priorizar: uma matriz de cinco passos

  1. Mapeie onde há dado pessoal no fluxo real: formulário, API interna, fila, cache, log, backup e relatório exportado.
  2. Cruze cada ponto com as classes do OWASP que expõem dado diretamente: controle de acesso quebrado, falha criptográfica, injeção, falha de autenticação e configuração insegura.
  3. Classifique o dado: dado sensível (saúde, biometria, origem racial, convicção religiosa) pesa mais que dado cadastral comum.
  4. Ordene pelo par probabilidade de exploração e dano ao titular, não pelo esforço de correção.
  5. Registre a decisão: o que foi corrigido, o que foi aceito como risco e com qual justificativa. Esse registro é o que sustenta a conversa com o jurídico, com o cliente e, se necessário, com a ANPD.

Um exemplo concreto: uma clínica de médio porte tem portal do paciente com a rota /exames/{id}. A tela esconde o botão de outro paciente, mas o servidor confia no id recebido. Basta trocar o número na URL para ler laudo alheio. É uma falha de controle de acesso (OWASP) sobre dado de saúde (LGPD), com dano alto e correção barata: validar no servidor se o recurso pertence ao titular autenticado, em toda rota que devolve registro.

Hardening como rotina, não como projeto

Hardening não é uma varredura feita uma vez por ano. É um conjunto de decisões que entram no dia a dia do time:

  • Teste automatizado de autorização por endpoint, provando que outro usuário recebe 403.
  • Consulta sempre com escopo de tenant ou de titular na cláusula, nunca filtrando em memória.
  • Segredos fora do repositório, com rotação e ambientes separados.
  • Log sem dado pessoal: identificador interno em vez de CPF, sem payload completo de requisição.
  • Rotina de atualização de dependências, com prazo definido para corrigir versão vulnerável.
  • Cabeçalhos de segurança, cookies com HttpOnly e Secure, e mensagens de erro que não revelam estrutura interna.

Cada item desses é verificável em revisão de código e barato de manter quando vira padrão do time.

Na prática

Quem mantém software em produção deve tratar segurança como item de backlog com prazo, não como tarefa de fundo. Uma forma simples de começar: escolha os três endpoints que mais devolvem dado pessoal, escreva testes de autorização para eles e corrija o que falhar. Em seguida, revise o que a aplicação grava em log e reduza ao mínimo necessário. Por fim, inclua no checklist de pull request duas perguntas objetivas: quem pode acessar este recurso e que dado pessoal passa por aqui. O resto do hardening avança em cima dessa base, com evidência registrada a cada sprint.