An ASP.NET Core API behind a reverse proxy sees HTTP instead of HTTPS and the proxy address instead of the client. How should forwarded headers be configured safely?

Forwarded headers and trusted proxy boundaries

Restores client scheme, host, and address behind trusted proxies without accepting spoofed forwarding data from arbitrary callers.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I configure forwarded-header middleware for the headers the proxy actually sends, such as original scheme and client address, and place it early before HTTPS redirection, authentication decisions, link generation, or logging that uses those values. I restrict known proxies or networks and set an appropriate forwarding limit. The application then sees the external HTTPS scheme and the nearest trusted client chain instead of blindly trusting arbitrary X-Forwarded-* headers.

Full answer below

Practice focus

Reverse proxies, X-Forwarded headers, trusted networks and proxies, middleware order, redirect loops, client IP, host validation, and deployment testing.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
A proxy terminates the external connection and creates a new internal request, so the application needs trusted metadata to reconstruct selected original values. Trusting that metadata from everyone creates a spoofing boundary.
I configure forwarded-header middleware for the headers the proxy actually sends, such as original scheme and client address, and place it early before HTTPS redirection, authentication decisions, link generation, or logging that uses those values. I restrict known proxies or networks and set an appropriate forwarding limit. The application then sees the external HTTPS scheme and the nearest trusted client chain instead of blindly trusting arbitrary X-Forwarded-* headers.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
Without correct scheme forwarding, UseHttpsRedirection can create redirect loops because every internal hop appears to be HTTP. Client-IP rate limiting or audit logs can also collapse all traffic to the proxy address or accept a spoofed address. I confirm which component appends versus replaces forwarding headers and how many trusted hops exist. Host forwarding is especially sensitive for generated links and reset URLs, so allowed-host and proxy configuration must agree. The same configuration must be exercised in an integration environment with the real proxy path.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Trusting forwarded headers from any remote address.
Running HTTPS redirection before the external scheme has been restored.
Using the first forwarded client IP without understanding append order and trusted hops.
Generating security-sensitive absolute URLs from an unvalidated forwarded host.

An ASP.NET Core API behind a reverse proxy sees HTTP instead of HTTPS and the proxy address instead of the client. How should forwarded headers be configured safely?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

Tech stacks

Skill areas

Suggest an improvement