OWASP Top 10 explicado para desenvolvedores

O OWASP Top 10 é a lista de referência mais conhecida da segurança de aplicações web. Publicada pela Open Worldwide Application Security Project, uma organização sem fins lucrativos, ela reúne as dez categorias de risco de segurança mais críticas e comuns em aplicações web. A lista é revisada periodicamente, e a versão vigente é a de 2021, ainda a referência principal em 2026.

Para um desenvolvedor, conhecer o OWASP Top 10 não é opcional. É o conjunto mínimo de riscos que você precisa entender para não construir aplicações vulneráveis. Este texto percorre as dez categorias com foco no que importa para quem escreve código: o que é, como acontece e como se defender.

A01 – Quebra de controle de acesso

Controle de acesso define quem pode fazer o quê. A quebra acontece quando um usuário consegue agir fora das suas permissões: acessar dados de outro usuário, executar ações administrativas sem ser admin, ou modificar recursos que não lhe pertencem. Um caso clássico é trocar um identificador na URL e acessar o registro de outra pessoa, uma falha conhecida como referência direta insegura a objetos.

A defesa é verificar a autorização no servidor, sempre, para cada requisição. Nunca confie no cliente para decidir o que pode ser acessado. Esconder um botão na interface não protege nada, porque a requisição pode ser feita diretamente. O identificador do usuário e seu papel devem vir de um token verificado no servidor, nunca de um parâmetro que o cliente controla. Esta categoria subiu ao topo da lista porque é ao mesmo tempo comum e devastadora.

A02 – Falhas criptográficas

Esta categoria cobre a proteção inadequada de dados sensíveis, seja em trânsito ou em repouso. Inclui transmitir dados sem criptografia, usar algoritmos fracos ou obsoletos, armazenar senhas de forma reversível e gerenciar chaves de forma descuidada. O impacto é o vazamento de informação que deveria ser secreta, como senhas, dados pessoais ou financeiros.

As defesas são conhecidas. Use sempre conexões criptografadas para dados sensíveis. Armazene senhas com funções de hash próprias para isso, como bcrypt ou argon2, nunca com hashes de propósito geral e jamais em texto puro. Não invente sua própria criptografia; use bibliotecas consolidadas. E classifique seus dados: você precisa saber o que é sensível para saber o que proteger.

A03 – Injeção

Injeção acontece quando dados não confiáveis são interpretados como comando. O exemplo mais famoso é a injeção de SQL, em que uma entrada do usuário é concatenada em uma consulta e altera sua lógica, permitindo ler ou destruir dados. Mas o conceito é mais amplo e inclui injeção de comandos do sistema operacional, de LDAP e outras.

A defesa central é nunca misturar dados com comandos por concatenação de strings. Para bancos de dados, use consultas parametrizadas, também chamadas de prepared statements, em que os valores viajam separados da estrutura da consulta. Essa única prática elimina a esmagadora maioria das injeções de SQL. Complementarmente, valide as entradas contra o que é esperado e trate qualquer dado externo como potencialmente hostil.

A04 – Design inseguro

Esta é uma categoria mais ampla e conceitual, introduzida para chamar atenção a falhas que nascem na fase de projeto, não de implementação. Um código perfeitamente escrito pode ser inseguro se a arquitetura por trás dele for falha. Exemplos incluem não prever limites de taxa, não pensar em fluxos de recuperação de conta que podem ser abusados, ou confiar em suposições que um atacante quebra.

A defesa é incorporar segurança desde o desenho, uma prática às vezes chamada de modelagem de ameaças. Antes de implementar, pergunte como cada funcionalidade pode ser abusada. Estabeleça padrões seguros que se repetem no projeto. Segurança não é uma camada que se adiciona no fim; é uma propriedade que precisa ser projetada desde o começo, como discutimos no texto sobre segurança em aplicações que usam IA.

A05 – Configuração de segurança incorreta

Muitas brechas não estão no código, mas na configuração. Servidores com opções padrão inseguras, mensagens de erro que vazam detalhes internos, serviços expostos que deveriam estar fechados, permissões amplas demais, componentes de exemplo deixados em produção. Configuração errada é uma das causas mais frequentes de incidentes justamente porque é fácil de negligenciar.

A defesa passa por endurecer a configuração de forma sistemática. Remova o que não é usado, feche o que não precisa estar aberto, personalize mensagens de erro para não vazar detalhes, e mantenha ambientes de desenvolvimento e produção separados. Automatizar a configuração ajuda a garantir que ela seja consistente e auditável, em vez de ajustada à mão e esquecida.

A06 – Componentes vulneráveis e desatualizados

Aplicações modernas dependem de dezenas ou centenas de bibliotecas de terceiros. Quando uma dessas dependências tem uma vulnerabilidade conhecida e você não a atualiza, sua aplicação herda o problema. Muitos ataques de grande escala exploraram exatamente falhas conhecidas em componentes que as vítimas não haviam corrigido.

A defesa é conhecer e manter suas dependências. Tenha um inventário do que você usa e em qual versão. Acompanhe alertas de vulnerabilidade e atualize quando surgirem correções. Ferramentas de análise de dependências automatizam boa parte disso, avisando quando uma biblioteca do seu projeto tem falha conhecida. Remova dependências que você não usa mais; cada uma é superfície de ataque.

A07 – Falhas de identificação e autenticação

Esta categoria trata de falhas nos mecanismos que confirmam quem é o usuário. Inclui permitir senhas fracas, não proteger contra tentativas repetidas de login, gerenciar sessões de forma insegura e implementar recuperação de senha de modo abusável. Autenticação quebrada permite que um atacante se passe por outro usuário.

As defesas incluem exigir senhas razoáveis e verificá-las contra listas de senhas vazadas, oferecer autenticação de múltiplos fatores, limitar tentativas de login, e gerar identificadores de sessão de forma imprevisível usando geradores criptográficos, nunca funções de aleatoriedade comuns. A sessão deve expirar e ser invalidada corretamente no logout. Reutilizar soluções de autenticação testadas costuma ser mais seguro do que construir a sua do zero.

A08 – Falhas de integridade de software e dados

Esta categoria, introduzida em 2021, cobre a confiança indevida em código ou dados sem verificar sua integridade. Inclui atualizações de software sem verificação de assinatura, dependências vindas de fontes não confiáveis, e desserialização insegura, em que dados serializados de origem duvidosa são reconstruídos em objetos e acabam executando código.

A defesa é verificar a integridade do que você consome. Use fontes confiáveis para dependências e confira assinaturas quando disponíveis. Proteja seu pipeline de build e deploy, porque comprometê-lo é uma forma poderosa de ataque, conhecida como ataque à cadeia de suprimentos. E trate dados serializados de origem externa com extrema cautela, validando antes de processar.

A09 – Falhas de registro e monitoramento

Você não pode responder a um ataque que não percebe. Esta categoria trata da ausência ou insuficiência de registros e monitoramento que permitiriam detectar e investigar incidentes. Sem logs adequados, uma invasão pode passar despercebida por meses, e depois é impossível reconstruir o que aconteceu.

A defesa é registrar eventos relevantes de segurança, como logins, falhas de autenticação e acessos a recursos sensíveis, de forma que permitam auditoria. Monitore esses registros ativamente, com alertas para padrões suspeitos. Ao mesmo tempo, cuide para que os próprios logs não virem um problema, evitando gravar dados sensíveis neles. Observabilidade não é só operação; é uma peça de segurança.

A10 – Falsificação de requisição do lado do servidor

A última categoria, conhecida pela sigla SSRF, acontece quando uma aplicação busca um recurso a partir de uma URL fornecida pelo usuário sem validá-la. Um atacante pode fazer o servidor requisitar endereços internos, acessando serviços que deveriam estar isolados da internet, como metadados de nuvem ou sistemas internos.

A defesa é validar e restringir os destinos que o servidor pode acessar. Use listas de permissão de endereços autorizados em vez de tentar bloquear os proibidos. Isole a rede de forma que serviços internos não sejam alcançáveis a partir da aplicação sem necessidade. E nunca confie cegamente em uma URL que veio do usuário para fazer uma requisição no servidor.

Como usar esta lista no dia a dia

O OWASP Top 10 não é uma checklist que você marca uma vez e esquece. É um conjunto de riscos para manter em mente ao longo de todo o desenvolvimento. Ao escrever um formulário, pense em injeção e controle de acesso. Ao lidar com autenticação, revise a categoria correspondente. Ao adicionar uma dependência, lembre dos componentes vulneráveis.

Se você quer ir além da defesa e aprender a encontrar essas falhas ativamente, o texto sobre introdução ao pentest web mostra o outro lado da moeda: como testar aplicações procurando exatamente essas vulnerabilidades.

Não confunda o Top 10 com segurança completa

Um mal-entendido perigoso é tratar o OWASP Top 10 como uma lista de tudo que precisa ser feito. Ele é, por definição, apenas os dez riscos mais críticos e comuns, não um catálogo exaustivo. Existem muitas outras vulnerabilidades relevantes que não entram no top 10, e a própria OWASP mantém listas específicas para contextos particulares, como uma dedicada aos riscos de aplicações que usam modelos de linguagem, cada vez mais importante à medida que a IA entra nos produtos.

O valor do Top 10 está em ser um piso, não um teto. Uma equipe que domina essas dez categorias eliminou a maior parte do risco realista, e isso já é enorme. Mas segurança é um processo contínuo, não uma checklist que se completa. Testes regulares, revisões de código com olhar de segurança e acompanhamento de novas ameaças fazem parte do trabalho permanente. Use o Top 10 como ponto de partida sólido e siga aprendendo a partir dele.

Conclusão

As dez categorias do OWASP Top 10 cobrem a maior parte dos incidentes de segurança em aplicações web, e o mais importante é que quase todas têm defesas conhecidas e diretas. Autorização verificada no servidor, consultas parametrizadas, criptografia adequada, dependências atualizadas, configuração endurecida e registros úteis já eliminam uma fatia enorme do risco. Segurança de aplicações não costuma exigir soluções exóticas; exige disciplina em aplicar consistentemente práticas que já conhecemos. Comece internalizando estas dez categorias e você já estará à frente da maioria.