Segurança de aplicação web raramente falha por falta de ferramenta. Falha porque as conversas acontecem separadas: o time técnico fala em OWASP, o jurídico fala em LGPD e a operação fala em disponibilidade. O resultado é um programa que não existe de fato, apenas documentos e um scanner contratado.

OWASP descreve a falha, não a sua prioridade

O OWASP Top 10 é um catálogo de classes de falha: controle de acesso quebrado, falhas de configuração, componentes desatualizados, injeção, autenticação frágil. Ele diz o que costuma dar errado em aplicações web, não o que dá errado no seu sistema. Transformar esse catálogo em prioridade é trabalho de engenharia: mapear quais rotas tocam dados pessoais, quais aceitam entrada de usuário e quais expõem operações administrativas.

Um caso comum: uma distribuidora de médio porte com portal de pedidos para clientes. A tela esconde o botão de cancelamento de quem não é gerente, mas a rota de API aceita o cancelamento de qualquer sessão autenticada. É controle de acesso quebrado no servidor, com a regra implementada apenas na interface. Nenhum scanner aponta isso sozinho, porque encontrar a falha exige entender o modelo de permissão do negócio.

LGPD transforma falha técnica em obrigação legal

A LGPD não exige tecnologia específica. Exige medidas técnicas e administrativas adequadas (art. 46) e comunicação de incidente relevante à ANPD e aos titulares (art. 48). Na prática, isso muda o peso de decisões pequenas: guardar CPF em log de aplicação por tempo indeterminado, usar base de produção em ambiente de homologação, manter conta de serviço com permissão total no banco.

O princípio da necessidade tem efeito direto no código: coletar o dado mínimo, reter pelo prazo mínimo, mascarar o que não é essencial para a operação. Um relatório interno que exibe CPF completo quando o time de atendimento só precisa dos quatro últimos dígitos é uma decisão técnica com consequência jurídica.

Hardening é rotina, não projeto

Hardening é reduzir superfície de ataque com decisões repetíveis, aplicadas a cada mudança que entra em produção. Os itens abaixo são básicos e continuam sendo os mais negligenciados:

  • autorização validada no servidor em toda requisição, nunca apenas na interface
  • mensagens de erro genéricas para o usuário e detalhe técnico restrito ao log interno
  • cookies de sessão com HttpOnly, Secure e SameSite, com TLS obrigatório
  • dependências atualizadas com prazo definido, não com a lógica de quando sobrar tempo
  • ambientes separados, sem dado real em homologação e em testes automatizados
  • menor privilégio em contas de serviço, usuários de banco e integrações
  • retenção e mascaramento definidos para logs, backups e exports

Cada item é barato isoladamente e caro quando vira incidente. O custo real não é o retrabalho de corrigir a falha, é a resposta ao incidente: identificar o alcance, avaliar risco aos titulares, comunicar, lidar com suporte e com a confiança do cliente.

Na prática

Quem mantém software em produção deveria tratar segurança como parte do ciclo de mudança, não como auditoria anual. Isso se traduz em alguns acordos simples com o time:

  1. Toda alteração que cria rota nova passa por revisão explícita de autorização, com pergunta registrada: quem pode chamar isso e como o servidor verifica?
  2. Toda migration que adiciona campo de dado pessoal passa por revisão de necessidade e de prazo de retenção, antes de ir para produção.
  3. Toda dependência crítica tem prazo de atualização acordado e alguém responsável por ele.
  4. O inventário de dados pessoais é atualizado quando o sistema muda, não quando o jurídico pede.
  5. O plano de resposta a incidente é testado em simulação, porque descobrir o processo no meio do incidente custa caro.

O programa único é esse: o OWASP entrega o vocabulário da falha, a LGPD entrega o critério de risco e o hardening é a execução que impede que os dois se encontrem em uma notificação de incidente.