Segurança de aplicação web raramente falha por falta de ferramenta. Falha por ausência de método: ninguém definiu o que é risco aceitável, quem responde por ele nem como isso é verificado no código que entra em produção. Três referências organizam essa conversa: o OWASP como catálogo técnico de riscos, a LGPD como marco legal e o hardening como o conjunto de decisões de engenharia que reduz a superfície de ataque.

OWASP como catálogo de risco, não como selo

O OWASP Top 10 não é certificação nem checklist aplicada uma vez só, e não deve virar documento de conformidade arquivado. É uma lista priorizada de categorias de falha que aparecem com frequência em aplicações reais: controle de acesso quebrado, falhas de autenticação e de gestão de sessão, injeção, configuração incorreta, uso de componentes desatualizados, exposição de dados sensíveis e falhas de criptografia. A utilidade prática está em usar essas categorias como roteiro de revisão de arquitetura e de pull request. Vale traduzir cada uma para o vocabulário do negócio: controle de acesso quebrado significa que um usuário consegue abrir o pedido ou o cadastro de outro; configuração incorreta significa produção com mensagem de erro detalhada, expondo caminhos de arquivo e versões de biblioteca.

LGPD: o que a lei cobra de quem opera o sistema

A LGPD fala em medidas de segurança técnicas e administrativas, prevenção e responsabilização. Ela não prescreve biblioteca, framework nem arquitetura: cobra resultado e capacidade de demonstrar o que foi feito e por quê. Na prática, isso exige saber onde estão os dados pessoais, quem acessa cada conjunto, por quanto tempo ficam guardados e como um incidente seria detectado e comunicado. Um sistema que armazena CPF, endereço e dados de saúde sem controle por perfil, sem trilha de auditoria e sem criptografia dificilmente sustenta essa conversa durante uma fiscalização ou na resposta a um incidente.

O caso de uma clínica de médio porte ilustra bem. O portal de resultados entregava o laudo em PDF a partir de uma URL com o identificador do paciente. O backend verificava se havia sessão ativa, mas não se aquele usuário tinha vínculo com aquele paciente. Bastava trocar o número no fim do endereço para abrir o exame de outra pessoa. Não houve vazamento em massa divulgado, mas o caso teve de ser tratado como incidente envolvendo dado sensível de saúde: medir o alcance, revisar logs, comunicar os titulares afetados, corrigir a autorização no servidor e revisar todas as rotas com o mesmo padrão. A correção em si custou poucas linhas de código; o caro foi o processo de resposta e a auditoria de dezenas de endpoints semelhantes.

Hardening: reduzir a superfície de ataque em camadas

Hardening é a soma de decisões pequenas, aplicadas de forma constante:

  • Autorização no servidor para cada recurso: toda requisição verifica se o usuário autenticado pode acessar aquele objeto, não apenas se está logado.
  • Menor privilégio: a conta de banco usada pela aplicação não é a de administrador, e cada serviço recebe só as permissões de que precisa.
  • Sessão e autenticação: cookies com HttpOnly, Secure e SameSite, expiração coerente com o risco e segundo fator para acessos administrativos.
  • Entrada e saída tratadas: validação no servidor, consultas parametrizadas e codificação de saída contra injeção e XSS.
  • Produção sem excesso: debug desligado, erros genéricos, HTTPS obrigatório e cabeçalhos de segurança como CSP e HSTS ativos.
  • Dependências e segredos sob controle: varredura de bibliotecas no pipeline e credenciais em cofre, com rotação, nunca no repositório.
  • Logs úteis e discretos: identificador de requisição e trilha de auditoria, sem senha, token ou dado pessoal em texto claro.

Cada item isolado parece trivial. O resultado vem da constância: hardening é rotina de manutenção, não mutirão de uma semana antes da auditoria.

Na prática

Para quem mantém software em produção, alguns hábitos sustentam tudo isso:

  • Tratar verificação de autorização como item obrigatório de revisão em todo endpoint novo que devolva dado de cliente ou de pessoa.
  • Manter um inventário simples de onde há dado pessoal no sistema e qual finalidade justifica cada armazenamento.
  • Incluir atualização de dependências e rotação de segredos na rotina do time, com janela definida.
  • Escrever um procedimento curto de resposta a incidente: quem decide, quem comunica, o que fica registrado.
  • Revisar acessos de produção e permissões de ex-colaboradores periodicamente.
  • Testar a restauração do backup, não apenas a geração dele.

Segurança de aplicação web não é projeto com data de conclusão. É disciplina de manutenção que combina método (OWASP), obrigação legal (LGPD) e execução técnica (hardening) no sistema que a empresa já opera todos os dias.