OWASP descreve o risco, a LGPD descreve a obrigação

O OWASP Top 10 não é certificação nem selo de conformidade. É um catálogo de categorias de falha que aparecem com recorrência em aplicações reais: controle de acesso quebrado, falhas de autenticação, injeção, configuração incorreta, componentes desatualizados, falhas de logging e monitoramento. Serve para priorizar conversa técnica, não para encerrar auditoria.

A LGPD também não cita framework. Ela exige segurança e prevenção (art. 46), tratamento adequado e limitado ao necessário (art. 6) e comunicação de incidentes relevantes (art. 48). A ligação entre os dois vocabulários é simples: quando uma categoria do OWASP se materializa, ela costuma virar um incidente envolvendo dado pessoal. O que era bug de aplicação passa a ser tratamento irregular, com dever de notificar e de demonstrar que medidas existiam.

Alguns pares diretos:

  1. Controle de acesso quebrado: um usuário acessa registro de outro titular. Vira acesso indevido a dado pessoal.
  2. Falha de autenticação: sessão sequestrada ou credencial compartilhada. Vira comprometimento de conta com acesso a base inteira.
  3. Injeção: exfiltração de tabela completa, incluindo CPF, endereço e dados de saúde.
  4. Configuração incorreta: ambiente de homologação aberto com cópia de produção, sem controle de acesso.
  5. Componentes desatualizados: biblioteca com vulnerabilidade conhecida mantida por comodidade.
  6. Falha de logging: não há trilha para saber o que foi acessado, nem base para notificar titular e autoridade.

Hardening: reduzir o que existe para ser atacado

Hardening não é produto nem projeto anual. É o conjunto de decisões que diminui superfície: banco de dados com usuário de aplicação sem privilégio de DDL, ausência de conta administrativa compartilhada, endpoints de debug e rotas antigas removidos, cabeçalhos de segurança padronizados, TLS obrigatório, segredos em cofre em vez de arquivo de configuração, pinagem de dependências, cadência de atualização definida e WAF tratado como complemento, nunca como substituto de código correto.

Do lado da LGPD, hardening inclui o tratamento do dado pessoal em log. Aplicação que grava corpo inteiro de requisição e resposta mantém CPF, telefone e laudo em texto claro por meses, acessível a qualquer pessoa com leitura no servidor de log. Mascarar campos, definir retenção e restringir quem lê é controle de segurança e de privacidade ao mesmo tempo.

Onde isso cobra a conta na operação

Considere o cenário recorrente de uma clínica de diagnóstico que libera laudos por portal do paciente. O endpoint recebe o identificador do laudo e devolve o PDF. A autenticação está correta, mas falta verificar se aquele laudo pertence àquele paciente. Basta trocar o número na requisição. Somam-se a isso logs completos, com nome, CPF e resultado de exame, e uma equipe de suporte com acesso direto à base de produção, sem registro de quem consultou o quê.

O incidente não é apenas técnico. Dado de saúde é dado sensível (art. 11) e a comunicação à ANPD e ao titular exige saber o escopo real: quais registros, quais acessos, em que janela de tempo. Sem trilha de auditoria, a investigação vira estimativa. Sem evidência de medidas técnicas, a clínica não consegue demonstrar o esforço exigido pelo art. 46. O custo aparece em retrabalho forense, em comunicação pública e na confiança do paciente, não só em correção de código.

Na prática

Para quem mantém software em produção, segurança verificável é o que sustenta conversa com jurídico, cliente e autoridade:

  • Mantenha inventário de endpoints e do fluxo de dado pessoal, atualizado a cada release.
  • Teste autorização por objeto no code review, não apenas autenticação. Toda consulta precisa vincular o titular ao registro.
  • Remova dado pessoal do log por padrão, mascarando campos sensíveis e definindo prazo de retenção.
  • Registre auditoria de acesso a dado sensível em armazenamento que a aplicação não consiga alterar.
  • Saiba qual versão de cada dependência está em produção e tenha cadência definida de atualização.
  • Separe ambientes e credenciais. Ninguém acessa base produtiva sem registro e justificativa.
  • Trate hardening como item de definição de pronto, com checklist no pipeline, e não como varredura pontual.
  • Tenha plano de resposta a incidente escrito, com responsáveis e prazo de decisão sobre notificação, ensaiado antes de precisar.