Nginx X-Accel-Redirect trusts the upstream response

Nginx's X-Accel-Redirect mechanism, used in conjunction with upstream proxies, trusts the response from the upstream server. This design simplifies the process of serving protected URIs, but it also makes the upstream response a crucial part of the trust boundary. Nginx explicitly documents X-Accel-Redirect among the request-redirection mechanisms that create internal redirects.

For the security feature to work, two conditions must be met: the application must authorize the request, and nginx must limit the URI space the response can reach.

A frequent error is treating the header as a benign optimization while allowing user-controlled input to influence it. If a download endpoint accepts a user-supplied filename and includes it in the X-Accel-Redirect header, the user can manipulate the internal path. To mitigate this risk, path normalization, prefix checks, and a fixed identifier-to-path map are preferable to concatenating user input into a URI.

If nginx lacks the necessary normalization, the application should utilize a server-side object ID instead of constructing a path.

The reverse configuration problem also poses a threat. A proxy that trusts every upstream header may accept an X-Accel-Redirect header from an application not intended to serve files. When dealing with general web applications or third-party services, it is essential to review whether the directive should be disabled for that route.

Nginx offers upstream header controls, such as proxy_ignore_headers and equivalent FastCGI settings, but the specific directive depends on the handler. An audit should address several key questions: which upstream responses can set X-Accel-Redirect, what internal locations exist and what filesystem paths each exposes, whether a request parameter can become part of the redirect URI, whether authorization happens before the header is emitted, and whether range requests, cache behavior, and error handling are governed by the same policy.

Additionally, the application's accessibility without nginx, bypassing the internal location, should be evaluated.

The final question is often decisive. If clients can directly connect to the application server, they might receive a response that assumes nginx will handle it, or they may access a file endpoint the proxy was meant to conceal. Network policy should ensure that nginx is the sole reachable path for those routes. The most secure design employs a limited number of internal locations, maps identifiers to fixed paths on the server, and confines the file-serving policy to a single, reviewable location.

Testing should include denied requests, malformed identifiers, missing files, and unexpected upstream headers. The selected object and authorization result should be logged, not the secret path. While X-Accel-Redirect can be beneficial when the upstream is trustworthy and the mapping is narrow, it becomes a liability when a request can control the redirect or circumvent the proxy.