OWASP Top 10:2025

Do zero

A OWASP é uma fundação aberta que estuda segurança de software. De tempos em tempos, ela publica o Top 10: a lista dos dez riscos mais críticos para aplicações web, montada com dados de milhões de aplicações testadas e com uma pesquisa entre profissionais. A edição de 2025 é a 8ª e é a que o edital cita.

Pense na aplicação como um prédio público. Os dez riscos são os dez jeitos mais comuns de alguém entrar onde não devia ou de o prédio falhar:

• portas internas sem fechadura, em que qualquer visitante entra na sala do diretor (controle de acesso);
• uma janela esquecida aberta ou a senha padrão do alarme nunca trocada (configuração);
• material comprado de um fornecedor que veio adulterado (cadeia de suprimentos);
• um cofre com combinação fraca (criptografia);
• um bilhete com ordens disfarçadas que o porteiro executa sem ler (injeção);
• uma planta que esqueceu a saída de emergência (design);
• um porteiro que não confere o crachá (autenticação);
• uma entrega aceita sem conferir o lacre (integridade);
• câmeras gravando sem ninguém olhando (registro e alerta);
• um alarme que, quando falta luz, destranca todas as portas em vez de travá-las (condições excepcionais).

Frase para guardar: acesso, configuração, cadeia, criptografia, injeção, design, autenticação, integridade, registro e exceções, nesta ordem.

Em 1 minuto

• A01 Controle de Acesso Quebrado continua em 1º e agora inclui o SSRF.
• A02 Configuração Insegura subiu de 5º (2021) para 2º.
• A03 Falhas na Cadeia de Suprimentos de Software é nova: amplia o antigo “Componentes Vulneráveis e Desatualizados”.
• A10 Manuseio Incorreto de Condições Excepcionais é nova: erros mal tratados e sistemas que “falham abertos”.
• Oito categorias saíram dos dados de testes e duas, da pesquisa com a comunidade. As 10 reúnem 248 CWEs (tipos de fraqueza catalogados pelo MITRE).

As dez categorias, com exemplo e controle

O texto oficial em português também usa outros nomes em alguns capítulos: “Falhas de Registro e Monitoramento de Segurança” (A09) e “Tratamento Incorreto de Condições Excepcionais” (A10). A prova pode usar qualquer um deles.

Exemplo concreto: a API de folha das prefeituras

O TCE-GO recebe, por uma API, a folha de pagamento de cada prefeitura. Três falhas típicas:

1. A01, IDOR. A prefeitura A está autenticada e chama GET /api/folhas/124, que é da prefeitura B. Se a API só confere se há um token válido, entrega a folha errada. O controle é verificar, em toda requisição, se o registro pertence a quem pede.
2. A05, injeção. A API monta a consulta juntando texto:

// Vulnerável: o valor do usuário vira parte do comando SQL
"SELECT * FROM folha WHERE cpf = '" + cpf + "'"
//   com cpf = ' OR '1'='1  a consulta devolve a tabela inteira

// Seguro: consulta parametrizada; o valor nunca vira comando
"SELECT * FROM folha WHERE cpf = ?"   com o parâmetro cpf

3. A10, falha aberta. O serviço que valida o token cai, e o código, na dúvida, deixa a requisição passar. O certo é falhar fechado: negar o acesso e registrar o erro.

Comparação: o que mudou de 2021 para 2025

Codificação segura e DevSecOps

DevSecOps é colocar a segurança dentro do fluxo de desenvolvimento, desde o início (“shift left”), em vez de testar só no fim. No pipeline:

• SAST: análise estática do código-fonte, sem executar (acha injeção, segredos no código).
• DAST: teste da aplicação rodando, de fora, como um atacante.
• SCA: análise de composição, que lista as dependências e cruza com vulnerabilidades conhecidas (CVE); gera o SBOM, a lista de materiais do software.
• Varredura de segredos, de imagens de container e de infraestrutura como código.
• Revisão humana obrigatória antes de ir para produção: a OWASP pede separação de funções, para que ninguém sozinho escreva o código e o promova até a produção.

Em APIs, containers e nuvem, os mesmos princípios aparecem: menor privilégio, negar por padrão, segredos fora do código, imagens mínimas e atualizadas, e configuração revisada (um bucket público é A02).

Como a FCC cobra

• Associar cenário e categoria (IDOR é A01; XSS é A05; senha padrão é A02).
• Ordem e nomes da edição 2025 contra a de 2021.
• Controle adequado para cada risco (consulta parametrizada, SBOM, MFA, falha segura).
• Ferramentas de DevSecOps (SAST × DAST × SCA).

Pegadinhas

Explique com suas palavras

Explique a um gestor que não é de TI o que é o OWASP Top 10:2025 e dê um exemplo de dois riscos da lista na API de folha das prefeituras, com o controle de cada um.

1. Escreva sem olhar a lição, com frases curtas e um exemplo seu.
2. Onde travar ou precisar de jargão, há uma lacuna: releia só essa parte.
3. Compare com a explicação-modelo e reescreva o que faltou.

Sua explicação

Fica salva neste navegador.

Comparar com uma explicação-modelo

O OWASP Top 10 é a lista dos dez riscos mais graves em aplicações web, feita por uma fundação aberta com dados de milhões de sistemas testados. A versão de 2025 é a referência atual.

Na API de folha, o risco número 1 é o controle de acesso quebrado: uma prefeitura, já logada, troca o número no endereço e lê a folha de outra. O controle é a API conferir, a cada pedido, se aquele dado é da prefeitura que pediu. Outro risco é a injeção: se a API monta a consulta ao banco colando o que o usuário digitou, um texto malicioso vira comando. O controle é usar consultas parametrizadas, em que o dado nunca vira comando.

Teste-se

Mais duas questões deste tópico estão em Questões.

Flashcards gerados

Ligação com o estudo de caso

O estudo de caso pode pedir “dois riscos do OWASP Top 10:2025 aplicáveis à API e um controle para cada”. Responda com o código e o nome exatos (A01:2025 Controle de Acesso Quebrado) e um controle concreto: “verificar em cada requisição se o registro pertence à prefeitura autenticada”. A01 e A05 são as escolhas mais seguras para uma API.

Fontes da lição

• OWASP Top 10:2025, texto oficial em português: introdução e categorias A01 a A10 (fontes/owasp-top10-2025/owasp-top10-2025-pt-BR.md).
• OWASP Top 10:2025 no repositório oficial
• Edital nº 01/2026, Anexo II, Segurança da Informação (fontes/edital-01-2026.txt).