Production engineering
Reveal answer and reasoning
A forwarding header is supplied data until the application has a reason to trust the peer that supplied it. The real middleware can replace request scheme and remote-address metadata, affecting redirects or other decisions, so accepting it indiscriminately changes the application's trust boundary. This fixture starts with a known proxy address from a documentation range, while the actual connection comes from loopback.
Those headers are therefore ignored until the owned run deliberately trusts loopback instead. The experiment concerns interpretation of metadata on one local HTTP connection; it does not introduce a real proxy, encrypt the connection or authenticate a person.
Program.cs enables only X-Forwarded-For and X-Forwarded-Proto, sets ForwardLimit to one, clears the default proxy/network collections and adds the explicitly configured proxy. UseForwardedHeaders then applies the standard framework behavior before the relevant endpoints observe the resulting context. /proxy returns scheme, remote and host. The actual test sends identical forwarded metadata first with the untrusted default peer and then after restarting the owned server with Production:Proxy=127.0.0.1.
The latter permits the supplied scheme and client context. X-Forwarded-Host is not enabled here, so this scenario should not be described as rewriting the request host through that header.
What a strong answer covers
- A forwarding header is supplied data until the application has a reason to trust the peer that supplied it.
- Program.cs enables only X-Forwarded-For and X-Forwarded-Proto, sets ForwardLimit to one, clears the default proxy/network collections and adds the explicitly configured proxy.
- A trusted header stating https describes the claimed original request scheme; the connection to this test server is still plain loopback HTTP.
Common pitfall
A trusted header stating https describes the claimed original request scheme; the connection to this test server is still plain loopback HTTP. A forwarded client address likewise does not authenticate the user behind it. Real deployments also need to know whether the proxy overwrites or appends incoming header values and which hop is immediately connected. Clearing every trust restriction without adding the intended peer would create a materially different policy. Host filtering, TLS termination, application identity and resource authorization remain separate controls. The known address comparison and one-hop limit do not establish those additional guarantees automatically.
Follow-up questions
- Why would enabling X-Forwarded-Host require another host-policy review even when X-Forwarded-Proto was already tested?
- Which actual transport segment remains plain HTTP after forwarded scheme metadata becomes https?
Self-review
Choose what to revisit. These marks are your own assessment and are separate from lesson completion.