Skip to main content

Grill Decisions — #30 Middleware Ordering

Data: 2026-07-08

Decisão 1: Abordagem de fix — reordenar vs refatorar vs não mexer​

Pergunta: Como corrigir o bug de ordering do middleware? UseAuthentication() está DEPOIS de UseEndpoints() (terminal) e nunca executa.

Opções:

#AbordagemO que fazPrósContras
AReordenar Startup.Configure()Mover UseAuthNConf() ANTES de UseApiConf()1 linha por serviço, sem alterar lógica interna, pipeline by-the-bookUseAuthZ fica duplicado (no-op inofensivo)
BExtrair UseEndpoints de UseApiConfSeparar UseEndpoints() para fora do método, chamar por últimoPipeline "limpo", sem duplicatasRefactor maior em 4 serviços, risco de regressão
CNão mexer no orderingConfiar no lazy auth do UseAuthorization()Zero riscoSó funciona com [Authorize]; não resolve #30 para endpoints públicos; SignalR quebrado (#29)

Decisão: Abordagem A — reordenar chamadas no Startup.Configure().

Trade-off: A duplicata do UseAuthorization() (uma em UseApiConf, uma em UseAuthNConf) fica como débito técnico para remoção futura. A segunda chamada é no-op quando User já autenticado — sem impacto funcional. A remoção exige alterar UseApiConfiguration() em cada serviço, o que é um refactor de baixo risco mas fora do escopo deste card de segurança.

Decisão 2: Escopo — 4 serviços vs ~17 serviços​

Pergunta: O bug de ordering afeta ~17 serviços. Corrigir todos ou só os 4 do escopo do pentest?

Opções:

  • Apenas 4 serviços do pentest (checkout, cart, product, store)
  • Todos os ~17 serviços de uma vez

Decisão: Apenas 4 serviços do pentest.

Trade-off: Os 4 serviços cobrem os endpoints vulneráveis documentados no relatório (#08 profile-fraud, #07 SQL injection, #30 schema override). Demais serviços têm o mesmo bug mas não foram testados no pentest. Corrigir 17 serviços de uma vez aumenta risco de regressão e dilui o foco. Card futuro: "fix middleware ordering nos serviços restantes" como batch.

Decisão 3: Duplicata UseAuthorization() — remover agora ou depois​

Pergunta: Após reordenar, UseAuthorization() será chamado DUAS vezes (uma em UseApiConf L79, uma em UseAuthNConf L85). Remover a duplicata?

Opções:

  • Remover UseAuthorization() do UseApiConfiguration() em cada serviço (agora)
  • Deixar a duplicata (no-op) e remover depois

Decisão: Deixar a duplicata. Remover depois em card separado.

Trade-off: A segunda chamada de UseAuthorization() é no-op quando HttpContext.User já está autenticado — o AuthorizationMiddleware verifica se já foi aplicado e pula. Remover agora exigiria alterar UseApiConfiguration() em 4 serviços (mais 1 ponto de falha). Card futuro de "limpeza" pode remover de todos os serviços de uma vez.

Decisão 4: Ordem de implementação — #08 antes de #30​

Pergunta: #30 (ordering) é pré-requisito para #08 (adicionar [Authorize]) ou podem ser implementados em paralelo?

Análise: #08 adiciona [Authorize(JwtBearer)] em endpoints de payment. Com o bug de ordering, o lazy auth do UseAuthorization() dispara a validação JWT — funciona. Portanto #08 não depende de #30.

Mas: sem #30, endpoints que NÃO receberam [Authorize] (via #08) continuam com HttpContext.User vazio → claim schema null → header ainda vence.

Opções:

  • #08 primeiro (funciona via lazy auth), #30 depois
  • #30 primeiro (pré-requisito), #08 depois
  • Juntos no mesmo card

Decisão: #08 primeiro, #30 depois. Sequência de implementação: #08 → #30.

Trade-off: #08 mitiga o risco imediato (endpoints de payment sem auth). #30 é melhoria sistêmica que beneficia todos os endpoints. Ordem de risco decrescente. Se #30 for implementado antes, #08 ganha defesa adicional (User populado mesmo sem lazy auth), mas a ordem inversa não cria risco novo.

Decisão 5: UseSwaggerConfiguration() antes de auth — problema?​

Pergunta: Após mover UseAuthNConf() para cima, UseSwaggerConfiguration() fica ANTES dos middlewares de auth. Isso é um problema?

Análise: UseSwaggerConfiguration() registra:

  • UseSwagger() — middleware que serve swagger.json
  • UseSwaggerUI() — middleware que serve a página HTML do Swagger

Ambos são middlewares de arquivos estáticos. Eles não precisam de autenticação — servem assets públicos.

Decisão: Manter Swagger antes de auth. Inofensivo.

Trade-off: Se no futuro o Swagger precisar de auth (ambiente de produção), a ordem precisaria ser UseAuthN → UseAuthZ → UseSwagger. Mas hoje Swagger é desabilitado em produção — só Development/Staging.