Como o gateway lida com chamadas a rotas não mapeadas?

A partir de 28 de abril de 2025, é possível configurar suas APIs para aceitarem apenas requisições que correspondam exatamente às rotas cadastradas no Manager.

Anteriormente, o Gateway aceitava caminhos adicionais após uma rota mapeada e também permitia o roteamento de operações não cadastradas na API. Isso acontecia principalmente em dois cenários:

Cenário 1: caminhos adicionais após uma rota mapeada

Com apenas a rota GET /conta-corrente configurada, uma chamada para GET /conta-corrente/saldo também era aceita e roteada para o backend, mesmo sem a rota /saldo existir na API.

Cenário 2: destination configurado no fluxo principal (all/all)

Quando o destination era posicionado no fluxo principal da API (que vale para qualquer método e qualquer caminho, all/all), era possível acessar qualquer operação do backend, independentemente de ela estar cadastrada como uma rota da API. Na prática, o fluxo principal funcionava como uma rota "curinga", repassando ao backend qualquer requisição recebida.

Com o bloqueio de rotas não mapeadas ativado, em ambos os cenários as requisições que não correspondem exatamente a uma rota cadastrada passam a retornar o erro 404 (Not Found).

Como posso ativar o bloqueio de rotas não mapeadas nas minhas APIs?

Clientes novos já têm o bloqueio de rotas não mapeadas habilitado por padrão.

Para clientes existentes, o comportamento padrão permanece o mesmo, e a ativação do bloqueio é feita mediante solicitação ao time de suporte da Sensedia. Após a ativação, as requisições que não corresponderem exatamente a uma rota cadastrada passam a retornar erro 404.

Por que essa funcionalidade é importante?

Esse novo comportamento aumenta a segurança e a previsibilidade do roteamento, sendo especialmente útil em cenários com:

  • Exigências de compliance;

  • Ambientes com múltiplas aplicações expostas por um único backend;

  • Riscos de exposição de endpoints administrativos ou privados;

  • Necessidade de controle mais rigoroso sobre os caminhos válidos da API.

Isso significa que havia uma vulnerabilidade?

Não. O comportamento padrão é semelhante ao de outros gateways de mercado, como o {proxy+} do AWS API Gateway. Ele foi projetado para cenários com rotas dinâmicas. O novo recurso apenas oferece um nível adicional de controle, alinhado às boas práticas de segurança.

Essa mudança afeta minhas APIs existentes?

Não. O comportamento padrão das suas APIs continua o mesmo. A nova configuração só será aplicada mediante solicitação e não impacta rotas já configuradas.

Thanks for your feedback!
EDIT

Share your suggestions with us!
Click here and then [+ Submit idea]