OWASP Top 10 (2021/2025): Os Riscos Mais Críticos em Aplicações Web

OWASP Top 10: O Padrão de Referência da Segurança Web

O OWASP (Open Web Application Security Project) é uma fundação sem fins lucrativos dedicada a melhorar a segurança de software. Fundada em 2001, produz documentação, ferramentas, vídeos e fóruns gratuitos e abertos sobre segurança de aplicações. O mais conhecido dos seus deliverables é o OWASP Top 10 — uma listagem periódica das dez vulnerabilidades mais críticas em aplicações web.

A versão atual, publicada em 2021, trouxe mudanças significativas: três categorias novas (Insecure Design, Software and Data Integrity Failures, SSRF), a fusão de antigas entradas e uma reorganização baseada em dados do setor. A próxima atualização, prevista para 2025, deve refletir o aumento de ataques de supply chain, o impacto de IA na superfície de ataque e a consolidação de APIs como vetor primário de exploração.

A01 — Broken Access Control

O que é

Broken Access Control ocorre quando um usuário consegue acessar dados ou funcionalidades para as quais não tem permissão. Foi promovido ao #1 em 2021 e permanece como a vulnerabilidade mais explorada na prática.

Tipos de quebra de controle de acesso

• Horizontal privilege escalation — usuário A acessa dados do usuário B no mesmo nível.
• Vertical privilege escalation — usuário comum acessa funcionalidades administrativas.
• IDOR (Insecure Direct Object Reference) — acesso direto a objetos manipulando identificadores. Exemplo: logado como /user/999, alterar para /user/1000 e visualizar os dados de outro usuário.
• Directory traversal — https://site.com/download?file=../../../../etc/passwd

Exemplo prático de exploração

# IDOR em endpoint de perfil
GET /api/v1/users/1001/profile
Authorization: Bearer <token_do_user_1000>

# Resposta: dados completos do user 1001 — sem nenhuma verificação
# de ownership no backend

Como defender

• Implementar RBAC (Role-Based Access Control) ou ABAC (Attribute-Based).
• Deny by default: nenhuma rota é pública até ser explicitamente autorizada.
• Validar ownership de recursos em todas as requests (não só no frontend).
• Desabilitar directory listing no servidor web.
• Nunca usar identificadores sequenciais previsíveis sem validação — UUIDs ajudam mas não substituem checagem de permissão.

A02 — Cryptographic Failures

O que é

Antes chamada de “Sensitive Data Exposure”, essa categoria engloba falhas relacionadas à criptografia — ou ausência dela. O foco é como os dados sensíveis são protegidos (ou não), tanto em trânsito quanto em repouso.

Exemplos comuns

• Senhas armazenadas em plaintext ou com hash fraco como MD5/SHA1.
• Sites operando exclusivamente em HTTP sem TLS.
• Certificados autoassinados em produção.
• Dados sensíveis (SSN, cartão de crédito) transmitidos sem criptografia.

Exemplo prático de exploração

# Dump de hashes MD5 de um banco de dados comprometido
# Se o hash for md5("admin123"):
admin:$1$3f2e8a7b$c97f1f2e...   # MD5 crypt — quebrável em segundos com hashcat
# hashcat -m 0 hashes.txt rockyou.txt → plaintext em segundos

Como defender

• Senhas: usar bcrypt, scrypt ou Argon2id com salt. Nunca MD5, nunca SHA1.
• Trânsito: TLS 1.2+ em todas as conexões. HSTS header habilitado.
• Repouso: AES-256 para dados em disco. Key management com rotation.
• Nunca armazenar dados sensíveis desnecessariamente — minimização de dados.
• Classificar dados e aplicar criptografia proporcional à sensibilidade.

A03 — Injection

O que é

Injection permanece entre as vulnerabilidades mais perigosas e prevalentes. O atacante envia dados maliciosos que o interpretador da aplicação executa como comando. Inclui SQL injection, NoSQL injection, OS command injection, LDAP injection, XPath injection e outras variações.

Impacto potencial

• Data exfiltration — dump completo do banco de dados.
• Authentication bypass — login sem credenciais válidas.
• RCE (Remote Code Execution) — execução de comandos no servidor via OS command injection.
• Full system compromise — leitura de arquivos, pivoting, persistência.

Exemplo prático de exploração

# SQL Injection clássica (auth bypass)
username: admin' OR '1'='1' --
password: qualquer_coisa

# Query resultante: SELECT * FROM users WHERE user='admin' OR '1'='1' --' AND pass='...'
# O '--' comenta o resto da query. Login bem-sucedido.

# OS Command Injection
https://site.com/tools/ping?host=127.0.0.1;cat /etc/shadow
# Se o backend faz: ping -c 3 $host
# O ';' separa comandos → executa cat /etc/shadow no servidor

Como defender

• Prepared statements / parameterized queries — a defesa primária contra SQLi.
• ORMs — Hibernate, SQLAlchemy, Prisma abstraem a construção de queries.
• Input validation — whitelist de caracteres permitidos, não blacklist.
• Escaping — último recurso, nunca primário. Contexto depende (HTML, SQL, OS, LDAP).
• Princípio do menor privilégio — a conta do banco não deve ser root.
• Para OS commands: evitar completamente. Usar bibliotecas nativas sempre que possível.

A04 — Insecure Design

O que é

Nova categoria em 2021, Insecure Design é fundamentalmente diferente das outras: não é um bug de implementação, é uma falha arquitetural. O sistema funciona exatamente como foi projetado — o problema é que o design não considerou cenários de abuso.

Características

• Ameaças nunca modeladas durante o design.
• Fluxos que permitem ações em sequência perigosa (ex: resgatar cupom sem limite).
• Falta de rate limiting no design (não é configuração, é ausência de design).
• Sistemas que confiam exclusivamente no cliente para validação de regras de negócio.

Exemplo prático

# E-commerce: endpoint de recuperação de senha
# Design permite enviar email de reset para QUALQUER endereço,
# não apenas o email cadastrado.
# Um atacante pode resetar a senha do admin e receber o token
# em um email que controla.

# Fix de design: validar que o email solicitado pertence à conta,
# exigir MFA adicional, limitar resets por hora.

Como defender

• Threat modeling — usar frameworks como STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) na fase de design.
• Secure SDLC — segurança incorporada desde os requisitos.
• Abuse cases — além de use cases, documentar como o sistema PODE ser abusado.
• Security by design — não adicionar segurança depois como patch.
• Referência: OWASP Application Security Verification Standard (ASVS).

A05 — Security Misconfiguration

O que é

Configurações inseguras são absurdamente comuns. Incluem desde detalhes sutis (header HTTP faltante) até falhas grotescas (credenciais padrão em produção). Essa categoria responde por uma parcela enorme dos breaches documentados.

Exemplos comuns

• Debug habilitado em produção (DEBUG=True em Django, stack traces visíveis).
• Headers de segurança ausentes (X-Frame-Options, Content-Security-Policy, X-Content-Type-Options).
• Credenciais padrão (admin/admin, root/root) em serviços expostos.
• Cloud buckets S3 configurados como public.
• Diretórios listing habilitados no servidor web.
• Versões desatualizadas do servidor com vulnerabilidades conhecidas.

Exemplo prático de exploração

# S3 bucket público com dados sensíveis
aws s3 ls s3://empresa-backup --no-sign-request
# Retorna: BACKUP_2024.tar.gz, client_db.sql, employee_records.csv

# Stack trace exposto em produção
# Basta enviar um payload inválido e ler o erro completo:
# "SyntaxError at /api/users - Line 42: cursor.execute('SELECT * FROM ...')"
# → revela estrutura da query, tabela, e caminho absoluto do arquivo

Como defender

• Hardening — seguir guidelines específicas (CIS Benchmarks, OWASP Secure Configuration).
• Automated scanning — ferramentas como ScoutSuite, Prowler, Scout do AWS.
• Remover defaults — mudar todas as credenciais padrão antes de deploy.
• Environment separation — configs de dev nunca em prod. Arquivos separados.
• Desabilitar features desnecessárias — cada módulo a menos é uma superfície de ataque a menos.

A06 — Vulnerable and Outdated Components

O que é

Aplicações modernas são construídas sobre camadas de dependências — frameworks, bibliotecas, pacotes npm, gems, imagens Docker. Se qualquer componente tiver uma vulnerabilidade conhecida (CVE), toda a aplicação está em risco. E esse risco é sistemático, não pontual.

Casos reais de impacto

• Log4Shell (CVE-2021-44228) — vulnerabilidade RCE no log4j (Java). Afetou praticamente toda a internet que usava Java. CVSS 10.0.
• SolarWinds (2020) — supply chain attack. Atacantes comprometeram o build pipeline do Orion e distribuíram backdoor assinada com certificado legítimo da SolarWinds.
• Heartbleed (2014) — OpenSSL permitia leitura de 64KB de memória por heartbeat. Certificados, chaves, tudo exposto.

Exemplo prático de exploração

# npm audit em projeto real
$ npm audit
# found 47 vulnerabilities (12 low, 8 moderate, 19 high, 8 critical)

# Critical: Prototype Pollution in lodash < 4.17.21
# Um atacante que controlar a propriedade __proto__ pode
# poluir o prototype de todos os objetos → alterar comportamento
# da aplicação, bypass de autenticação, RCE

Como defender

• SCA (Software Composition Analysis) — ferramentas como Snyk, OWASP Dependency-Check, WhiteSource.
• SBOM (Software Bill of Materials) — inventário completo de componentes (obrigatório em setores regulados como governo dos EUA).
• Patch management — processos automatizados de atualização: npm audit fix, Dependabot, Renovate.
• Monitoramento contínuo — assinar alertas de CVE dos componentes utilizados.
• Remover dependências não utilizadas — menos código = menos superfície de ataque.

A07 — Identification and Authentication Failures

O que é

Anteriormente “Broken Authentication”, essa categoria cobre falhas na verificação de identidade. Quando a autenticação é fraca, o resto da aplicação vira irrelevante do ponto de vista de segurança.

Exemplos comuns

• Senhas fracas permitidas (“123456”, “password”).
• Credential stuffing — reuso de credenciais vazadas automatizado contra múltiplos serviços.
• Brute-force sem rate limiting ou account lockout.
• Sessões com IDs previsíveis ou não invalidadas no logout.
• MFA (Multi-Factor Authentication) implementada mas bypassável.

Exemplo prático de exploração

# Credential stuffing com hydra
hydra -L usernames.txt -P rockyou.txt site.com http-post-form \
  "/login:user=^USER^&pass=^PASS^:Invalid credentials"

# Sem rate limiting: 1000 tentativas/segundo → conta de admin comprometida
# em minutos se a senha estiver em wordlists.

# Session fixation
# Atacante obtém um session ID e força a vítima a usá-lo:
https://site.com/login?sessionid=ATTACKER_SESSION
# Vítima faz login → session ID não muda → atacante tem acesso à sessão autenticada

Como defender

• MFA obrigatório — especialmente para contas admin e acesso a dados sensíveis.
• Rate limiting — limitar tentativas de login (ex: 5 por minuto por IP).
• Account lockout — após X tentativas falhas, bloquear temporariamente.
• Senhas fortes — mínimo de caracteres, checagem contra listas de senhas vazadas (HaveIBeenPwned).
• Session management seguro — regenerar session ID após login, invalidar no logout, cookies HttpOnly + Secure + SameSite.
• Nunca expor mensagens de erro que indiquem qual parte da credencial está incorreta.

A08 — Software and Data Integrity Failures

O que é

Nova categoria em 2021, abrange situações onde a integridade do software ou dos dados é comprometida. Isso inclui CI/CD pipelines sem verificação, deserialização insegura, plugins e bibliotecas não verificados, e ataques de supply chain.

Exemplos comuns

• CI/CD pipeline que faz deploy sem validar assinatura de código.
• Insecure deserialization — dados serializados do usuário são desserializados sem validação, permitindo injeção de objetos maliciosos (Java, .NET, PHP são os mais afetados).
• Plugins de CMS instalados de fontes não verificadas.
• Atualizações de software baixadas sem verificação de checksum/signatura.

Exemplo prático de exploração

# Insecure deserialization em Java (Apache Commons Collections)
# Payload ysoserial CommonsCollections1 'ping attacker.com'
# Gera objeto serializado que, ao ser desserializado, executa
# Runtime.exec("ping attacker.com") — RCE

# Enviado como cookie ou campo de formulário:
Cookie: session=aced000573720017...  (objeto serializado malicioso)

Como defender

• Code signing — assinar artefatos de build e verificar assinatura antes do deploy.
• Verificar checksums — sempre validar SHA256/SHA512 de dependências baixadas.
• SAST/DAST no pipeline — análise estática e dinâmica de segurança em cada build.
• Nunca desserializar dados de fontes não confiáveis. Usar formatos simples como JSON.
• Integrity checks — SRI (Subresource Integrity) para recursos externos, integridade de pacotes com npm audit.

A09 — Security Logging and Monitoring Failures

O que é

Aplicações sem logs suficientes ou sem monitoramento permitem que ataques ocorram sem detecção. Breaches significativos frequentemente são descobertos meses depois da intrusão inicial — não porque faltaram sinais, mas porque ninguém olhava.

Exemplos comuns

• Login falhado não é logado.
• Logs sem nível de severidade apropriado.
• Logs armazenados apenas localmente sem backup — atacante apaga após comprometimento.
• Sem alerting automático para padrões suspeitos.
• Ausência de incident response plan.

Caso real

Como defender

• Centralized logging — ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, Datadog.
• SIEM — correlacionar eventos de múltiplas fontes para detectar padrões de ataque.
• Alerting — regras automáticas para eventos críticos (ex: >10 logins falhados em 5 minutos, acesso admin fora do horário).
• Retention policy — logs suficientes para investigação forense (tipicamente 90-365 dias, mais conforme regulamentação).
• Eventos obrigatórios para log: login (sucesso/falha), alteração de permissão, acesso a dados sensíveis, erros de validação de input, ações admin.
• Imutabilidade — enviar logs para sistema de append-only (CloudTrail com log file validation, papel central).

A10 — Server-Side Request Forgery (SSRF)

O que é

SSRF entrou como categoria nova no Top 10 de 2021 e é uma das vulnerabilidades mais perigosas em ambientes cloud. O atacante faz o servidor da aplicação enviar requisições HTTP em nome dele — para URLs internas, metadata endpoints de cloud providers ou serviços que não deveriam ser acessíveis externamente.

Por que é tão perigoso em cloud

A maioria dos provedores cloud expõe metadata endpoints em 169.254.169.254. Esses endpoints fornecem credenciais temporárias (IAM roles, service accounts) que o servidor usa para acessar outros recursos. Se o atacante consegue fazer o servidor acessar esse endpoint, ele rouba as credenciais cloud e pivota para outros serviços.

Exemplo prático de exploração

# Aplicação tem um endpoint que busca URLs:
POST /api/fetch-url
{"url": "https://exemplo.com"}

# Atacante envia:
POST /api/fetch-url
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

# Resposta: credenciais AWS temporárias
{
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "wJalrX...",
  "Token": "FwoGZXIvYXdz..."
}

# Com essas credenciais, o atacante pode:
# - Listar buckets S3
# - Acessar databases RDS
# - Escalar privilégios via IAM
# - Persistir na conta

# Outros payloads SSRF comuns:
{"url": "http://localhost:6379/"}        # Redis interno
{"url": "http://10.0.0.5:8080/admin"}   # Painel admin interno
{"url": "file:///etc/passwd"}           # Leitura de arquivos locais

Como defender

• Allowlist de URLs/domínios — a defesa mais eficaz. Lista explícita do que é permitido.
• Desabilitar esquemas desnecessários — bloquear file://, gopher://, ftp://.
• Segmentação de rede — o servidor da aplicação não deve ter rota para 169.254.169.254 ou para serviços internos sensíveis.
• IMDSv2 (AWS) — exige token para acessar metadata endpoint, dificulta SSRF simples.
• Validar e sanitizar — não passar URLs fornecidas pelo usuário diretamente para funções de requisição HTTP.
• Monitorar — alertar sobre requisições para IPs internos ou metadata endpoints.

Tabela Resumo: OWASP Top 10 (2021)

Próximo Artigo