Azre Web App for Containers service does not respect the custom header configuration

Hi @Milan Rancic ,

Thank you for submitting your question on Microsoft Q&A.

Root cause: The headers are removed correctly in your IIS container locally, but when the same image runs on Azure App Service for Containers (Windows), Azure adds its own default headers (e.g., Server: Microsoft-IIS/10.0)

This happens because some responses are generated or modified by the App Service front-end (ARR/reverse proxy and platform pipeline) before they reach your container, so those headers don’t come from your IIS at all. Examples include the initial 301 redirect when “HTTPS Only” is enabled, malformed requests, or platform error pages. For these platform-generated responses, your IIS/web.config can’t suppress the headers because they’re added upstream. You also mentioned a .NET 6 web app but are building on an ASP.NET 4.8 Windows Server Core image, which contributes to the mismatch.

A note on the base image

mcr.microsoft.com/dotnet/framework/aspnet:4.8-windowsservercore-ltsc2022

That image is for .NET Framework (ASP.NET), not ASP.NET Core/.NET 6. For .NET 6 on Windows+IIS, use:

mcr.microsoft.com/dotnet/aspnet:6.0-windowsservercore-ltsc2022

Or (often simpler, more secure, and lighter) switch to Linux App Service with:

mcr.microsoft.com/dotnet/aspnet:6.0

Microsoft’s official guidance and tags for ASP.NET Core images are here.

Using the correct base image ensures the ASP.NET Core Module and hosting model are aligned, and avoids odd behaviors that sometimes occur when mixing runtimes.

Keep App Service public, add an edge layer to rewrite response headers

Put Azure Front Door (recommended) or Application Gateway v2 in front of your two App Services (frontend and backend) and use rules to delete or overwrite response headers. Apply the same rule set to both origins for consistency.

Front Door (Standard/Premium) steps

1. Create a Rule Set -> add an action Modify response header.
2. For each header you want to hide, set:
   • Action: Delete
     • HeaderName: Server, X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version
3. Associate the rule set with the routes/endpoints serving your domains. Docs: rule-set actions and scenarios (modify response headers, security headers).

This fully hides upstream platform headers because the edge becomes the final responder.

Application Gateway v2 You can add a Rewrite Rule Set to remove response headers for traffic that passes through the gateway. However, be aware of a limitation: headers cannot be rewritten for responses generated directly by the gateway (many 4xx/5xx), so some error cases may still show a gateway Server header.

Make App Service private; edge handles all public traffic

Place your App Services behind Private Endpoints or in an ILB ASE and front them with Front Door Premium or Application Gateway v2. All public responses originate from the edge layer, where you control headers via rules as in Option A. (This also hardens your exposure.)

Option C Minimize residual headers inside the app (for worker-originated responses)

Even though this won’t affect front-end–generated responses, you should still keep your app clean:

• IIS 10+ supported removal of Server via requestFiltering removeServerHeader="true" (what you have). Reference: IIS config docs and Azure guidance/blog.
• Remove X-Powered-By via <httpProtocol><customHeaders><remove name="X-Powered-By" /></customHeaders></httpProtocol>.
• Disable X-AspNet-Version via <system.web><httpRuntime enableVersionHeader="false" /></system.web>. [serverfault.com]
• If you host Kestrel directly (Linux), you can also disable its own server header at startup (AddServerHeader=false).

Handle HTTPS redirect in-app (narrow workaround)

If the first 301 comes from Azure’s HTTPS-only setting, it may include the platform Server header. Disabling HTTPS Only in App Service and doing the redirect in your app makes that first response originate from your site, so your header settings apply. (Trade-off: you assume redirect logic and must get HSTS correct.)

Suggested implementation for your two-site setup (frontend + WebAPI)

1. Fix the base images
   • Frontend .NET 6 (Windows): mcr.microsoft.com/dotnet/aspnet:6.0-windowsservercore-ltsc2022
   • Or consider Linux App Service with mcr.microsoft.com/dotnet/aspnet:6.0 for simpler hosting and smaller image.
2. Keep/confirm web.config settings inside each site (Option C).
3. Add Azure Front Door (Std/Premium) in front of both apps (two origins), and attach Rule Set to delete the headers listed above (Option A). Docs and scenarios for response-header modification
4. (Optional) If you prefer Application Gateway v2, add a rewrite-rule set to remove headers, but be mindful of the gateway error-response limitation.
5. Validate with curl: Shell Expect NO Server/X-Powered-By from the public endpoint after rules apply curl -I https://your-frontend-domain curl -I https://your-backend-domain/api/health Show more lines Clear Front Door cache after rule changes if you test any cached resources.

Reference:

https://learn.microsoft.com/en-us/azure/frontdoor/front-door-rules-engine-actions?tabs=portal&pivots=front-door-standard-premium

https://learn.microsoft.com/en-us/iis/configuration/system.webServer/security/requestFiltering/

https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/docker/building-net-docker-images?view=aspnetcore-10.0

Kindly let us know if the above comment helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.