Azure Linux App Service: supported explicit proxy trust for ASP.NET Core forwarded headers?

Question

Azure Linux App Service: supported explicit proxy trust for ASP.NET Core forwarded headers?

Dave Mace 0

We are evaluating ASP.NET Core 10 on the built-in .NET stack in multitenant Azure App Service for Linux (not IIS, an App Service Environment, or a custom container). Public HTTPS terminates at the platform before reaching Kestrel. There is no customer-managed proxy in front of App Service.

We need the original scheme and client IP for HTTPS handling, secure authentication flows and IP-based rate limiting. We want to consume only X-Forwarded-For and X-Forwarded-Proto with ForwardLimit = 1 and an explicitly trusted immediate proxy, rather than accept these headers from arbitrary peers.

The ASP.NET Core guidance recommends ASPNETCORE_FORWARDEDHEADERS_ENABLED=true for Linux/non-IIS hosting, but explicitly warns that this does not restrict forwarding to KnownProxies.

A synthetic test observed a platform-internal immediate peer and correct forwarding in sampled requests, including requests with client-supplied forwarding headers. However, repeated observations are not a documented platform guarantee, and the app public inbound/outbound IP lists do not identify the immediate Kestrel peer.

Could the App Service team clarify the supported production approach?

Is there a documented set of immediate proxy addresses, or a supported discovery mechanism, suitable for KnownProxies/KnownIPNetworks across worker replacement, scaling and platform updates?
What isolation guarantees prevent direct ingress to Kestrel or requests from other tenants/workloads impersonating that trusted peer?
For direct public ingress, does the final platform hop always append the actual client IP as the rightmost X-Forwarded-For value and replace X-Forwarded-Proto, even when a caller supplies these headers? Are there any exceptions relevant to ForwardLimit = 1?
If explicit peer restrictions are not supported on this hosting model, what documented alternative preserves trustworthy scheme/client-IP processing? If unrestricted forwarding is the intended approach, which platform ingress and header-normalization guarantees make that safe?

We are seeking authoritative documentation or App Service team guidance, rather than assuming a private/link-local address range is trusted. No application or customer data is included in this question.

0 comments

1 answer

Your answer

Answer 1

Hi Dave Mace & thx for join me at Q&A platform,

On multitenant Linux App Service, I wouldn’t build KnownProxies around the private IP address you happen to observe as Kestrel’s immediate peer. That address is part of the App Service infrastructure and can change when workers move, scale, or the platform topology changes. The documented App Service inbound/outbound IP addresses aren’t a list of trusted front-end proxy addresses. ASPNETCORE_FORWARDEDHEADERS_ENABLED=true is the supported ASP.NET Core mechanism for enabling forwarded headers in this hosting scenario, but, as you noted, it effectively removes the default proxy restrictions. There doesn’t appear to be a documented App Service API or stable CIDR list that can be used to populate KnownProxies/KnownNetworks for the final platform hop. I wouldn’t rely on the observed rightmost X-Forwarded-For behavior as a security contract unless App Service explicitly documents it. ForwardLimit = 1 only limits how many entries the middleware processes; it doesn’t by itself establish that the peer or selected header value is trustworthy.

If your security model requires cryptographically or topologically trustworthy client IP information with an explicitly controlled proxy boundary, the safer architecture is to put a proxy you control, such as Application Gateway or another appropriate ingress layer, in front of the app and restrict App Service so traffic can only arrive through that path. You can then configure ASP.NET Core to trust that known proxy/network rather than undocumented App Service infrastructure addresses.

For the direct-public-ingress case, the specific guarantees you’re asking about — stable identity of the final proxy, protection against peer impersonation, and exact normalization of caller-supplied X-Forwarded-For/X-Forwarded-Proto — really need an authoritative answer from the App Service engineering team. I don’t think it would be safe to infer those guarantees from sampled traffic or private/link-local addresses observed on a worker.

rgds,

Alex