A maioria das invasões não usa técnica de filme. Usa a porta que ficou aberta.

É o que mostra, ano após ano, o OWASP Top 10, o ranking mais respeitado de riscos de segurança em aplicações web, mantido pela Open Worldwide Application Security Project (owasp.org/Top10). As mesmas categorias de falha aparecem edição após edição, porque continuam funcionando: são erros de construção, não façanhas de gênio do mal.

Aqui estão as cinco que mais encontramos em avaliações de aplicações reais, traduzidas do "OWASPês" para o dia a dia, com a defesa de cada uma.

1. Controle de acesso quebrado

O nº 1 do ranking oficial. A tela esconde o botão de admin, mas a API aceita a chamada de qualquer usuário logado. Ou o clássico: /pedidos/1234 funciona, então /pedidos/1235 (do outro cliente) também.

A defesa: autorização se verifica no servidor, a cada requisição, nunca só na interface. Regra de ouro: negar por padrão, liberar por papel. E teste de QA hostil: "o que acontece se eu trocar o ID da URL?" (é o caminho hostil que já defendemos).

2. Injeção (SQL, comandos e amigos)

O formulário pergunta o nome; o atacante responde com código. Se a aplicação monta a consulta colando strings, o banco executa o que vier: vazamento, alteração ou destruição de dados.

A defesa: consultas parametrizadas (prepared statements) sempre, sem exceção heroica. ORMs modernos já fazem isso; o risco volta quando alguém "só dessa vez" concatena. Validação de entrada completa o cerco.

3. Autenticação e sessão frágeis

Senha sem limite de tentativas (convite para força bruta), tokens que não expiram, "esqueci minha senha" que entrega a conta, sessão que sobrevive ao logout.

A defesa: limite e atraso progressivo em tentativas, senhas verificadas contra listas de vazamento, MFA para contas sensíveis, sessões curtas e invalidadas no logout. Nada disso é exótico; tudo isso é esquecível na pressa da entrega.

4. Configuração insegura

O ambiente de produção com stack trace exposto, painel de admin com senha padrão, bucket de storage público, CORS liberado com asterisco, dependência de debug ligada. A vulnerabilidade não está no seu código: está no que ficou ligado por engano.

A defesa: ambientes descritos como código (auditáveis e reproduzíveis), hardening como checklist de deploy e a pergunta rotineira: "o que está exposto na internet que não precisaria estar?"

5. Componentes desatualizados

Sua aplicação é 10% código seu e 90% bibliotecas de terceiros. Cada CVE publicado num framework antigo é um manual de invasão para o seu sistema, com exploit pronto circulando em horas.

A defesa: inventário de dependências, atualização como rotina (não como projeto anual) e alertas automáticos de vulnerabilidade (Dependabot e afins) tratados com prioridade de bug. Software parado no tempo não é estável; é passivo acumulando juros.

O padrão: segurança é processo, não produto

Repare que nenhuma das cinco defesas é uma ferramenta cara. São hábitos de engenharia: autorização no servidor, query parametrizada, sessão bem gerida, configuração auditada, dependência atualizada. O relatório de investigações de violações da Verizon (DBIR) reforça o quadro todos os anos: a maior parte dos incidentes explora o básico mal feito, não o avançado (verizon.com/dbir).

A boa notícia embutida: quem faz o básico com disciplina já sai da mira da maioria dos ataques oportunistas, que varrem a internet procurando exatamente as cinco portas acima.

Quer saber quais dessas portas estão abertas aí?

Uma avaliação de segurança de aplicação (código, configuração e dependências, contra o OWASP Top 10 completo) é um dos trabalhos do nosso serviço de Cibersegurança e Proteção de Dados, com relatório priorizado por risco real, não por alarmismo.

Quer uma primeira leitura? Descreva sua stack para a IA da Rabelo Digital, aqui no canto da tela, e ela aponta os pontos de atenção típicos. Sem formulário, sem espera.

---

Leia também

• LGPD na prática para o seu produto
• Pen test: o que é e quando fazer
• Zero Trust: a arquitetura de segurança moderna