OWASP, LGPD e hardening aparecem juntos em quase toda apresentação sobre segurança, mas raramente conversam no dia a dia do time. O OWASP descreve classes de falha técnica. A LGPD define obrigações sobre dados pessoais. Hardening é o trabalho de engenharia que fecha a distância entre os dois. O problema é que cada um fala uma língua, e a conta chega quando alguém pergunta, em uma auditoria ou no meio de um incidente, o que a aplicação realmente faz.

Três linguagens que precisam convergir

O OWASP Top 10 é um catálogo de categorias de risco: controle de acesso quebrado, falhas criptográficas, injeção, design inseguro, má configuração, componentes vulneráveis e desatualizados, falhas de autenticação, falhas de integridade, falhas de logging e monitoramento, e SSRF. Não é checklist de conformidade. É um mapa de onde as falhas costumam acontecer.

A LGPD não prescreve tecnologia. O artigo 46 exige medidas de segurança técnicas e administrativas; o artigo 48 trata da comunicação de incidentes relevantes à ANPD e ao titular; o artigo 37 fala do registro das operações de tratamento. A lei cobra capacidade de demonstrar controle, não a compra de um produto específico.

Hardening é a camada onde essa conversa se resolve: configuração, código e operação. Sem ele, OWASP vira relatório de pentest esquecido na gaveta e LGPD vira política assinada que ninguém consegue comprovar.

Onde o hardening encontra cada obrigação

  1. Controle de acesso por objeto, não só por tela. O OWASP coloca controle de acesso quebrado no topo da lista, e na LGPD isso conversa com o princípio da necessidade: o operador do faturamento não precisa abrir o laudo de um paciente.
  2. Criptografia em trânsito e em repouso, com gestão de chaves. TLS bem configurado, backup cifrado e segredos fora do repositório e fora da imagem do container.
  3. Validação de entrada e consultas parametrizadas. Injeção continua sendo falha de código, não de firewall.
  4. Gestão de dependências. Um componente desatualizado expõe dado pessoal sem que ninguém tenha escrito uma linha de código nova, e é o tipo de risco que só aparece quando alguém varre a árvore de pacotes.
  5. Logs úteis e minimizados. Registrar eventos de acesso ajuda a responder a incidente e a demonstrar controle, mas gravar CPF, senha ou resultado de exame no log cria uma base paralela de dados pessoais sem governança.
  6. Configuração segura de borda. Cookies com HttpOnly e SameSite, headers consistentes, ambientes de homologação sem cópia integral da base produtiva.

Um caso concreto: o portal do paciente de uma clínica

Uma clínica de médio porte mantém um portal em que o paciente baixa o laudo do exame. A URL é algo como /laudo?id=1042. Trocar o número devolve o laudo de outra pessoa, porque a aplicação verifica se o usuário está autenticado, mas não se aquele laudo pertence a ele. O log de acesso grava a URL completa e o CPF do titular em texto claro, o que amplia o problema em vez de ajudar a investigá-lo.

Não há vulnerabilidade exótica aqui: é controle de acesso ausente somado a um log mal desenhado. O hardening passa por autorização por objeto, identificadores não sequenciais, registro com identificador interno pseudonimizado, prazo de retenção definido e alerta para sequências de acesso fora do padrão.

O impacto no negócio não está no patch, que é pequeno. Está na resposta: dado de saúde é dado sensível, e um vazamento exige avaliação sobre comunicação à ANPD e ao titular, tempo de jurídico e de segurança, além do desgaste com o paciente que descobre que o laudo dele ficou acessível.

Na prática

Para quem mantém software em produção, o roteiro é menos glamouroso do que parece:

  • Mapear, por endpoint, quais dados pessoais trafegam e quem pode acessá-los. Essa lista é o começo de tudo.
  • Transformar os itens do OWASP em testes automatizados no pipeline: autorização por objeto, validação de entrada, verificação de dependências.
  • Revisar o que entra no log. Se o log permite identificar uma pessoa, ele é tratamento de dado pessoal e precisa entrar no inventário, com retenção e acesso controlados.
  • Definir descarte. Guardar tudo para sempre é passivo, não é segurança.
  • Ter um procedimento escrito de resposta a incidente, com papéis definidos e quem decide sobre a comunicação.

Hardening não é projeto com data de término. É a diferença entre afirmar que a aplicação está em conformidade e conseguir provar isso quando alguém perguntar.