01 - STAKEHOLDER (quem valida e esclarece):
02 - PROBLEMA (cenário e/ou dor):

Durante os testes, identificamos que a documentação da API está publicamente acessível sem a necessidade de autenticação. Esse tipo de exposição permite que qualquer usuário não autenticado visualize todos os endpoints, parâmetros e métodos disponíveis na API.

Para reproduzir a vulnerabilidade, acessamos a área autenticada da aplicação e clicamos no botão que redireciona para a documentação da API.

Identificamos que a documentação da API pode ser visualizada de forma autenticada.

Abrimos uma aba anônima no navegador e acessamos a URL da documentação da API.

Por fim, podemos confirmar que é possível acessar a documentação mesmo sem estar autenticado, o que evidencia a exposição indevida de informações sensíveis.

OBS: Podemos utilizar da URL criada na barra de endereços e alterar o parâmetro &env= para qualquer outra tenant que não temos permissão de administrador que conseguimos acessar a documentação da API.

Recomendações
Recomendamos restringir o acesso à documentação da API, aplicando autenticação adequada (por exemplo, autenticação baseada em roles, permitindo apenas usuários administradores ou desenvolvedores internos). Além disso, recomenda-se:

• Não expor documentação da API em ambientes de produção.

• Utilizar ferramentas de gerenciamento de APIs que permitam controle de acesso granular.

• Manter ambientes de homologação/QA para disponibilizar a documentação apenas internamente

Swagger à nível de Tenant e Org

Aparentemente mostrou a documentação, embora não tenha se autenticado.

Trocando parâmetro na URL para tenant que sou App Admin apenas e não tenho acesso ao swagger pela UI, entrou como autenticado.

03 - OBJETIVO (solução proposta):
04 - QUEM PODE USAR (perfis de usuários):
05 - ASSETS (links e arquivos relevantes):
06 - CRITÉRIOS DE ACEITE:

• Swagger deve retornar os endpoints apenas se tiver um Authorization token valido, inclusive para endpoints que não requerem autenticação.