Production engineering
Reveal answer and reasoning
A reverse-proxy design should enumerate the actual immediate trusted peers or networks, constrain accepted forwarding depth and specify how the edge removes spoofed incoming values. Configure only required forwarded fields before components that consume them. TLS policy must describe each transport segment, while host validation and user authorization retain their own trusted inputs. Test unknown and known immediate peers separately rather than treating an Origin or forwarding string as an authenticated identity.
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.
A useful report records configured trust, immediate transport, supplied metadata and observed context as distinct facts. It should explicitly retain plain HTTP in the transport description even when Request.Scheme becomes https. The portable address comparison makes that distinction understandable but supplies no network proof. A senior answer identifies the trusted hop and accepted chain before relying on metadata for redirects, cookies or authorization-adjacent decisions.
It also keeps user identity and allowed resource access outside the proxy-address claim. The real framework integration is valuable precisely because it can be inspected without pretending the classroom server is a deployed reverse-proxy architecture.
What a strong answer covers
- A reverse-proxy design should enumerate the actual immediate trusted peers or networks, constrain accepted forwarding depth and specify how the edge removes spoofed incoming values.
- A trusted header stating https describes the claimed original request scheme; the connection to this test server is still plain loopback HTTP.
- A useful report records configured trust, immediate transport, supplied metadata and observed context as distinct facts.
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.