Kong: Request path matching may have undesired behaviour

[kwahome]

Summary

Matching via request paths has an undesired behaviour of allowing access to endpoints on the upstream service that may not be configured on the gateway or that consumers are not authorized to access.

To satisfy the request path routing condition, a client request's path must be prefixed with one of the values of the paths attribute.

For example, with a Route configured like so:
{ "paths": ["/service"] }

The following requests would be matched:

GET /service HTTP/1.1
GET /service/resource HTTP/1.1

Route /service/resource may represent either a resource on the upstream service that is not exposed via the gateway or a resource that is configured but a configured consumer is not authorized to access.

Steps To Reproduce

1. Configure a service e.g. one with an upstream with /service and /service/resource
2. Configure a route e.g. one with path /service
3. Access the configured route but with an extra resource endpoint suffixed i.e GET /service/resource HTTP/1.1
4. Observe the request being proxied to the upstream and the resource returned even though it is not configured on the gateway

The way I have dealt with this issue is to optionally use the end of line regex character $ to yield a strict match while configuring route paths when desired by passing a flag to my custom logic that adds routes. I have had to implement custom endpoints to configure routes dao (same case in apis model) because my gateway requirements needed this strict match and how we do routes (or apis in the earlier model) is by parsing and extracting necessary fields from a swagger documentation of an API endpoint.

For example, with a Route configured like so:
{ "paths": ["/service$"] }

Additional Details & Logs

• Kong version (0.13.0)

[thibaultcha]

Hi,

Thanks for your feedback. This is intended behavior, and how Kong's proxying has worked for several years already. We call it "transparent" proxying: Kong is not restrictive by default with regards to _how_ it proxies the request, and does, by default, the minimum amount of changes to it before sending it upstream.

This is also the whole reason behind Services and Routes introduced in 0.13, to be able to apply plugins per endpoint, and make some Routes authenticated and some others not. See the 0.13 announcement blog post for an example.

Your solution with matching the exact path, or the multiple Routes paradigm are both valid. In the future, we might add "exact path matches", and OpenAPI spec validation, as well as ACL, all three of which also help configuring this.

I will let this open for some more time, but not considering it an issue in any way.

[thibaultcha]

Considering this answered and closing it. Thank you.

[shuoqingding]

Hi @thibaultcha , just wanted to check if "exact path matches" feature has been added on the roadmap? Thank you.