Why is a request with URL containing ../../../ rejected with 400 by Application Load Balancer?

What's the full request path you're sending in the third scenario? If it's /owner/config/../../../test then you're trying to backtrack from the root level, after the first ".." removed "config" and the second removed "owner", making the request not valid.

the full request path is https://client.mydomain.com:443/owner/config/..%2f..%2F..%2Ftest I would expect AWS not to treat this as a backtrack as it is URI encoded.

If I only have two ../ in the path, e.g. https://client.mydomain.com:443/owner/config/..%2F..%2Ftest it hits my service at the correct endpoint, so appears not to have gone back two steps.

The ALB won't modify the path, so if the request is allowed to pass through, it's up to the target application or middleware to decide how to interpret the encoded slashes and ".." path elements.

I believe backtracking three levels when there are only two in the path is the reason the request is being considered as invalid. You could try setting "routing.http.desync_mitigation_mode" on the ALB to "monitor" (https://docs.aws.amazon.com/elasticloadbalancing/latest/application/application-load-balancers.html#load-balancer-attributes) to minimise the number of validation tests the ALB performs. I'm not sure if it affects the path parsing behaviour, but that's easy to test. In the console, it's on the "Attributes" tab of the load balancer's settings with the name "Desync mitigation mode".

Thank you for the info. I have just tried changing the desync_mitigation_mode to "monitor" and it still fails with the same issue. I'm not sure how to work around this, I guess either limit my UI to prevent entry of an invalid id, or base64 encode the id

Too bad it didn't help. I don't believe there's anything more about ALB's request validation rules that can be relaxed. The workaround you described of encoding the value in Base64 would certainly avoid having the ALB parse it as a directory structure.