OWASP e LGPD olham o mesmo sistema por ângulos diferentes

OWASP descreve classes de falha técnica: controle de acesso quebrado, falhas de configuração, componentes desatualizados, injeção, exposição de dados sensíveis. É um catálogo de engenharia, útil para priorizar backlog de correção.

A LGPD não fala em cabeçalho HTTP nem em versão de biblioteca. Fala em finalidade, necessidade, segurança, prevenção e resposta a incidentes, e prestação de contas. Na prática, exige que você saiba onde há dado pessoal, quem acessa e por quê, e consiga demonstrar isso quando questionado.

As duas listas se encontram em um ponto: quase todo incidente de segurança em aplicação web é também um incidente envolvendo dados pessoais. Um endpoint que devolve o pedido de outro cliente não é apenas um bug de autorização. É exposição de dado pessoal, com dever de avaliar risco e decidir sobre comunicação a titulares e à autoridade.

Hardening que serve aos dois lados

Hardening aqui não é instalar ferramenta. É reduzir superfície de exposição de forma verificável.

  • Controle de acesso por objeto, no servidor, em toda rota. A verificação de autorização fica no backend, nunca só na tela. Cada requisição checa se o usuário autenticado pode acessar aquele registro específico.
  • Validação e parametrização: consultas preparadas, validação server-side e escape correto na saída eliminam classes inteiras de injeção.
  • Gestão de dependências com inventário de versões e rotina de atualização. Biblioteca sem dono é falha de configuração esperando data.
  • Sessão e credenciais: cookies com HttpOnly e SameSite, expiração curta, segundo fator para perfis administrativos, segredos em cofre e fora do repositório.
  • Cabeçalhos de segurança e CSP, junto com limite de requisições e proteção contra automação abusiva nas rotas de login e recuperação de senha.
  • Logs sem dado pessoal desnecessário. Log que grava CPF e endereço completo em texto claro replica a exposição dentro da infraestrutura e amplia o escopo de qualquer vazamento.
  • Minimização no schema: campo sem finalidade definida não deveria existir no formulário nem na tabela.
  • Segregação de ambientes e dado de produção fora de homologação. Cópia de base produtiva em ambiente de teste é um dos caminhos mais comuns de exposição silenciosa.

Exemplo: o portal do cliente de uma distribuidora

Uma distribuidora de médio porte mantinha um portal onde clientes pessoa jurídica consultavam pedidos e notas. A autorização era feita no front: a tela mostrava apenas os pedidos do cliente logado, mas a API aceitava qualquer identificador enviado na requisição. Quem soubesse montar a chamada obtinha pedidos de outras empresas, com valores, endereços de entrega e contatos.

Do ponto de vista OWASP, é controle de acesso quebrado, a categoria mais recorrente em aplicações corporativas. Do ponto de vista da LGPD, é tratamento de dados de terceiros sem base legal, com risco de dano aos clientes e obrigação de avaliar o incidente. O custo não está só na correção, que foi pequena: verificação de autorização no backend, por objeto. O caro foi descobrir tarde, revisar contratos, decidir sobre comunicação e lidar com a confiança comercial que a distribuidora levou anos para construir.

Na prática

Para quem mantém software em produção, a ordem que funciona:

  1. Inventarie onde há dado pessoal e quem acessa, por rota e por perfil. Sem esse mapa, OWASP vira lista genérica e LGPD vira política de gaveta.
  2. Trate controle de acesso quebrado como prioridade máxima, antes de qualquer item cosmético de segurança.
  3. Coloque atualização de dependências e revisão de configuração na esteira de entrega, com responsável definido.
  4. Defina o que fazer quando algo é encontrado: quem avalia, em quanto tempo e quem decide sobre comunicação. Resposta improvisada custa mais que o próprio incidente.
  5. Revise logs periodicamente. Se o log contém mais dado pessoal do que a operação precisa, ele é parte do problema.

Segurança de aplicação web é rotina de manutenção, não projeto com data de encerramento.