OWASP Top 10: erros de segurança mais comuns em apps web

O OWASP Top 10 é a lista das dez categorias de vulnerabilidade mais críticas em aplicações web, mantida pela OWASP (Open Worldwide Application Security Project), organização sem fins lucrativos de referência em segurança de software. Corrigir esses dez pontos não elimina todo risco, mas já coloca sua aplicação à frente da maioria dos sistemas em produção. Este guia explica o que cada categoria significa na prática e como preveni-la, seja em Node.js, Python, PHP ou qualquer outra stack web usada em 2026.

O que é o OWASP Top 10 e por que ele ainda importa em 2026

O OWASP Top 10 é atualizado periodicamente com base em dados reais de milhares de aplicações analisadas por empresas de segurança parceiras do projeto. A lista completa e detalhada está disponível na documentação oficial do OWASP Top Ten, que também mantém o Cheat Sheet Series com exemplos de código seguro para cada categoria. Mesmo com o avanço de frameworks que já mitigam parte desses problemas por padrão, os dez riscos continuam aparecendo em auditorias porque nascem de decisões de arquitetura, não de bugs isolados.

Injection: quando dados do usuário viram código

Injection acontece quando dados enviados pelo usuário são inseridos diretamente em uma query, comando de sistema ou interpretador sem validação. O resultado mais comum é o SQL injection, que pode expor ou apagar uma tabela inteira do banco de dados.

A forma de evitar é simples e não tem exceção: nunca concatene dados do usuário em queries. Use prepared statements (ou parametrized queries): você define a estrutura da query com placeholders e passa os dados do usuário como parâmetros separados. O banco trata esse conteúdo como dado, nunca como código executável.

Aplicações que usam agentes de IA enfrentam uma variação moderna do mesmo problema: o prompt injection em agentes de IA, em que texto malicioso inserido no prompt tenta sequestrar as instruções do modelo. O princípio de defesa é o mesmo do injection clássico, tratar entrada externa sempre como dado não confiável.

Autenticação quebrada: senhas e sessões vulneráveis

Autenticação quebrada significa que um atacante consegue logar com credenciais inválidas, contornar o processo de login ou sequestrar a sessão de outro usuário.

Falhas comuns incluem armazenar senhas em texto plano, sessões que nunca expiram e tokens sem validação de assinatura. Nesses cenários, uma ferramenta automatizada testa milhares de combinações de senha por segundo até invadir uma conta.

Boas práticas de autenticação

• Hash de senha com algoritmo lento, como bcrypt ou Argon2, nunca MD5 ou SHA simples.
• Sessões com expiração definida e renovação segura.
• Tokens assinados e validados a cada requisição.
• Rate limiting em endpoints de login para dificultar força bruta.

Exposição de dados sensíveis

Toda aplicação armazena algum dado sensível: senhas, tokens de API, números de cartão, documentos pessoais. Se um invasor acessa o sistema, esses dados precisam estar protegidos, não disponíveis em texto plano.

Erros frequentes incluem dados sensíveis mantidos sem criptografia em memória ou banco, logs que registram senhas por engano, backups sem criptografia e tráfego trafegando em HTTP em vez de HTTPS.

A correção passa por HTTPS obrigatório em toda a aplicação, criptografia de dados sensíveis em repouso, segredos configurados em variáveis de ambiente (nunca hardcoded no código) e logs que nunca registram senhas ou tokens completos.

XML External Entities (XXE)

Se sua aplicação processa arquivos XML, um atacante pode inserir referências externas maliciosas que exploram o parser XML. O resultado vai da leitura de arquivos sensíveis do servidor até negação de serviço.

É um risco menos comum hoje, já que muitas APIs modernas usam JSON, mas continua crítico em sistemas legados ou integrações B2B baseadas em XML. A correção é direta: desabilite o processamento de external entities no parser XML, geralmente uma única linha de configuração.

Controle de acesso quebrado (Broken Access Control)

Controle de acesso correto garante que o usuário A veja apenas os dados de A, o usuário B veja apenas os de B, e que apenas administradores acessem funções administrativas. Quando essa regra falha, qualquer usuário autenticado pode acessar dados de outra conta.

Erros comuns incluem validar permissão apenas no frontend (o backend aceita a requisição de qualquer forma) e usar IDs sequenciais que permitem enumerar registros de outros usuários trocando um número na URL.

A correção exige verificar permissão no servidor para toda ação sensível, usar identificadores não sequenciais (UUID em vez de ID incremental) e aplicar whitelist de recursos permitidos por papel de usuário. O mesmo princípio de “verificar antes de agir” aparece em sistemas de IA que executam ações automatizadas: veja como o human in the loop em agentes de IA define pontos de pausa para aprovação humana antes de uma ação crítica ser executada.

Configuração de segurança incorreta

Acontece quando uma aplicação vai para produção com configurações de ambiente de desenvolvimento: modo debug ativo, senhas padrão não trocadas, stack traces expostos ao usuário final e headers HTTP que revelam a tecnologia usada no backend.

A correção passa por manter configurações separadas entre desenvolvimento e produção, usar senhas e segredos fortes e únicos por ambiente, desabilitar debug em produção e remover headers que vazam informação de infraestrutura. Quem faz deploy self-hosted também precisa gerenciar bem essas variáveis: o guia de n8n self-hosted no Docker mostra como isolar segredos e configurações sensíveis fora da imagem da aplicação.

Cross-Site Scripting (XSS): injetando JavaScript no navegador de outro usuário

No XSS, o atacante insere JavaScript malicioso em um campo do site. Quando outro usuário visualiza essa página, o script executa no navegador dele, permitindo roubo de cookies de sessão, redirecionamento para sites falsos ou phishing.

O erro típico é aceitar HTML ou JavaScript em formulários sem nenhum filtro. A correção envolve escapar todo dado do usuário antes de exibi-lo no HTML, aplicar Content Security Policy para restringir quais scripts podem rodar na página e sanitizar HTML apenas quando a aplicação realmente precisa aceitar formatação rica.

Cross-Site Request Forgery (CSRF): forçando ações sem consentimento

No CSRF, o usuário está autenticado em um sistema (por exemplo, um banco) e, ao visitar um site malicioso em outra aba, esse site dispara uma requisição para o banco se passando pelo usuário logado, sem que ele perceba.

A defesa correta combina tokens CSRF exclusivos por sessão e requisição, validação dos headers Origin e Referer no servidor, e cookies configurados com o atributo SameSite.

Componentes com vulnerabilidades conhecidas

Uma aplicação moderna depende de dezenas ou centenas de bibliotecas de terceiros. Basta uma delas ter uma vulnerabilidade conhecida e publicada para que um atacante explore essa falha através da sua aplicação, mesmo sem tocar no código próprio.

A prevenção envolve manter dependências sempre atualizadas, usar ferramentas de detecção automática de vulnerabilidades conhecidas (como Dependabot, Snyk ou o próprio npm audit) e remover pacotes que não são mais utilizados no projeto.

Logging e monitoramento insuficientes

Um padrão recorrente em investigações de incidentes de segurança: a equipe só descobre o ataque semanas depois, porque não havia logs suficientes, ou porque os logs existentes foram sobrescritos em poucas horas.

A correção exige registrar eventos de segurança relevantes (login, falha de autenticação, mudança de permissão), armazenar esses logs em local seguro e separado da aplicação, e monitorar em tempo real por padrões anômalos que indiquem tentativa de invasão.

Erros comuns ao aplicar o OWASP Top 10

O primeiro erro é tratar segurança como etapa final: construir a aplicação inteira e só depois pensar em proteção. O correto é considerar cada item do Top 10 desde o design da arquitetura, não como um checklist de última hora.

O segundo erro é acreditar que “ninguém vai atacar minha aplicação”. Talvez nenhuma pessoa específica ataque, mas bots automatizados varrem a internet constantemente em busca de falhas conhecidas, sem distinguir o tamanho ou a relevância do alvo.

O terceiro erro é confiar em segurança por obscuridade, esperando que uma falha não seja descoberta só porque não foi divulgada. A postura correta é assumir que qualquer vulnerabilidade será encontrada eventualmente e proteger o sistema de qualquer forma.

Perguntas frequentes

O que é o OWASP Top 10?

É a lista das dez categorias de vulnerabilidade mais críticas em aplicações web, mantida pela OWASP com base em dados reais coletados de milhares de sistemas em produção.

Quanto custa implementar as práticas do OWASP Top 10?

Custa pouco quando aplicado desde o início do projeto, e custa muito mais quando uma falha de segurança é descoberta depois que a aplicação já está em produção com dados reais de usuários.

Preciso de um especialista em segurança para seguir o OWASP Top 10?

Para sistemas críticos, sim, vale contratar uma auditoria especializada. Para a maioria das aplicações, seguir corretamente as dez categorias já reduz drasticamente o risco de invasão.

Como saber se minha aplicação já foi comprometida?

Só é possível saber com logs e monitoramento configurados corretamente. Sem registro de eventos de segurança, não há como identificar acessos indevidos, então a configuração de alertas para atividades anormais é essencial.

O OWASP Top 10 cobre segurança de aplicações que usam IA?

Cobre os fundamentos, mas aplicações com agentes de IA têm riscos adicionais específicos, como o prompt injection, que exigem camadas extras de validação além dos dez itens clássicos.

• Leia também:
• FastAPI do zero: criando uma API REST em Python em menos de uma hora
• PostgreSQL vs MongoDB: como escolher o banco certo para cada projeto
• Data contracts na prática: como evitar que dados quebrados derrubem sua IA

Arrume seu OWASP Top 10 hoje

Faça uma checagem simples: sua aplicação usa prepared statements? Senhas com hash forte? HTTPS em todas as rotas? Controle de acesso validado no servidor, não só no frontend?

Para cada resposta negativa, priorize a correção pelos itens de maior impacto, começando por injection e controle de acesso, que costumam causar os incidentes mais graves.