Closed jblossey closed 1 month ago
Hi, thanks for your report, but I will close here.
The deepl api should not care about a host header when it receives it from a client and properly perform the requested translation.
The "Host: hostname" header value distinguishes between various DNS names sharing a single IP address, allowing name-based virtual hosting. While optional in HTTP/1.0, it is mandatory in HTTP/1.1.
You can check other Websites/APIs (e.g. Google), they will not ignore the Host
field either.
Summary:
Your api reacts to client-side set host headers by redirecting somewhere internally and then returning html code. A potential security risk, I think, because it seems like undefined behavior.
Use-Case:
While developing an app that uses your api, I had to setup an api request proxy through a traefik router that proxies from our client to your api. The vanilla setup looks like this:
You can start this config locally with:
And request using cURL like this:
Expected Behaviour:
The deepl api should not care about a host header when it receives it from a client and properly perform the requested translation.
Actual behaviour:
Because traefik stores the original host in the respective header field, the deepl API returns a 503 with the following html:
Suggested Fix (server-side/deepl-api-side):
Don't use the client-side transmitted HOST header to do something internally in your API. I would rate that as a potential security risk. Store the client headers when you receive the request the first time and set your own headers properly. Otherwise one of your servers apparently gets confused.
Suggested Fix (client side):
For anyone stumbling across the same problem, just tell traefik to not pass the host header with a simple config change: