OWASP, LGPD e hardening respondem a perguntas diferentes

É comum tratar os três como sinônimos de "deixar o sistema seguro". Não são. OWASP é um catálogo de riscos técnicos (o Top 10 e o ASVS são os artefatos mais usados) e serve para responder: por onde um atacante entra? A LGPD é uma obrigação legal sobre dados pessoais e responde: quais dados estão no sistema, com que base legal, por quanto tempo e quem pode acessá-los? Hardening é disciplina operacional, reduzir superfície de ataque em configuração, permissões, dependências e defaults.

Quando o time mistura as três, o resultado típico é investimento mal alocado: um scanner rodando semanalmente que ninguém lê, uma política de privacidade publicada no site sem reflexo no banco de dados e um servidor de produção com debug ligado.

Uma forma simples de separar as responsabilidades:

  • OWASP: injeção, controle de acesso quebrado, falhas de autenticação e sessão, exposição de dados sensíveis, SSRF e dependências vulneráveis.
  • LGPD: inventário de dados pessoais, base legal, finalidade, retenção, atendimento a titulares, registro de operações e resposta a incidentes.
  • Hardening: variáveis de ambiente, segredos fora do repositório, cabeçalhos HTTP, menor privilégio no banco, debug e rotas de diagnóstico desligados em produção.

Onde a LGPD muda a prioridade técnica

Exemplo: uma clínica de médio porte com portal do paciente, agenda e prontuário eletrônico. O backlog de segurança estava ordenado apenas pela severidade técnica das falhas mapeadas no OWASP. Ao montar o inventário de dados pessoais, o time encontrou um endpoint de exportação de relatórios que incluía nome, CPF e telefone e aceitava um identificador sequencial na URL. Não era o item de maior pontuação técnica do backlog, mas era o que permitia extrair dados pessoais em volume sem verificação adequada de autorização.

A prioridade mudou. O controle de acesso subiu para o topo, junto com o registro de auditoria de quem consultou o quê. O custo de corrigir foi baixo: revisar a autorização do endpoint, trocar identificadores sequenciais e limitar a exportação por perfil. O custo de não corrigir envolveria comunicação a titulares, tratamento junto à ANPD, retrabalho jurídico e perda de confiança de pacientes.

Esse é o ponto que gestores costumam subestimar: a LGPD não é apenas um documento do jurídico. Ela altera o que é urgente no backlog de engenharia, porque muda a unidade de medida de "falha técnica" para "exposição de dado pessoal".

Hardening tem prazo de validade

Hardening não é um mutirão de uma semana. Toda configuração endurecida volta a ficar frouxa: uma dependência nova entra com vulnerabilidade conhecida, uma imagem base fica desatualizada, uma permissão de bucket é ampliada para "resolver" um chamado, uma chave de API é colada em um arquivo de configuração.

Por isso hardening precisa morar no ciclo de manutenção. Na prática, isso significa:

  1. Varredura de dependências no pipeline, com falha de build para vulnerabilidade crítica.
  2. Revisão periódica de permissões, incluindo usuários de banco, buckets e papéis na nuvem.
  3. Segredos em cofre, nunca no repositório nem em variável versionada.
  4. Revisão das rotas administrativas e de diagnóstico antes de cada release.
  5. Logs de aplicação sem dado pessoal em texto claro, para não criar um problema novo ao resolver outro.

Na prática

Para quem mantém software em produção, segurança se sustenta em rotina, não em evento. Um caminho que funciona:

  • Manter uma matriz simples ligando cada ativo a um dado pessoal, a um risco OWASP e a um controle existente. Se um item não tem dono, ele não será corrigido.
  • Fazer triagem mensal do backlog de segurança com dois critérios: gravidade técnica e volume de dado pessoal exposto. Os dois juntos definem a ordem de execução.
  • Automatizar testes de autorização. A falha mais comum não é criptografia quebrada, é um endpoint que deixou de checar se aquele usuário pode ver aquele registro.
  • Tratar hardening como manutenção contínua, com itens recorrentes na esteira de releases.
  • Ter um plano de resposta a incidente escrito, com quem decide, quem comunica e em quanto tempo, para a equipe não improvisar no pior momento.

Segurança de aplicações web madura é a soma de três coisas que não se substituem: um catálogo de riscos para saber onde olhar, uma obrigação legal para saber o que priorizar e uma disciplina operacional para impedir que o sistema volte a ficar exposto depois da próxima entrega.