devly
Voltar para Secure Coding

Os Vilões Mais Comuns: Entendendo OWASP Top 10 (Versão Dev)

Introdução ao OWASP Top 10 com exemplos práticos de todas as 10 categorias de vulnerabilidades mais críticas para desenvolvedores.

Atualizado em: 4 de Junho, 2025
Notas do Autor

Beleza, Dev! Na aula anterior, firmamos o pacto: segurança é nossa responsa. Agora, vamos conhecer os "vilões" mais procurados no mundo do desenvolvimento web: o famoso OWASP Top 10.

Calma, não precisa decorar uma lista complexa. A ideia aqui é te apresentar as ameaças mais comuns de forma direto ao ponto e com foco no código, para que você consiga identificar e, principalmente, evitar essas armadilhas no seu dia a dia. Pense nisso como um "guia de campo" para reconhecer os perigos antes que eles causem problemas sérios.

Entender esses riscos é crucial para qualquer dev que queira construir aplicações robustas e seguras, especialmente para o mercado gringo, onde a barra de segurança é alta. Vamos encarar esses vilões?


Nesta aula, vamos desvendar:

  1. A01: Broken Access Control
  2. A02: Cryptographic Failures
  3. A03: Injection
  4. A04: Insecure Design
  5. A05: Security Misconfiguration
  6. A06: Vulnerable and Outdated Components
  7. A07: Identification and Authentication Failures
  8. A08: Software and Data Integrity Failures
  9. A09: Security Logging and Monitoring Failures
  10. A10: Server-Side Request Forgery (SSRF)

1. A01:2021 - Broken Access Control 🚪

Papo Reto do Dev 💬

Nunca confie no que vem do front-end. Sempre verifique no back-end se o usuário logado tem permissão para acessar o dado ou executar a ação solicitada.

Ocorre quando restrições sobre o que usuários autenticados podem fazer não são devidamente aplicadas. Isso permite que usuários acessem funcionalidades ou dados para os quais não têm permissão, explorando falhas como URLs desprotegidas, IDs sequenciais em URLs que permitem acesso a outros registros, ou falta de checagem de permissão no backend.

Exposição de IDs de objeto direto na URL (ex: /user/123/edit) sem verificar se o usuário logado é o 123 ou um admin.
Falha ao validar no backend se o usuário tem permissão para realizar uma ação, mesmo que a UI esconda o botão.
Permissões baseadas em papéis (roles) mal configuradas ou muito amplas.
CORS (Cross-Origin Resource Sharing) mal configurado, permitindo acesso de origens não confiáveis.

Alerta de B.O. 🚨

Sempre valide permissões no backend! O frontend pode ser manipulado.

2. A02:2021 - Cryptographic Failures (antes Sensitive Data Exposure) 📄

Papo Reto do Dev 💬

Use HTTPS para tudo. Para senhas, use um algoritmo de hash forte e com salt (ex: Argon2, bcrypt). Não "reivente" a criptografia.

Cobre falhas relacionadas à criptografia (ou ausência dela) que levam à exposição de dados sensíveis, tanto em trânsito (sem HTTPS) quanto em repouso (senhas em texto plano, dados de cartão de crédito não criptografados).

Não usar HTTPS em todas as páginas do site.
Armazenar senhas em texto plano ou com algoritmos de hashing fracos e sem salt (ex: MD5, SHA1).
Usar algoritmos criptográficos fracos, obsoletos ou com configurações inseguras.
Gerenciamento inadequado de chaves criptográficas (ex: chaves hardcoded no código).
Expor dados sensíveis em logs ou mensagens de erro.

A regra de ouro: proteja dados sensíveis como se fossem seus. Use HTTPS sempre, hash forte e com salt para senhas (ex: Argon2, bcrypt), e criptografia para dados sensíveis em repouso quando necessário.


3. A03:2021 - Injection 💉

Papo Reto do Dev 💬

Sempre use Parameterized Queries (ou Prepared Statements). Nunca construa queries concatenando strings com input do usuário. Faça o "escape" de dados antes de renderizá-los no HTML para evitar XSS.

Falhas de injection ocorrem quando dados não confiáveis são enviados para um interpretador como parte de um comando ou query. O mais famoso é o SQL Injection, mas também pode acontecer com NoSQL, OS, LDAP, XSS (Cross-Site Scripting) etc.

Exemplo (SQL Injection - Conceitual em Node.js com string concatenada):

javascript
// ROTA VULNERÁVEL
app.get('/user/:id', (req, res) => {
  const userId = req.params.id; // Ex: usuário digita '1 OR 1=1'
  const query = `SELECT * FROM users WHERE id = ${userId}`; // PERIGO!
  // ... executa a query ...
});

Se um atacante insere algo como ' OR '1'='1 no lugar do ID, a query pode se tornar SELECT * FROM users WHERE id = '' OR '1'='1', retornando todos os usuários! A defesa principal? Parameterized Queries (Prepared Statements) e Input Validation.

Cross-Site Scripting (XSS) é um tipo específico de injection onde scripts maliciosos são injetados em sites confiáveis. Ocorre quando sua aplicação inclui dados não confiáveis em uma página web sem a devida validação ou "escape" (codificação).

html
// URL: http://example.com/search?query=<script>alert('XSS_ALERT!')</script>

// No template (vulnerável):
<div>
  Você buscou por: {{ unsafeQueryParameter }}
</div>

Se unsafeQueryParameter não for devidamente tratado (encoded), o script será injetado na página e executado no navegador do usuário. A defesa envolve Output Encoding apropriado.


4. A04:2021 - Insecure Design 🏗️

Papo Reto do Dev 💬

Pense nos possíveis abusos das funcionalidades que você cria. Segurança começa no design, não como um remendo no final. Questione: "Como um atacante poderia usar isso de forma maliciosa?".

Esta é uma categoria mais ampla que foca em falhas relacionadas a deficiências no design e arquitetura de segurança da aplicação. Não se trata de uma falha de implementação específica, mas de riscos que poderiam ter sido evitados com um planejamento de segurança mais robusto desde o início (Shift Left Security).

Falta de modelagem de ameaças (threat modeling) durante a fase de design.
Processos de negócio com lógica falha que pode ser explorada (ex: um sistema de votação que permite votos ilimitados de um mesmo usuário).
Proteções insuficientes para casos de uso críticos (ex: recuperação de senha frágil).
Exposição desnecessária de funcionalidades ou informações sensíveis.
Confiança excessiva em controles do lado do cliente, sem validação robusta no servidor.

Fica a Dica 💡

Insecure Design ressalta a importância de pensar em segurança como parte integral do ciclo de vida de desenvolvimento, não como um item a ser adicionado no final.

5. A05:2021 - Security Misconfiguration ⚙️

Papo Reto do Dev 💬

Não use configurações padrão. Desabilite features de debug em produção, troque senhas padrão e remova serviços ou portas desnecessárias. Automatize o "hardening" do seu ambiente.

Configurações de segurança incorretas são uma das vulnerabilidades mais comuns. Isso pode incluir desde deixar features de debug habilitadas em produção, usar contas padrão, não aplicar patches de segurança, ou ter listagem de diretórios habilitada no servidor web.

Serviços ou portas desnecessárias abertas no servidor.
Contas padrão (admin/admin) não alteradas.
Mensagens de erro excessivamente detalhadas que expõem informações do sistema.
Frameworks de aplicação com configurações de segurança padrão não otimizadas (ex: verbos HTTP desnecessários habilitados).
Permissões de arquivo e diretório muito permissivas.
Cabeçalhos de segurança HTTP importantes (CSP, HSTS, X-Frame-Options) ausentes ou mal configurados.

Fica a Dica 💡

Um processo de hardening regular (revisar e fortalecer as configurações de segurança) é essencial para servidores, frameworks e aplicações.

6. A06:2021 - Vulnerable and Outdated Components 🧩

Papo Reto do Dev 💬

Mantenha suas dependências atualizadas. Use ferramentas como Dependabot (GitHub) ou Snyk para automatizar a verificação de vulnerabilidades conhecidas (CVEs) em suas bibliotecas.

Aplicações modernas dependem fortemente de componentes de terceiros (bibliotecas, frameworks). Se esses componentes possuem vulnerabilidades conhecidas e não são atualizados, sua aplicação herda esses riscos.

Usar bibliotecas com vulnerabilidades publicamente conhecidas (CVEs).
Não ter um inventário dos componentes e suas versões.
Processos de atualização de dependências inexistentes ou muito lentos.
Usar software sem suporte ou que não recebe mais patches de segurança.

Caixa de Ferramentas 🛠️

Ferramentas como npm audit, yarn audit, GitHub Dependabot, Snyk ajudam a identificar e gerenciar vulnerabilidades em dependências.

7. A07:2021 - Identification and Authentication Failures (antes Broken Authentication) 🔑

Papo Reto do Dev 💬

Exija senhas fortes, implemente Multi-Factor Authentication (MFA) e proteja os tokens de sessão. Invalide a sessão no logout. Não crie sua própria lógica de autenticação se não for um especialista.

Vulnerabilidades relacionadas à confirmação da identidade do usuário, autenticação e gerenciamento de sessão. Podem permitir que atacantes comprometam senhas, chaves, tokens de sessão, ou explorem falhas de implementação para assumir identidades de outros usuários.

Permitir senhas fracas, comuns ou credenciais padrão.
Não proteger adequadamente os tokens de sessão (ex: enviá-los via URL, cookies inseguros).
Sessões que não expiram ou não são invalidadas corretamente após o logout ou período de inatividade.
Mecanismos de recuperação de senha inseguros (ex: baseados em perguntas secretas fáceis de adivinhar).
Ausência de proteção contra ataques de força bruta (ex: rate limiting, CAPTCHA, account lockout).
Não implementar Multi-Factor Authentication (MFA) para funcionalidades críticas.

Alerta de B.O. 🚨

Autenticação forte é a porta de entrada da sua aplicação. Use bibliotecas testadas e siga as melhores práticas.

8. A08:2021 - Software and Data Integrity Failures ⛓️

Papo Reto do Dev 💬

Cuidado com a desserialização de dados de fontes não confiáveis. Garanta que seu pipeline de CI/CD verifique a integridade das dependências para evitar "supply chain attacks".

Esta categoria foca em falhas relacionadas à integridade do software e dos dados, como código ou infraestrutura que não protege contra alterações não autorizadas. Isso inclui, por exemplo, atualizações de software inseguras ou a inclusão de código de fontes não confiáveis sem verificação.

Desserialização insegura de dados de fontes não confiáveis, podendo levar à execução remota de código.
Pipelines de CI/CD que não verificam a integridade dos artefatos ou dependências (ex: supply chain attacks).
Falta de assinatura digital em atualizações de software ou firmware.
Modificação de dados críticos sem mecanismos de detecção ou prevenção.

Visão de Águia 🦅

Garantir a integridade significa que o código e os dados são o que deveriam ser, e não foram adulterados por um atacante.

9. A09:2021 - Security Logging and Monitoring Failures 🕵️

Papo Reto do Dev 💬

Faça log de eventos importantes de segurança (logins, falhas de login, acesso a dados sensíveis). Configure alertas para atividades suspeitas. Sem visibilidade, você está cego para um ataque em andamento.

Sem logging e monitoramento adequados, é difícil detectar e responder a incidentes de segurança. Muitas vezes, as brechas só são descobertas por terceiros.

Eventos de segurança importantes (logins, falhas de login, acessos negados, alterações críticas) não são logados.
Logs são armazenados de forma insegura ou não são protegidos contra adulteração.
Não há alertas para atividades suspeitas em tempo hábil.
Os logs não são monitorados ou analisados regularmente.
Logs não contêm informações suficientes para entender o que aconteceu.

Alerta de B.O. 🚨

Se você não está monitorando, você não vai ver o ataque chegando. Um bom logging é o seu sistema de câmeras de segurança.

10. A10:2021 - Server-Side Request Forgery (SSRF) 💻➡️

Papo Reto do Dev 💬

Valide e sanitize todas as URLs fornecidas pelo usuário que seu servidor vai acessar. Use uma "allow-list" de domínios e protocolos permitidos. Nunca deixe o servidor fazer requisições para endereços arbitrários.

Uma vulnerabilidade de SSRF ocorre quando um atacante consegue forçar o servidor a fazer requisições para um local escolhido por ele. Isso pode ser usado para vazar informações, escanear a rede interna ou interagir com serviços internos que não deveriam estar expostos.

Uma funcionalidade que busca um recurso com base em uma URL fornecida pelo usuário (ex: importador de imagens de uma URL) sem validar adequadamente essa URL.
Exposição de metadados de serviços cloud (ex: AWS EC2 Instance Metadata Service) através de SSRF.
Acesso a sistemas internos que o servidor tem permissão para acessar, mas o usuário externo não deveria.

Alerta de B.O. 🚨

SSRF é perigoso porque transforma seu servidor em um pivô para ataques internos. Sempre trate URLs externas como dados não confiáveis.

💊 Pílula Devly

Ufa! Cobrimos muita coisa. O OWASP Top 10 é denso, mas entender essas categorias é um superpoder para qualquer dev. Não se preocupe em ser um expert em tudo de uma vez. O importante é começar a reconhecer esses padrões e pensar: "Como isso poderia afetar o código que estou escrevendo agora?". Nas próximas aulas, vamos focar nas técnicas de codificação defensiva para combater esses vilões na prática. Continue firme!

Anterior

Segurança Não é 'Problema dos Outros'

Voltar

Próximo

Escrevendo Código que Resiste

Continuar