Segurança de aplicação web raramente falha por falta de ferramenta. Falha por falta de processo: um controle configurado uma vez, nunca mais revisado, cria sensação de proteção que não se sustenta no primeiro incidente. OWASP, LGPD e hardening só produzem resultado quando operam no mesmo fluxo, com dono, rotina e evidência.

O que o OWASP entrega e o que ele não entrega

O OWASP Top 10 organiza riscos em categorias conhecidas: controle de acesso quebrado, falhas de autenticação, injeção, configuração incorreta, componentes desatualizados, falhas de integridade e de logging. Serve como priorização e como vocabulário comum entre o time técnico e quem aprova orçamento.

O que ele não entrega: contexto jurídico e operacional. O Top 10 não diz quais campos da sua aplicação são dados pessoais, quem pode acessá-los, por quanto tempo ficam guardados, nem como provar que um acesso indevido foi detectado. Essa parte vem do mapeamento do fluxo de dados da própria operação, não do checklist.

LGPD: segurança que precisa ser demonstrável

A lei não determina tecnologia. Determina que o tratamento tenha base legal, finalidade, minimização e segurança, e que a empresa consiga demonstrar isso. Traduzindo para engenharia:

  • inventário de dados: quais campos são pessoais, por que existem e quem os consome;
  • autorização por papel, revisada periodicamente, com atenção especial a endpoints de exportação;
  • criptografia em trânsito e em repouso, incluindo backups e ambientes de teste;
  • política de retenção executada por rotina, com expurgo ou anonimização do que não precisa mais existir;
  • log de auditoria sem vazar conteúdo: registrar quem acessou, quando e de onde, não o dado em si;
  • plano de resposta a incidente com responsável e prazo definidos.

Nenhum item dessa lista é resolvido por biblioteca. Todos dependem de decisão de arquitetura e de disciplina de operação.

Hardening: reduzir superfície sem travar o time

Hardening é subtração antes de ser adição: desligar endpoints que ninguém usa, remover contas e permissões esquecidas, esconder stack trace em produção, validar entrada no servidor, manter dependências atualizadas no ciclo de entrega, guardar segredos fora do código e aplicar cabeçalhos de segurança. Cada item reduz a quantidade de coisas que podem dar errado sem que ninguém perceba.

Caso concreto: uma distribuidora de insumos com portal B2B de pedidos encontrou, durante uma revisão, três problemas comuns. A sessão não expirava, o que é grave em computador compartilhado no balcão do cliente. O endpoint de exportação devolvia a base inteira para qualquer usuário autenticado. E os logs gravavam CPF e endereço completo em texto puro. Nenhum dos três exigia ataque sofisticado. A correção foi priorizada em um ciclo curto: autorização verificada no servidor, expiração de sessão, mascaramento dos campos de log e trilha de auditoria. O ganho não foi só técnico: quando um cliente questionou quem havia consultado seus dados, a empresa conseguiu responder com registro, não com suposição.

Na prática

Quem mantém software em produção precisa transformar esses três temas em rotina verificável:

  1. Inclua verificação de autorização no aceite de toda história que cria ou altera endpoint, especialmente os de listagem e exportação.
  2. Rode análise de dependências no pipeline e trate falha crítica como bloqueio de release, não como aviso ignorado.
  3. Versione a configuração de produção junto com o código, para que ninguém dependa de memória ou de acesso manual ao servidor.
  4. Revise permissões quando alguém muda de função ou sai do time; acesso órfão é um dos furos mais silenciosos.
  5. Feche cada release com três perguntas: o que mudou na superfície de ataque, quais dados pessoais novos passaram a ser coletados e quem consegue acessá-los.

Segurança de aplicação não é um projeto com data de encerramento. É um conjunto pequeno de decisões repetidas a cada entrega, com registro suficiente para responder a um cliente, a um auditor ou a um incidente real.