O que é o OWASP?
A OWASP (Open Web Application Security Project) é uma fundação sem fins lucrativos que produz metodologias, ferramentas e documentação gratuita de segurança de software. O OWASP Top 10 — atualizado em 2021 — representa as categorias de risco mais críticas em aplicações web, baseado em dados de centenas de organizações e milhares de aplicações.
A1 — Quebra de Controle de Acesso (Broken Access Control)
Posição #1 em 2021, presentes em 94% das aplicações testadas. Ocorre quando usuários conseguem agir fora das permissões pretendidas — acessar dados de outros usuários, funções administrativas ou modificar registros alheios.
Exemplo: Alterar o parâmetro ?user_id=123 para ?user_id=456 e acessar dados de outro usuário sem autenticação.
Como corrigir: Implementar verificação de autorização no servidor para cada requisição, usar tokens de acesso com escopo definido, negar por padrão (deny by default).
A2 — Falhas Criptográficas
Dados sensíveis expostos por falhas na implementação ou ausência de criptografia: senhas armazenadas em texto puro, uso de algoritmos fracos (MD5, SHA1 sem salt), transmissão de dados sem TLS, chaves criptográficas hardcoded no código.
Como corrigir: TLS 1.2+ para dados em trânsito, bcrypt/Argon2 para senhas, AES-256 para dados em repouso, gestão segura de chaves.
A3 — Injeção (Injection)
SQL Injection, NoSQL Injection, LDAP Injection, OS Command Injection, SSTI (Server-Side Template Injection). Ocorre quando dados não confiáveis são enviados a um interpretador como parte de um comando ou consulta.
-- Exemplo de SQL Injection clássico: SELECT * FROM users WHERE username = '' OR '1'='1' -- ' AND password = 'x' -- Resultado: retorna todos os usuários, bypassa autenticação
Como corrigir: Prepared statements / parameterized queries, ORMs, validação de entrada, princípio do menor privilégio no banco de dados.
A4 — Design Inseguro
Falhas de design que não podem ser corrigidas apenas com implementação correta. Ausência de modelagem de ameaças (threat modeling), requisitos de segurança não definidos, lógica de negócio explorada.
Como corrigir: Secure Development Lifecycle (SDL), threat modeling com STRIDE, revisão de arquitetura antes do desenvolvimento.
A5 — Configuração de Segurança Incorreta
Configurações padrão inseguras, funcionalidades desnecessárias habilitadas, mensagens de erro com detalhes de stack trace, cabeçalhos HTTP de segurança ausentes, permissões excessivas em serviços cloud.
Como corrigir: Hardening de servidores, desabilitar features não utilizadas, cabeçalhos HTTP: Content-Security-Policy, X-Frame-Options, HSTS.
A6 — Componentes Vulneráveis e Desatualizados
Uso de bibliotecas, frameworks e dependências com CVEs conhecidos. O ataque à SolarWinds explorou exatamente um componente de terceiros comprometido.
Como corrigir: Inventário de dependências (SBOM), ferramentas de análise: Snyk, OWASP Dependency-Check, npm audit, atualizações automatizadas com Dependabot.
A7 — Falhas de Identificação e Autenticação
Senhas fracas, ausência de MFA, sessões não invalidadas após logout, brute force sem rate limiting, tokens JWT com algoritmo none ou secrets fracos.
Como corrigir: MFA obrigatório para funções críticas, políticas de senha forte, limitação de tentativas, PKCE para OAuth 2.0, rotação de tokens.
A8 — Falhas de Integridade de Software e Dados
Código e infraestrutura que não protegem contra modificação não autorizada: pipelines CI/CD inseguros, deserialização de dados sem validação, atualizações automáticas sem verificação de assinatura.
Como corrigir: Verificação de assinatura de pacotes, pipeline seguro com SAST/DAST, Subresource Integrity (SRI) para scripts externos.
A9 — Falhas de Log e Monitoramento
Sem logs adequados, incidentes passam despercebidos por meses. O tempo médio para detectar uma violação sem monitoramento é de 207 dias (IBM, 2024).
Como corrigir: Logs de autenticação, autorização e erros de negócio; alertas em tempo real (SIEM); plano de resposta a incidentes testado.
A10 — Server-Side Request Forgery (SSRF)
O servidor é enganado para fazer requisições para destinos não intencionados — metadata de cloud (169.254.169.254), serviços internos, redes privadas. Explorada na violação da Capital One em 2019 (AWS IMDSv1).
-- Exemplo de SSRF para acessar metadata AWS: GET /fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ -- Pode vazar credenciais IAM do servidor
Como corrigir: Validação e allowlist de URLs, bloquear requisições a faixas privadas (RFC 1918), AWS IMDSv2, segmentação de rede.
Resumo das 10 vulnerabilidades
| # | Categoria | CVSS típico | Prevalência |
|---|---|---|---|
| A1 | Broken Access Control | 7.5–9.8 | 94% das apps |
| A2 | Falhas Criptográficas | 5.0–8.0 | Muito alta |
| A3 | Injeção (SQLi, XSS) | 6.0–10.0 | Alta |
| A4 | Design Inseguro | Variável | Crescente |
| A5 | Configuração Incorreta | 5.0–9.0 | 90% das apps |
| A6 | Componentes Vulneráveis | Herdado do CVE | Muito alta |
| A7 | Autenticação Falha | 7.0–9.8 | Alta |
| A8 | Integridade de Dados | 6.0–9.0 | Média |
| A9 | Log & Monitoramento | Indireta | Muito alta |
| A10 | SSRF | 8.0–9.8 | Crescente |