> Separately, configure your backends to not spit out secret info in production mode and you should not have to actually worry about this It's not really about

> Separately, configure your backends to not spit out secret info in production mode and you should not have to actually worry about this It's not really about secrets. That's just the example from the article. (Although, that can happen if the backend is communicating authorisation-to-serve to a cache.) You may be using X-Accel-Redirect: https://www.nginx.com/resources/wiki/start/topics/examples/xsendfile/ https://www.nginx.com/resources/wiki/start/topics/examples/x... Or any of the other built-in X-Accel response headers that are automatically offered by proxy module: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_ignore_headers https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr... It's fairly common to use X-Accel-Redirect to have the backend tell NginX to serve a file. With a malformed request, NginX will serve the header instead of the file, revealing your internal filesystem structure to the client. Often that structure has hashes and versions in the paths. Even without those, it can be quite revealing. That's not a badly designed backend; this feature is useful and intentional. Having that pass through without being processed is a security fail of NginX, and they should at least document it. Better, provide an option to never blindly forward in these cases, or some "if" variable to let the admin configure what they want done. After learning about this, I expect there are plenty of sites out there which will reveal their X-Accel-Redirect paths if you ask them like this, though I can't be bothered to go looking.