pular para o conteúdo
base de conhecimento · owasp top 10

O OWASP Top 10, em código.

Cada um dos dez riscos web explicado, com código vulnerável e corrigido em várias linguagens e o teste que prova a correção.

$ clique num card para ver os detalhes · ctrl+k para buscar

mapa de aprendizado

Os tópicos estão organizados por nível, dos fundamentos ao avançado. As setas vão do pré-requisito para o que se apoia nele. Selecione um tópico para ver uma prévia ou siga o próximo passo destacado.

Seu próximo passo

0 de 10 estudados
começar este tópico

01 Fundamentos

As ideias sobre as quais todo o resto se apoia.

02 Prática

Aplique os controles e faça-os funcionar na prática.

03 Avançado

Projete, escale e opere em profundidade.

  • estudado
  • pronto para estudar
  • faltam pré-requisitos

onde cada risco é decidido

Do design à operação: cada risco tem uma fase em que prevenir é barato. Cada chip abre o tópico correspondente.

  1. 01design

    decida o que precisa ser impossível

    gate: toda funcionalidade tem casos de abuso e uma regra de autorização antes do código

  2. 02código

    trate entrada, segredos e identidade com segurança

    gate: padrões perigosos são bloqueados na revisão e no CI

  3. 03entrega

    entregue código verificado com configurações seguras

    gate: só artefatos assinados, escaneados e reforçados chegam à produção

  4. 04operação

    enxergue ataques e falhe com segurança

    gate: um ataque é percebido, contido e deixa rastro

tópicos

A01 Broken Access Control
A autenticação diz quem você é; o controle de acesso diz o que você pode fazer. Quando o servidor esquece de verificar em cada requisição, trocar um id na URL é tudo o que um atacante precisa.
técnica· etapa: design
A02 Security Misconfiguration
Os padrões são feitos para conveniência, não para a internet. Uma flag de debug, um bucket aberto, um erro detalhado ou uma senha padrão transformam código correto em um incidente.
prática· etapa: ship
A03 Software Supply Chain Failures
Sua aplicação é feita, em sua maior parte, de código de outras pessoas. Uma biblioteca vulnerável, um pacote malicioso ou uma etapa de build adulterada chega à produção com o seu nome.
prática· etapa: ship
A04 Cryptographic Failures
A criptografia raramente é quebrada; ela é pulada, mal configurada ou mal usada. Transporte em texto puro, hashes de senha rápidos e chaves no código são como os dados realmente vazam.
técnica· etapa: code
A05 Injection
Quando dados e instruções viajam na mesma string, quem controla os dados controla a instrução. A cura é mantê-los separados, em qualquer linguagem.
técnica· etapa: code
A06 Insecure Design
Uma implementação perfeita de um design ruim continua sendo uma vulnerabilidade. A segurança precisa ser pedida antes da primeira linha de código, como requisito, e não encontrada depois como um bug.
conceito· etapa: design
A07 Authentication Failures
O login é a porta da frente. Tentativas ilimitadas, senhas reutilizadas, sessões que nunca expiram e tokens que não são realmente verificados deixam um atacante entrar como um usuário real.
técnica· etapa: code
A08 Software or Data Integrity Failures
Se o programa aceita atualizações, plugins, objetos serializados ou saída de pipeline sem provar de onde vieram, quem puder alterá-los pode executar código como você.
técnica· etapa: ship
A09 Security Logging and Alerting Failures
Você não consegue responder ao que não consegue ver. Logs sem alertas são um arquivo morto; alertas sem bons logs são ruído. Ambos precisam existir, e nenhum pode ser injetável nem estar cheio de segredos.
prática· etapa: operate
A10 Mishandling of Exceptional Conditions
A segurança muitas vezes depende do que acontece quando algo dá errado. Se um erro significa "permitir", um stack trace significa "aqui está o meu código" ou uma operação pela metade significa "estado corrompido", o caminho de falha é a vulnerabilidade.
técnica· etapa: operate