OWASP Top 10 explicado: as 10 maiores falhas de segurança web

Toda aplicação que você publica na internet vira, instantaneamente, um alvo. Bots varrem a web em busca de falhas conhecidas, e a maioria dos incidentes não exige um gênio do outro lado: explora erros previsíveis e repetidos. É exatamente esse padrão que o OWASP Top 10 tenta resumir, listando as categorias de risco mais comuns em aplicações web.

Neste guia você vai entender o que é a OWASP, por que o Top 10 virou referência mundial e o que significa cada uma das dez categorias da edição de 2021 — com defesas práticas que você pode aplicar mesmo em projetos pequenos ou gerados com ajuda de IA.

O que é a OWASP e o que é o Top 10

A OWASP (Open Worldwide Application Security Project) é uma fundação sem fins lucrativos dedicada à segurança de software. Ela mantém documentos, ferramentas e padrões abertos, todos gratuitos. O mais famoso deles é o OWASP Top 10, um documento de conscientização que reúne as dez categorias de risco mais críticas em aplicações web (OWASP Foundation, 2021).

É importante entender o que o Top 10 não é:

Ele é um ponto de partida. Para um trabalho mais rigoroso e verificável, a OWASP mantém o Application Security Verification Standard (ASVS), que define requisitos de segurança organizados por níveis de garantia (OWASP Foundation, 2021). Pense no Top 10 como o alerta de prioridades e no ASVS como o manual detalhado.

Como o Top 10 é construído

Vale entender de onde vêm esses números, porque isso muda como você lê a lista. A OWASP combina dados de muitas organizações — frequências de vulnerabilidades encontradas em testes reais — com uma pesquisa de comunidade para captar tendências que os dados ainda não mostram. Cada categoria é avaliada por critérios como incidência, explorabilidade, detectabilidade e impacto técnico. Por isso a lista são categorias amplas de risco, não falhas pontuais: "Injeção" engloba dezenas de variantes, e "Broken Access Control" cobre uma família inteira de problemas de autorização. Ler a lista assim — como mapas de território, não como bugs específicos — é o que a torna útil no dia a dia.

A01 — Broken Access Control (Quebra de controle de acesso)

Subiu para o primeiro lugar na edição de 2021. Ocorre quando um usuário consegue acessar dados ou ações que não deveriam estar disponíveis para ele. Exemplos clássicos:

A causa raiz quase sempre é confiar em dados que vêm do cliente. A defesa central é verificar permissões no servidor, sempre, em cada requisição, com base na identidade autenticada — nunca em parâmetros enviados pelo navegador. Aqui é fundamental não confundir os dois conceitos que sustentam o controle de acesso; vale a pena revisar Autenticação vs autorização: qual a diferença?.

Um ponto prático: a verificação de acesso deve recair sobre o recurso, não sobre a rota. Não basta esconder o botão de "editar" no frontend ou checar o papel na entrada da página; cada endpoint que toca um dado precisa confirmar que este usuário pode tocar aquele registro específico. Negar por padrão e liberar explicitamente — deny by default — é a postura correta.

A02 — Cryptographic Failures (Falhas criptográficas)

Antes chamada de "Sensitive Data Exposure", esta categoria trata de dados sensíveis mal protegidos: trafegados ou armazenados sem criptografia adequada, com algoritmos fracos ou chaves mal gerenciadas (OWASP Foundation, 2021). Sinais de alerta:

A correção começa por cifrar dados em trânsito (TLS) e em repouso, e por usar funções apropriadas para cada finalidade — hashing lento e com salt para senhas, cifragem simétrica ou assimétrica para sigilo.

Um erro recorrente é confundir as ferramentas: senha não se cifra, se faz hash com um algoritmo lento e salgado, projetado para resistir a força bruta. Cifrar senha é um antipadrão, porque pressupõe uma chave que, se vazar, expõe tudo. Para dados que você precisa recuperar (um número de cartão, por exemplo), aí sim use cifragem, com gestão cuidadosa de chaves. E lembre-se de classificar seus dados primeiro: você só protege adequadamente o que sabe que é sensível.

A03 — Injection (Injeção)

A categoria de injeção engloba qualquer caso em que entrada não confiável é interpretada como comando. O exemplo mais conhecido é o SQL Injection, mas também entram injeção de comandos de sistema, LDAP e outros. A lógica é sempre a mesma: o atacante mistura dados com código porque a aplicação não os separou corretamente.

A defesa universal é tratar entradas como dados inertes. Para bancos de dados, isso significa queries parametrizadas (prepared statements). Aprofunde no tema em O que é SQL Injection e como se proteger. O XSS, que é injeção de scripts no navegador, também pertence historicamente a esse universo — veja O que é XSS (Cross-Site Scripting)?.

Cuidado com a falsa sensação de segurança de um ORM: ele protege quando você usa seus métodos parametrizados, mas muitos ORMs oferecem "escotilhas" para SQL cru, e é aí que a injeção volta. A regra prática vale para qualquer interpretador (SQL, shell, XPath, template engine): nunca construa o comando concatenando entrada do usuário; passe os dados como parâmetros separados da estrutura do comando.

A04 — Insecure Design (Design inseguro)

Categoria nova em 2021, foca em falhas de arquitetura e modelagem, não de implementação. Você pode escrever um código impecável, mas ainda assim ter um sistema inseguro se o desenho não previu abusos: falta de limites de tentativa, fluxos de recuperação de senha frágeis, ausência de controles de negócio.

A defesa aqui não é um patch — é processo. Práticas como threat modeling ajudam a antecipar abusos ainda na fase de design. Esse é o assunto de Threat modeling: como pensar como um atacante.

Um exemplo ajuda a separar "insecure design" de "bug": imagine um e-commerce que permite resgatar um cupom sem limitar quantas vezes. Não há nenhuma linha de código errada — o código faz exatamente o que foi pedido. O problema é que ninguém modelou o abuso de resgatar o cupom mil vezes. Nenhum scanner pega isso; só pega quem se pergunta, no design, "como alguém abusaria deste fluxo?".

A05 — Security Misconfiguration (Configuração incorreta)

Servidores, frameworks e nuvens vêm com muitas opções, e configurações erradas abrem portas. Exemplos típicos:

A defesa é ter configurações padrão seguras, automatizadas e revisadas. Quanto menos superfície exposta, menor o risco.

Como configuração muda toda hora, automação é a única defesa que escala. Trate a infraestrutura como código, com revisão e auditoria, e adote o princípio do menor privilégio: cada serviço, conta e bucket começa fechado e só recebe a permissão estritamente necessária. Reduzir a superfície — desligar recursos não usados, remover contas de exemplo, fechar portas — costuma eliminar classes inteiras de problema de uma vez.

A06 — Vulnerable and Outdated Components (Componentes vulneráveis e desatualizados)

Aplicações modernas dependem de dezenas ou centenas de bibliotecas. Quando uma delas tem falha conhecida e você não atualiza, herda o problema. O caso Log4Shell mostrou como uma única dependência pode comprometer milhares de sistemas.

Defenda-se com:

Vale acrescentar que o problema é transitivo: você não depende só do que instalou diretamente, mas de tudo que essas bibliotecas, por sua vez, puxam. Um único npm install pode trazer centenas de pacotes indiretos. Por isso, manter um inventário automatizado (um SBOM, Software Bill of Materials) e integrar a varredura de vulnerabilidades ao pipeline de CI/CD — falhando o build quando aparece uma CVE crítica — é mais eficaz do que checagens manuais esporádicas.

A07 — Identification and Authentication Failures (Falhas de identificação e autenticação)

Antes chamada de "Broken Authentication", cobre fraquezas no processo de provar quem é o usuário: senhas fracas permitidas, ausência de proteção contra força bruta, sessões mal gerenciadas, tokens previsíveis. Boas defesas incluem:

Duas ameaças merecem destaque por serem muito comuns. O credential stuffing explora o fato de pessoas reusarem senhas: o atacante testa, em massa, pares de e-mail e senha vazados de outros sites. MFA e detecção de logins anômalos são as defesas mais eficazes. E o gerenciamento de sessão precisa de atenção contínua: gere o identificador de sessão de novo após o login, invalide o token no logout de verdade (no servidor, não só apagando o cookie) e defina expirações sensatas. As recomendações modernas, aliás, favorecem senhas longas e a checagem contra listas de senhas vazadas, em vez de regras de complexidade que só geram frustração.

A08 — Software and Data Integrity Failures (Falhas de integridade)

Categoria nova, ligada a confiar em código ou dados sem verificar sua integridade. Inclui:

A defesa passa por assinaturas digitais, verificação de origem e proteção da cadeia de suprimentos de software.

Esse risco ganhou enorme relevância com os ataques de cadeia de suprimentos, em que o atacante compromete uma dependência ou uma etapa do build para envenenar o produto de todo mundo que o usa. As contramedidas envolvem verificar a integridade do que você instala (checksums e assinaturas), fixar versões exatas de dependências (em vez de aceitar qualquer atualização automaticamente) e proteger as credenciais e o ambiente do seu pipeline com o mesmo rigor de um servidor de produção — porque, na prática, ele é produção.

A09 — Security Logging and Monitoring Failures (Falhas de log e monitoramento)

Sem registros e alertas, ataques passam despercebidos por semanas. Esta categoria não causa a invasão diretamente, mas amplia o estrago ao retardar a detecção e a resposta. Defesas:

Há um equilíbrio delicado aqui: você quer registrar o suficiente para detectar e investigar incidentes, mas sem gravar dados sensíveis nos logs — senhas, tokens, números de cartão jamais devem aparecer ali, sob risco de o próprio log virar um vazamento. Logue o evento ("falha de login para o usuário X a partir do IP Y"), não o segredo. E lembre-se de que log sem alerta é quase inútil: de nada adianta registrar tudo se ninguém é avisado quando o padrão suspeito acontece.

A10 — Server-Side Request Forgery (SSRF)

Entrou no Top 10 por votação da comunidade. No SSRF, o atacante força o servidor a fazer requisições para destinos que ele não deveria alcançar — por exemplo, serviços internos ou endpoints de metadados na nuvem. A defesa central é validar e restringir, no servidor, os destinos que a aplicação pode acessar, usando listas de permissão em vez de listas de bloqueio.

O cenário clássico é uma funcionalidade que busca uma URL fornecida pelo usuário (um "importe a imagem deste link", por exemplo). Se não houver controle, o atacante aponta para http://169.254.169.254/, o endpoint de metadados de muitos provedores de nuvem, e pode extrair credenciais temporárias da instância. Por isso a defesa não pode ser uma denylist (que sempre deixa escapar formatos como IPs em decimal ou redirecionamentos): use uma allowlist de domínios permitidos, valide o IP resolvido e bloqueie faixas de rede internas.

Como usar o Top 10 no dia a dia

Em vez de tratar a lista como teoria, transforme-a em hábitos:

Esse cuidado é ainda mais importante quando boa parte do código é escrita por assistentes de IA, que podem reproduzir padrões inseguros sem aviso. Vale ler Segurança do código gerado por IA: cuidados essenciais para entender os riscos específicos desse fluxo de trabalho.

Perguntas frequentes

O Top 10 cobre toda a segurança da minha aplicação? Não. Ele é um documento de conscientização sobre os riscos mais comuns, um ponto de partida. Para cobertura abrangente e verificável, use o ASVS, e considere testes de invasão para validar na prática.

Com que frequência o Top 10 é atualizado? A cada poucos anos. A edição de referência atual é a de 2021. Como são categorias amplas, os princípios envelhecem devagar, mesmo que detalhes mudem.

Por que controle de acesso virou o número 1? Porque os dados mostraram que falhas de autorização são extremamente frequentes e têm alto impacto. É difícil automatizar a verificação de "este usuário pode fazer isto?" porque depende da lógica de negócio, então erros se acumulam.

Sou só um dev solo com um projeto pequeno. Isso vale para mim? Sim, e talvez mais ainda. Bots não distinguem alvos grandes de pequenos; eles varrem tudo. As três primeiras categorias — acesso, criptografia e injeção — já protegem você contra a maioria dos ataques automatizados.

Conclusão

O OWASP Top 10 não promete cobrir tudo, mas oferece o melhor mapa público das falhas que mais derrubam aplicações web. As três primeiras categorias — controle de acesso, falhas criptográficas e injeção — sozinhas explicam uma fatia enorme dos incidentes. Internalizar esses padrões, validar permissões no servidor, tratar toda entrada como hostil e apoiar-se no ASVS para requisitos detalhados já coloca seu projeto muito à frente da média. Segurança não é um recurso que você adiciona no fim: é uma forma de pensar que acompanha cada decisão de design e cada linha de código.

Referências