OWASP Top 10: o guia do desenvolvedor para não ser invadido

Publicado pela Pentesty · Série para profissionais de segurança

Você não começou a programar com a intenção de criar código vulnerável. Ninguém começa.

Mas, todos os anos, as mesmas categorias de vulnerabilidades aparecem em aplicações em produção de todos os setores, tecnologias e tamanhos de equipe. O OWASP Top 10 existe porque esses não são erros aleatórios. São padrões previsíveis, o que significa que também podem ser evitados.

Este guia percorre cada categoria pela perspectiva de quem cria software. O foco é entender o que realmente acontece no seu código e como seria uma versão mais segura, em vez de apenas como um atacante explora a falha. Essa abordagem importa porque compreender a causa raiz é o que permite desenvolver sem repetir o padrão.

A01: quebra de controle de acesso

Esse é o risco número um da lista. Depois que você reconhece o padrão, começa a percebê-lo em todos os lugares.

O controle de acesso é a parte da aplicação que responde à pergunta: este usuário tem permissão para fazer isto? Quando ele falha, os usuários conseguem agir além das permissões previstas. Isso significa ler dados de outras pessoas, modificar registros que não lhes pertencem, acessar funções administrativas com uma conta comum ou elevar os próprios privilégios.

A falha geralmente não é dramática. É uma verificação ausente. Um desenvolvedor cria um recurso, configura a interface para exibi-lo apenas aos administradores e esquece de aplicar a mesma restrição ao endpoint da API chamado pela interface. O menu desaparece para os usuários comuns. O endpoint continua disponível.

Uma versão comum desse problema é uma aplicação que expõe /api/orders/4821 e não verifica se o usuário que fez a requisição é o dono do pedido 4821. Qualquer pessoa que descubra o padrão pode percorrer os pedidos de outras pessoas simplesmente alterando o número. Em nosso artigo anterior sobre relatórios de pentest, vimos como achados assim acabam enterrados nos resultados do scanner, sem contexto suficiente para priorização.

A correção não é complicada. Toda requisição que toca um recurso protegido precisa de uma verificação no servidor para confirmar se o solicitante tem o direito de fazer o que está pedindo. A interface não é uma camada de controle de acesso. O frontend não é uma fronteira de confiança.

Software de plataforma pode violar a mesma regra em escala: quando o estado da sessão é considerado confiável sem validação rigorosa, uma única falha de interpretação pode derrubar toda a fronteira de confiança. Para um exemplo real em hospedagem, veja nossa análise da CVE-2026-41940, injeção CRLF e desvio de autenticação no cPanel.

A02: falhas criptográficas

Essa categoria antes se chamava "Exposição de dados sensíveis", e esse nome era até mais útil. A questão não é a criptografia como conceito abstrato. É o que acontece com os dados sensíveis quando são armazenados ou transmitidos e se esse tratamento é adequado.

As falhas aqui aparecem de algumas formas.

Transmitir dados por conexões sem criptografia é a mais óbvia, em grande parte resolvida pela adoção do HTTPS. Mas isso ainda aparece na comunicação interna entre serviços, em backends de aplicativos móveis e em sistemas legados.

Armazenar dados sensíveis sem proteção adequada é mais comum. Senhas armazenadas em texto puro ou transformadas em hash com MD5 ou SHA-1 são, na prática, legíveis para qualquer pessoa que acesse o banco de dados. Esses algoritmos não foram projetados para armazenar senhas. bcrypt, scrypte Argon2 foram. São lentos por projeto, o que torna impraticáveis os ataques de força bruta contra eles.

Usar criptografia incorretamente é um problema mais sutil. Uma aplicação pode usar AES com uma chave fixa no código, reutilizar vetores de inicialização ou usar o modo ECB, que revela padrões nos dados. A presença de criptografia não significa que os dados estejam protegidos.

A pergunta que o desenvolvedor deve fazer é: cada dado tratado pela aplicação realmente precisa ser armazenado? Se sim, precisa ser armazenado de forma recuperável? Muitas vezes, a resposta à segunda pergunta é não, o que significa que o adequado é usar hash, e não criptografia reversível.

A03: injeção

A injeção acontece quando dados fornecidos pelo usuário são enviados a um interpretador como parte de um comando ou consulta, sem separação adequada da própria estrutura do comando. O interpretador não consegue distinguir entre "dados que o usuário forneceu" e "instruções que devo seguir".

SQL é o exemplo mais conhecido. Mas a mesma classe de vulnerabilidade existe na injeção de comandos do sistema operacional, de LDAP, de NoSQL e de templates, em que a entrada do usuário chega a um mecanismo de templates no servidor que a processa como código.

A correção conceitual é a mesma em todos os casos: usar interfaces parametrizadas que mantenham dados e instruções separados. Para SQL, isso significa consultas preparadas. Para comandos do sistema operacional, significa evitar completamente chamadas de shell com entrada do usuário ou usar APIs seguras que não invoquem um shell. Para templates, significa nunca renderizar a entrada do usuário como um template.

A validação de entrada ajuda, mas não é a defesa principal. A validação pode ser contornada. A parametrização impõe a separação no nível do interpretador, que é o que realmente importa.

A04: design inseguro

Essa categoria é mais recente na lista e aponta para algo que as outras não abordam: algumas vulnerabilidades não são falhas de implementação. São falhas de projeto.

Uma falha de implementação significa que o projeto era adequado, mas o código introduziu um problema. Design inseguro significa que a própria abordagem, mesmo implementada corretamente, ainda produziria um sistema inseguro.

Alguns padrões que se encaixam aqui:

Um fluxo de redefinição de senha que usa perguntas de segurança. Mesmo que o fluxo seja implementado perfeitamente, o problema está no projeto. As respostas às perguntas de segurança podem ser adivinhadas ou pesquisadas e não oferecem proteção significativa.

Uma aplicação multitenant que usa um banco de dados compartilhado com uma coluna tenant_id para separar os dados dos clientes. O projeto depende inteiramente de que todas as consultas filtrem corretamente pelo cliente. Uma cláusula WHERE esquecida expõe dados entre clientes. Um projeto que separa completamente os clientes no nível do banco de dados é mais robusto.

A implicação prática para desenvolvedores é pensar em segurança durante o projeto, antes da revisão de código. A modelagem de ameaças, mesmo informalmente, pergunta "o que pode dar errado com esta abordagem?" antes de escrever uma única linha. Isso custa muito menos do que adaptar a segurança a um projeto falho depois.

A05: configuração incorreta de segurança

Essa é uma das vulnerabilidades mais comuns em aplicações reais e também uma das mais evitáveis. Ela não exige um atacante engenhoso. Basta alguém encontrar o que ficou destrancado.

A configuração incorreta de segurança abrange uma ampla variedade de falhas: credenciais padrão que nunca foram alteradas, mensagens de erro que expõem rastros de execução e caminhos internos aos usuários finais, listagem de diretórios habilitada em um servidor web, recursos desnecessários ativados, como uma interface administrativa de banco de dados exposta à internet, buckets de armazenamento em nuvem com permissão pública de leituraou ausência de cabeçalhos de segurança nas respostas HTTP.

O hábito que mais ajuda aqui é tratar o ambiente de produção de forma diferente do ambiente de desenvolvimento. Mensagens detalhadas de erro são úteis durante o desenvolvimento. Em produção, são prejudiciais. O modo de depuração nunca deve chegar à produção. Credenciais padrão precisam ser alteradas antes da implantação.

A06: componentes vulneráveis e desatualizados

Sua aplicação vai além do seu código. Ela inclui cada biblioteca, framework e dependência de que o código depende, além das dependências dessas próprias dependências. Uma vulnerabilidade em qualquer uma delas é, na prática, uma vulnerabilidade na sua aplicação.

A vulnerabilidade Log4Shell, no fim de 2021, é o exemplo recente mais claro. Uma falha crítica em uma biblioteca Java de registro amplamente utilizada afetou uma quantidade enorme de aplicações em vários setores, muitas delas mantidas por equipes que nunca haviam pensado muito naquela dependência específica.

A causa da falha geralmente não é o desconhecimento desse risco em princípio. É que gerenciar dependências é um trabalho pouco atraente. As bibliotecas ficam fixadas em uma versão que funciona e raramente são revisadas. Um ano depois, essa versão tem vulnerabilidades conhecidas e ninguém a atualizou porque "funciona".

Use ferramentas automatizadas que acompanhem vulnerabilidades conhecidas na sua lista de dependências. GitHub Dependabot, Snyk e ferramentas semelhantes abrirão pull requests quando uma dependência em uso tiver uma CVE publicada. Permita esse processo. Revise e incorpore essas atualizações.

No setor financeiro, o alcance do impacto de um fornecedor fraco ou de uma integração sem correções não é teórico. Ele se mede em notificações a clientes e comunicações aos reguladores. Para entender como isso aparece quando um grande banco confirma acesso a dados de contas, leia nosso panorama do incidente do BTG Pactual.

A07: falhas de identificação e autenticação

A autenticação é o sistema que responde "quem é você?". Falhas nessa área significam que a resposta pode estar errada, ser contornada ou manipulada.

Padrões comuns: políticas fracas de senha, ausência de limitação de requisições que permite credential stuffing, tokens de sessão que não expiram ou não são devidamente invalidados ao sair.

A fixação de sessão é um caso sutil. Se a aplicação cria uma sessão antes da autenticação e depois eleva os privilégios dessa mesma sessão após o login, um atacante que introduza um token de sessão conhecido antes da entrada pode usá-lo para acessar a sessão autenticada depois. A correção é simples: gere novamente o identificador da sessão após qualquer evento de autenticação.

O uso incorreto de JWT é cada vez mais comum à medida que mais aplicações adotam autenticação baseada em tokens. Erros frequentes incluem usar o algoritmo "none", deixar de validar o algoritmo especificado no cabeçalho do token ou armazenar dados sensíveis no payload sem lembrar que JWTs são apenas codificados, não criptografados.

A autenticação multifator é o controle defensivo de maior impacto nessa categoria. Ela não resolve todos os problemas, mas aumenta significativamente o custo de tomar uma conta, mesmo quando as senhas estão comprometidas.

Incidentes reais reforçam essa lição: quando milhões de e-mails e nomes saem de uma plataforma de consumo, os atacantes imediatamente os usam em credential stuffing e spear phishing. Para um estudo de caso recente sobre os riscos posteriores a uma alegação de grande vazamento em uma plataforma de ensino, veja a análise do vazamento da Udemy e do ShinyHunters.

A08: falhas de integridade de software e dados

Essa categoria ganhou destaque depois que o ataque à SolarWinds demonstrou exatamente como é o comprometimento da integridade de software em escala.

A categoria abrange situações em que uma aplicação presume a integridade de atualizações de software, dados críticos ou componentes de pipelines de CI/CD sem verificar essas suposições. Se sua aplicação atualiza automaticamente um plugin sem verificar a assinatura da atualização, uma fonte comprometida entrega código malicioso que é automaticamente considerado confiável e instalado.

Para os desenvolvedores, a implicação mais prática está na cadeia de suprimentos. De onde vem seu código? De onde vêm suas dependências? Essas fontes são verificadas? Pipelines de CI/CD com permissões excessivas ou que usam fontes de terceiros sem verificar integridade representam uma exposição real.

A09: falhas de registro e monitoramento de segurança

Essa categoria é diferente das outras. A vulnerabilidade não é permitir que um atacante faça algo indevido. É ninguém perceber quando ele faz.

Registros e monitoramento insuficientes não causam invasões diretamente. Mas fazem com que elas permaneçam sem detecção por mais tempo, dificultam a investigação e eliminam a oportunidade de interromper um ataque durante sua execução.

Como são bons registros pela perspectiva de um desenvolvedor:

Eventos de autenticação devem ser registrados: logins bem-sucedidos, logins que falharam, redefinições de senha e eventos de MFA. O acesso a recursos sensíveis deve ser registrado com contexto suficiente para responder "quem acessou o quê, quando e de onde". Erros devem ser registrados detalhadamente no servidor, mas esses detalhes nunca devem ser apresentados ao usuário final.

Os registros precisam permitir consultas e ser retidos por tempo suficiente para serem úteis. Quando combinados com alertas de padrões anômalos, como excesso de falhas de login, acesso de uma região geográfica incomum ou em horários fora do padrão, eles deixam de ser registros passivos e se tornam detecção ativa.

A10: falsificação de requisições no servidor, ou SSRF

Ao criar um recurso que busca conteúdo remoto em nome de um usuário, você dá a ele algum controle sobre os destinos contatados pelo seu servidor. Isso é aceitável quando as entradas esperadas são URLs de recursos públicos. O problema surge quando nada impede que seu servidor seja direcionado a serviços internos, endpoints de metadados de nuvem ou outra infraestrutura que nunca deveria ser alcançável de fora.

As perguntas que o desenvolvedor deve fazer ao criar qualquer recurso de busca por URL:

Qual é o conjunto legítimo de URLs que esse recurso deve alcançar? É possível defini-lo em uma lista de permissões? Esse recurso precisa alcançar intervalos de IP internos, endereços de loopback ou infraestrutura privada de nuvem? Quase certamente não, o que significa que esses destinos devem ser bloqueados explicitamente.

Listas de permissões são mais fortes do que listas de bloqueio nesse caso. Existem formas demais de representar um endereço IP para que uma lista de bloqueio seja completa de maneira confiável.

O fio condutor

Ao ler as dez categorias em conjunto, surge um padrão que vale nomear explicitamente.

A maioria dessas vulnerabilidades não é exótica. Elas não são resultado de um atacante engenhoso que encontrou uma falha sutil. São falhas previsíveis que acontecem quando a segurança não faz parte do projeto e do desenvolvimento desde o início: falta de verificações, validação, registros, atualizações e comprovação.

Segurança não é um traço de personalidade nem uma disciplina separada que se delega a especialistas. É um conjunto de perguntas que você aprende a fazer em cada etapa da construção. O que pode dar errado com este projeto? O que acontece se esta entrada for maliciosa? O que este sistema registra quando algo ruim acontece? Como sei que esta dependência é segura?

Essas perguntas, feitas consistentemente, são o que o OWASP Top 10 procura ensinar. Para uma análise mais profunda de como essas vulnerabilidades aparecem em avaliações reais de segurança e por que frequentemente se perdem no ruído dos relatórios, leia nosso artigo sobre por que a maioria dos relatórios de pentest não leva à correção.

Na Pentesty, acreditamos que o conhecimento de segurança deve ser acessível a todas as pessoas que criam software, além dos especialistas. Se quiser se aprofundar em qualquer um desses temas, temos laboratórios estruturados e trilhas de aprendizado em pentesty.co que permitem explorar esses conceitos na prática, em ambientes seguros e legais.

Porque tudo começa na compreensão. É a prática que consolida o aprendizado.

Tem dúvidas sobre desenvolvimento seguro ou quer ver essas vulnerabilidades na prática? Obtenha acesso antecipado à Pentesty e explore laboratórios práticos para cada categoria da OWASP.