Questão de Segurança da Informação — OWASP — FCC 2025

OWASP Top 10:2021 — A04: Design Inseguro (Insecure Design)

Gabarito: letra B. A medida mais completa e preventiva para mitigar riscos de falhas de projeto é estabelecer um ciclo de vida de desenvolvimento seguro, com padrões arquiteturais, testes de fluxo e validação contra ameaças — exatamente o que a alternativa B descreve. Isso porque o A04:2021 (Design Inseguro) trata de falhas estruturais no planejamento e arquitetura da aplicação, que não podem ser corrigidas por uma implementação perfeita, pois os controles de segurança necessários nunca foram criados para defender contra ataques específicos.

O OWASP Top 10 é uma publicação da fundação sem fins lucrativos OWASP (Open Web Application Security Project) que lista os riscos de segurança mais críticos para aplicações web. É um documento de conscientização e referência para desenvolvedores e profissionais de segurança, atualizado periodicamente. A versão 2021 trouxe mudanças significativas, incluindo a introdução do A04:2021 – Design Inseguro, que não existia na versão 2017. Essa categoria é particularmente importante porque aborda a segurança em uma fase anterior ao código: o design e a arquitetura da aplicação.

O conceito central do Design Inseguro é que falhas estruturais no planejamento não podem ser resolvidas com uma implementação perfeita. Se a arquitetura não previu controles de segurança para determinadas ameaças, nenhuma quantidade de código bem escrito corrigirá o problema. Um dos fatores que contribuem para um design inseguro é a falta de um perfil de risco de negócios inerente ao software, ou seja, não se avaliou quais ameaças são relevantes para aquele sistema específico. Por isso, a prevenção exige ações na fase de pré-codificação: modelagem de ameaças, uso de padrões seguros, testes de segurança no início do desenvolvimento e fortalecimento do processo de coleta de requisitos.

As medidas de prevenção recomendadas pelo OWASP para o Design Inseguro incluem: estabelecer e usar um ciclo de vida de desenvolvimento seguro com profissionais de AppSec; estabelecer e usar bibliotecas de padrões de projeto seguros; usar modelagem de ameaças para autenticação crítica, controle de acesso, lógica de negócios e fluxos de chaves; integrar a linguagem e os controles de segurança às histórias de usuários; integrar verificações de plausibilidade em cada camada da aplicação; escrever testes de unidade e integração para validar se todos os fluxos críticos são resistentes ao modelo de ameaça; compilar casos de uso de sucesso e casos de uso indevido para cada camada; separar as camadas de nível no sistema e nas camadas de rede; separar os tenants de maneira robusta por design; e limitar o consumo de recursos por usuário ou serviço.

A alternativa B sintetiza essas recomendações ao mencionar "ciclo de vida de desenvolvimento seguro", "padrões arquiteturais", "testes de fluxo" e "validação contra ameaças". Os "testes de fluxo" correspondem aos testes de unidade e integração, e a "validação contra ameaças" remete à modelagem de ameaças e aos casos de uso indevido. É a única alternativa que ataca a raiz do problema: o design inseguro. As demais alternativas tratam de medidas reativas ou de outras categorias do OWASP, como veremos a seguir.

Alternativa A — ❌ Incorreta

Implementar firewalls e monitoramento contínuo é uma medida de detecção e resposta, não de prevenção de falhas de design. Firewalls atuam na camada de rede, filtrando tráfego, e o monitoramento contínuo visa identificar atividades suspeitas durante a operação. Essas medidas são importantes, mas não corrigem falhas estruturais de projeto — se o design é inseguro, o firewall não impede que a vulnerabilidade seja explorada. Além disso, o monitoramento contínuo está mais relacionado ao A09:2021 (Falhas em Monitoramento e Segurança de Logs) do que ao A04:2021.

Alternativa B — ✅ Correta ⟵ GABARITO

Estabelecer um ciclo de vida de desenvolvimento seguro com padrões arquiteturais, testes de fluxo e validação contra ameaças é exatamente o que o OWASP recomenda para prevenir o Design Inseguro. O ciclo de vida de desenvolvimento seguro (SDLC) incorpora segurança em todas as fases, desde a coleta de requisitos até a manutenção. Os padrões arquiteturais garantem que a estrutura da aplicação seja segura por design. Os testes de fluxo (unitários e de integração) validam se os fluxos críticos resistem ao modelo de ameaça. E a validação contra ameaças envolve a modelagem de ameaças e a compilação de casos de uso indevido. Essa é a medida mais completa e preventiva, pois ataca a causa raiz do problema.

Alternativa C — ❌ Incorreta

Aplicar criptografia simétrica e controle de integridade sobre os dados transmitidos é uma medida de proteção de dados em trânsito, relacionada ao A02:2021 (Falhas Criptográficas). Embora seja importante, não previne falhas de design. A criptografia protege a confidencialidade e a integridade dos dados, mas não corrige problemas estruturais na arquitetura da aplicação. Além disso, a criptografia simétrica é apenas uma das ferramentas criptográficas; a escolha entre simétrica e assimétrica depende do caso de uso, e a questão não pede especificamente proteção de dados em trânsito.

Alternativa D — ❌ Incorreta

Reduzir validações internas em componentes menos críticos é uma prática insegura e contrária às recomendações do OWASP. A validação de entrada é uma camada de defesa essencial em todas as partes da aplicação, independentemente da criticidade do componente. Reduzir validações para evitar lentidão é um trade-off perigoso que aumenta a superfície de ataque e pode levar a vulnerabilidades como injeção (A03:2021). Essa alternativa não apenas não previne o design inseguro, como o agrava.

Alternativa E — ❌ Incorreta

Substituir APIs públicas por mecanismos de integração proprietários com controle de acesso restrito é uma medida de controle de acesso e segurança de integração, mas não aborda o design inseguro. APIs públicas não são inerentemente inseguras; o problema está em como são projetadas e protegidas. A troca por mecanismos proprietários pode até reduzir a exposição, mas não corrige falhas estruturais de projeto. Além disso, essa medida é específica para integrações, enquanto o enunciado fala de falhas de projeto de forma geral. O controle de acesso restrito está mais relacionado ao A01:2021 (Quebra de Controle de Acesso).

Gabarito: letra B — a única alternativa que aborda a prevenção de falhas de design de forma completa, alinhada às diretrizes do OWASP para o A04:2021.