GitHub

Toda aplicação web é, na prática, uma porta aberta para o mundo. Você pode caprichar na fechadura ou pode deixar a chave embaixo do tapete. A maioria dos times, sem perceber, escolhe a segunda opção, não por incompetência, mas porque segurança raramente é tratada como requisito desde o início.

A pergunta que faço a qualquer time é simples: se um atacante decidisse atacar você hoje, quanto tempo levaria? A resposta honesta costuma ser desconfortável. E o problema quase nunca é falta de tecnologia. É falta de fundamento.

Este artigo é sobre esses fundamentos. Não sobre a ferramenta da moda, mas sobre os princípios que sustentam uma aplicação web que merece confiança.

Por que segurança virou problema de negócio

Houve um tempo em que segurança era assunto restrito ao time de infraestrutura. Hoje é problema de CEO, de conselho e de reputação.

Um vazamento de dados não é só um bug. É manchete, é multa, é cliente perdido. No Brasil, a LGPD trouxe consequências concretas para quem trata dado pessoal sem cuidado. Mas mesmo sem regulação, o custo de um incidente sempre foi alto, só ficou mais visível.

O ponto é que segurança deixou de ser detalhe técnico e virou variável de negócio. Quem lidera produto ou tecnologia precisa entender isso para decidir onde investir.

A tese: segurança é arquitetura, não verniz

Minha posição é direta. Segurança não é uma camada que você adiciona depois que o produto está pronto. É uma propriedade que emerge das decisões que você toma desde o começo.

Times que tratam segurança como tarefa final, uma revisão antes do lançamento, um pentest às pressas, estão apenas comprando a ilusão de proteção. O pentest encontra os sintomas. A arquitetura define se a doença existe.

Quando segurança é fundamento, ela aparece em como você modela dados, em como você autentica usuários, em como você confia (ou desconfia) de entradas. Quando é verniz, ela aparece num relatório que ninguém lê.

Os fundamentos que realmente importam

Vou ser pragmático. Há dezenas de tópicos possíveis, mas alguns fundamentos resolvem a maior parte dos problemas reais.

Nunca confie na entrada do usuário

A maioria das vulnerabilidades clássicas, injeção de SQL, cross-site scripting, manipulação de parâmetros, nasce do mesmo erro: confiar em dados que vêm de fora.

A regra é simples e inegociável: toda entrada é hostil até prova em contrário. Valide no servidor, sempre. Validação no navegador é experiência do usuário, não segurança, ela é trivialmente contornável.

Use consultas parametrizadas no banco. Escape saídas conforme o contexto. Trate uploads de arquivo como código potencialmente malicioso. Esses cuidados parecem óbvios, mas continuam sendo a causa de incidentes que viram notícia.

Autenticação e autorização são coisas diferentes

Autenticação responde "quem é você". Autorização responde "o que você pode fazer". Confundir os dois é receita para desastre.

O erro mais comum que vejo: aplicações que verificam se o usuário está logado, mas não verificam se ele tem permissão para acessar aquele recurso específico. O resultado é o clássico problema em que o usuário A consegue ver os dados do usuário B só trocando um número na URL.

Autorização precisa ser checada no servidor, em cada requisição sensível, nunca presumida pelo que a interface mostra. Esconder um botão não protege nada.

Gerencie segredos como segredos

Senhas, chaves de API, tokens de acesso. Esses dados não pertencem ao código-fonte, não pertencem ao repositório e definitivamente não pertencem a um arquivo de configuração versionado.

Senhas de usuários devem ser armazenadas com algoritmos de hash projetados para isso, não com criptografia reversível, muito menos em texto puro. Use bibliotecas consolidadas. Criptografia caseira é uma das formas mais rápidas de criar um problema que você não vai detectar até ser tarde.

Criptografia em trânsito não é opcional

Todo tráfego deve usar HTTPS. Não há justificativa razoável para o contrário hoje. Dados que trafegam sem criptografia podem ser interceptados, e isso inclui credenciais.

Mas atenção: HTTPS protege o caminho, não o destino. Uma aplicação pode ter um cadeado verde no navegador e ainda assim armazenar senhas em texto puro. Criptografia em trânsito e em repouso são camadas distintas, e ambas importam.

O que a OWASP nos ensina

Quando alguém me pergunta por onde começar, minha resposta é quase sempre a mesma: comece pela OWASP.

O OWASP Top 10 é uma lista das vulnerabilidades mais críticas em aplicações web, mantida pela comunidade e atualizada periodicamente. Não é um padrão burocrático, é um mapa das ameaças que de fato causam dano.

O valor dela não está em decorar a lista, mas em usá-la como linguagem comum no time. Quando todo mundo entende o que é controle de acesso quebrado ou falha de configuração de segurança, as conversas técnicas ficam mais objetivas e as decisões mais informadas.

Recomendo transformar o Top 10 em parte do processo: uma revisão leve, mas consistente, que pergunta "estamos expostos a algum desses riscos?" antes de cada entrega relevante.

Os erros culturais que sabotam a segurança

A parte mais difícil de segurança não é técnica. É cultural.

O primeiro erro é tratar segurança como responsabilidade de uma pessoa ou de um time isolado. Segurança é responsabilidade de quem escreve código, de quem desenha produto e de quem prioriza o backlog. Quando vira tarefa de alguém, vira tarefa de ninguém.

O segundo erro é o teatro de segurança: políticas extensas que ninguém segue, processos que existem no documento mas não no dia a dia. Segurança real é discreta e operacional, não um manual na gaveta.

O terceiro, e talvez o mais perigoso, é a falsa sensação de que "isso não vai acontecer comigo". Aplicações pequenas são atacadas o tempo todo, muitas vezes por automação que não escolhe alvo. Ser pequeno não é proteção.

Segurança como vantagem, não como custo

Há uma maneira melhor de enxergar tudo isso. Segurança bem-feita não é apenas defesa, é diferencial.

Em setores que lidam com dados sensíveis, como saúde, finanças e o setor público, confiança é moeda. Um produto que demonstra cuidado com dados ganha vantagem sobre um concorrente que trata o tema com descaso. Para gestores públicos, isso é ainda mais crítico: o dado do cidadão não é ativo da organização, é responsabilidade.

Investir em fundamentos de segurança não freia a inovação. Pelo contrário, dá a base sólida sobre a qual você pode construir rápido sem medo de que tudo desabe.

Segurança não é o que você faz quando sobra tempo. É o que define se o produto que você está construindo merece existir.

Se a sua organização está desenvolvendo aplicações web e segurança ainda é um assunto deixado para o fim, vale a pena revisitar essa prioridade. Tenho outros artigos no blog sobre LGPD, criptografia e arquitetura segura, e estou sempre aberto a trocar ideias com quem leva esse tema a sério.

Segurança em aplicações web: os fundamentos que ninguém pode ignorar