Diante da imensidão de vulnerabilidades web possíveis, você precisa de um mapa que priorize o que mais importa. Esse mapa é o OWASP Top 10 — uma lista, mantida pela Open Worldwide Application Security Project, das dez categorias de riscos de segurança web mais críticas, atualizada periodicamente com base em dados reais da indústria. É a referência mais influente da segurança web: pentesters a usam como checklist, desenvolvedores como guia do que evitar, e é conhecimento obrigatório para qualquer profissional. Esta aula te dá o panorama; as próximas aprofundam as categorias mais importantes com prática.

O que a lista é e o que não é

Antes das categorias, entenda o que o OWASP Top 10 é e não é. É uma lista de categorias de risco (não vulnerabilidades específicas), baseada em prevalência, severidade e impacto reais. Não é uma lista exaustiva (há muito mais que dez tipos de falha), mas cobre os riscos de maior impacto — é o "onde começar", não o "onde terminar". Ela é atualizada a cada poucos anos, e as posições e agrupamentos mudam conforme o cenário evolui; o valor está menos na ordem exata e mais em conhecer as categorias e o que cada uma representa. Vamos percorrê-las em nível conceitual, apontando onde o curso as aprofunda.

Broken Access Control no topo

Broken Access Control (controle de acesso quebrado) — subiu ao topo nas versões recentes, e por bom motivo: é quando a aplicação não impõe corretamente o que cada usuário pode fazer. Um usuário acessa dados ou funções que não deveria — vê o pedido de outro cliente mudando um número na URL, acessa o painel de admin sem ser admin, executa ações fora de sua permissão. É a violação da autorização (o segundo A do AAA, aula A tríade CIA e o modelo AAA: o vocabulário da defesa), e o exemplo clássico é o IDOR (Insecure Direct Object Reference), que veremos também nas APIs (Bloco XIII). É onipresente porque impor autorização corretamente em cada ponto é trabalhoso e fácil de esquecer.

Falhas criptográficas e injeção

Cryptographic Failures (falhas criptográficas) — dados sensíveis expostos por criptografia ausente, fraca ou mal implementada. É o Bloco IV inteiro aplicado à web: dados trafegando sem HTTPS, senhas mal armazenadas (aula Hashes e assinaturas digitais: a impressão digital dos dados), algoritmos obsoletos, chaves expostas. Injection (injeção) — quando entrada não confiável é interpretada como comando/código pelo servidor; o SQL Injection é o exemplo clássico, mas inclui command injection (aula Command Injection: do navegador ao sistema operacional) e outras. É a categoria que este bloco mais aprofunda, porque injeção é a essência de muitas falhas web.

Design inseguro e má configuração

Insecure Design (design inseguro) — falhas na arquitetura, não na implementação; problemas que nasceram na prancheta por falta de threat modeling (aula Threat modeling: STRIDE, DREAD, PASTA e attack trees). Security Misconfiguration (configuração incorreta) — o que vimos no Tomcat (aula Apache Tomcat: abusando de funcionalidade legítima): credenciais padrão, funcionalidades desnecessárias expostas, permissões erradas, mensagens de erro reveladoras. Vulnerable and Outdated Components (componentes vulneráveis e desatualizados) — usar bibliotecas/frameworks com vulnerabilidades conhecidas (conecta com a cadeia de suprimentos, Bloco XVII, e com o Heartbleed).

Autenticação e integridade de dados

Identification and Authentication Failures (falhas de autenticação) — gestão fraca de login e sessões: senhas fracas permitidas, força bruta não mitigada (Bloco VII), sessões mal gerenciadas, ausência de MFA (aula Falhas de autenticação, sessões e JWT: quebrando o controle de identidade). Software and Data Integrity Failures (falhas de integridade) — confiar em código/dados sem verificar sua integridade, incluindo desserialização insegura (aula Web avançada I: XXE, SSTI e desserialização insegura) e riscos de CI/CD e cadeia de suprimentos (Bloco XVII). Security Logging and Monitoring Failures (falhas de log e monitoramento) — não registrar ou monitorar adequadamente, cegando a organização para ataques (a lição da aula Ocultação de rastros: o que muda quando o hacking é ético). E SSRF (Server-Side Request Forgery, aula CSRF e SSRF: falsificando requisições no cliente e no servidor) — que ganhou entrada própria por sua crescente relevância, especialmente em nuvem.

Checklist, linguagem comum e estrutura

O valor prático do OWASP Top 10 para você é triplo. Como checklist de teste: ao avaliar uma aplicação, você percorre as categorias, garantindo cobertura dos riscos principais. Como linguagem comum: reportar um achado como "Broken Access Control" comunica imediatamente sua natureza a qualquer profissional e a desenvolvedores. E como estrutura de aprendizado: as categorias organizam o vasto campo da segurança web em blocos gerenciáveis — é exatamente por isso que este bloco do curso se estrutura em torno delas. A OWASP mantém, para cada categoria, guias detalhados de teste e prevenção (o Web Security Testing Guide, as Cheat Sheets) que são referência de trabalho.

Uma ferramenta para quem constrói

Do lado defensivo, o OWASP Top 10 é primariamente uma ferramenta para desenvolvedores e defensores — sua razão de existir é orientar a construção de aplicações seguras. Cada categoria vem com práticas de prevenção, e a mensagem central se repete, expandida: valide toda entrada no servidor, imponha autorização em cada ponto, use criptografia corretamente, mantenha componentes atualizados, configure com segurança, gerencie sessões e autenticação com rigor, e monitore. Um princípio que atravessa tudo é o "secure by design" — construir segurança desde a arquitetura (threat modeling, aula Threat modeling: STRIDE, DREAD, PASTA e attack trees), não remendá-la depois. O OWASP também mantém recursos defensivos como o ASVS (padrão de verificação de segurança de aplicações) para quem quer profundidade. Com o mapa em mãos, o mergulho nas categorias mais importantes começa pela mais icônica: a injeção de SQL, feita primeiro na mão.

Fontes e leituras recomendadas

Exercícios

  1. O que o OWASP Top 10 é e o que ele não é? Por que a ordem exata importa menos que conhecer as categorias?

    ✓ Resposta:

    É uma lista das dez categorias de risco de segurança web mais críticas, baseada em dados reais de prevalência e impacto; não é uma lista exaustiva de vulnerabilidades específicas, mas um ponto de partida priorizado. A ordem exata importa menos porque muda entre versões; o valor está em conhecer as categorias e o que cada uma representa.

  2. Explique "Broken Access Control" e dê o exemplo do IDOR. A que parte do AAA essa categoria corresponde?

    ✓ Resposta:

    Broken Access Control é quando a aplicação não impõe corretamente o que cada usuário pode fazer, permitindo acesso a dados ou funções indevidos. O IDOR é o exemplo clássico: acessar o objeto de outro usuário alterando um identificador (ex.: um número na URL). Corresponde à autorização (o segundo "A" do AAA).

  3. O que caracteriza a categoria "Injection", e por que ela é central na segurança web?

    ✓ Resposta:

    Injection ocorre quando entrada não confiável é interpretada como comando ou código pelo servidor (ex.: SQL Injection, command injection). É central porque é a essência de muitas falhas web — resultado direto de processar entrada do usuário sem o devido tratamento, o princípio que a arquitetura web torna crítico.

  4. Qual a diferença entre "Insecure Design" e "Security Misconfiguration"?

    ✓ Resposta:

    Insecure Design são falhas na arquitetura/concepção, nascidas na prancheta por falta de threat modeling (o problema está no projeto). Security Misconfiguration são falhas na configuração da implementação — credenciais padrão, funcionalidades expostas, permissões erradas (o projeto pode estar certo, mas a implantação está mal configurada).

  5. Cite os três valores práticos do OWASP Top 10 para o pentester, e qual o princípio defensivo central que ele promove.

    ✓ Resposta:

    (1) Checklist de teste (cobertura dos riscos principais); (2) linguagem comum (comunicar a natureza de um achado); (3) estrutura de aprendizado (organizar o campo). O princípio defensivo central é o "secure by design" — construir segurança desde a arquitetura, validando entrada, impondo autorização, usando criptografia correta e monitorando, em vez de remendar depois.