~/questoes/ciberseguranca
Pressupostos frágeis são decisões de design que assumem segurança sem implementar verificações explícitas. Um exemplo clássico é acreditar que usuários comuns nunca conseguirão alcançar URLs administrativas apenas porque não estão visíveis na interface, sem protegê-las com validações reais no servidor.
A alternativa está correta porque identifica exatamente o padrão de pressupostos frágeis: acreditar que a restrição funciona sem verificá-la de fato. Quando a aplicação não valida permissões no servidor, um atacante pode simplesmente digitar a URL administrativa diretamente ou modificar requisições para contornar essa falsa proteção.
Descreve o cerne dos pressupostos frágeis: confiar em segurança por obscuridade sem controles reais. A aplicação parece segura porque usuários normais não veem o link administrativo, mas não há verificação de permissões implementada, permitindo acesso direto.
Tokens JWT com expiração curta é uma prática de segurança sólida para gestão de sessão, não um exemplo de pressupostos frágeis. Isso representa verificação explícita e renovação automática, que é o oposto do que pressupostos frágeis fazem.
Verificar permissões em cada operação sensível é exatamente o que você deve fazer para evitar pressupostos frágeis. Essa é uma prática defensiva correta, não uma característica de pressupostos frágeis.
Certificados SSL protegem a comunicação entre cliente e servidor (confidencialidade em trânsito), mas não resolvem problemas de controle de acesso ou pressupostos frágeis sobre quem pode fazer o quê dentro da aplicação.