Application Gateway for Containers (AGC) — unable to remove/override Server: Microsoft-Azure-Application-LB/AGC response header

Question

Application Gateway for Containers (AGC) — unable to remove/override Server: Microsoft-Azure-Application-LB/AGC response header

Michael Vivet 40

Environment:

Application Gateway for Containers (Gateway API, gatewayClassName: azure-alb-external)
ALB Controller managed deployment
HTTPRoute on both HTTP (port 80, redirect) and HTTPS (port 443) listeners

Issue: All responses through AGC include Server: Microsoft-Azure-Application-LB/AGC in the response headers. I'm trying to remove or override this header for security/pentest compliance reasons, but neither remove nor set via ResponseHeaderModifier has any effect on it.

What I've tried:

Removing the header:

filters:
  - type: ResponseHeaderModifier
    responseHeaderModifier:
      remove:
        - Server

Overriding the value

filters:
  - type: ResponseHeaderModifier
    responseHeaderModifier:
      set:
        - name: Server
          value: "N/A"

Both were applied to the HTTPRoute bound to the HTTPS listener (sectionName: https), and the route confirmed Accepted/Programmed status. Neither had any effect — the header is still returned unmodified. I also tested on the HTTP - HTTPS redirect route (RequestRedirect filter) with the same result.

Question:

Is Server header removal/override supported on AGC via ResponseHeaderModifier, given it appears to be injected at the edge/frontend layer rather than coming from the backend response? If not, is this on the roadmap, and is there any supported workaround (e.g., via SecurityPolicy/WAF or another mechanism)?

For context: I'm aware this is a known, unresolved limitation on classic Application Gateway V2 (rewrites don't apply to gateway-generated responses — ref), but I haven't found equivalent documentation confirming this for AGC specifically.

Mythreya Asnala 0 Reputation points Microsoft External Staff Moderator

2026-07-14T10:50:11.56+00:00
Hi Michael Vivet!

You’re using Application Gateway for Containers (AGC) with Gateway API (gatewayClassName: azure-alb-external) and you’ve configured ResponseHeaderModifier on both HTTP and HTTPS HTTPRoutes—but the response header Server: Microsoft-Azure-Application-LB/AGC is still present and can’t be removed/overridden.

What we can confirm from the provided docs

The provided AGC documentation we have here is about header rewrite for AGC, and it explicitly describes examples of request-header modification (e.g., stripping request headers before they go to the backend) using Gateway API / Ingress API.

However, the docs content we were given does not state that AGC supports removing/overriding gateway-generated response headers like Server, nor does it document ResponseHeaderModifier behavior specifically for headers injected at the edge/frontend layer.

What we can cite from the provided information:

AGC “Header rewrite” examples show modifying headers as traffic flows between client and backend, and include a note that modifying Host with requestHeaderModifier is not supported (and to use URLRewrite instead).

The “Troubleshoot Application Gateway header and URL routing configuration issues” doc indicates that Application Gateway v2 and WAF v2 can add/remove/update HTTP request/response headers, but it doesn’t call out AGC’s specific response-header behavior or limitations for gateway-generated headers.

Given the lack of explicit documentation in what you provided, we can’t definitively confirm whether ResponseHeaderModifier is intended to control Server on AGC, especially if that header is added by the gateway edge.

Likely explanation (based on your observation)

Your hypothesis—“Server appears to be injected at the edge/frontend layer rather than coming from the backend response”—is consistent with how edge/load-balancer products often behave (they add their own server-identification headers regardless of backend).

So from an engineering guidance standpoint: it’s plausible that AGC does not currently support removing/overriding the platform-generated Server header via ResponseHeaderModifier, or that the modifier doesn’t apply to that specific header.

What you can try / supported workaround (based only on provided info)

The only workaround mentioned in the provided docs is for request-side header behavior and for Host specifically (use URLRewrite instead of requestHeaderModifier). There’s nothing provided here about using WAF/SecurityPolicy to strip the Server response header on AGC.

So with the current documentation set, we can’t provide a verified AGC/WAF workaround for Server removal.

To further troubleshoot the issue please provide the below requested information

Are you using ALB managed deployment only, or have you also tested BYO (bring-your-own) deployment?

Can you confirm the exact Gateway API HTTPRoute filter section that contains ResponseHeaderModifier for the HTTPS listener (including the full filter structure)?

Are you seeing Server: Microsoft-Azure-Application-LB/AGC even for responses generated without hitting any backend (for example, redirects or 404s)?

Which backend app/framework is behind the route, and does it ever set its own Server header (or do you see only the AGC one)?

Are you able to share (redacting PII) any AGC/ALB controller logs related to applying the HTTPRoute/filters?

Once we have those details, we can better determine whether this is an unsupported case/limitation vs. a configuration-path issue.

Please follow the below Documents for reference:

Application Gateway for Containers – General / overview https://learn.microsoft.com/azure/application-gateway/for-containers/concepts-how-application-gateway-for-containers-works (Document section provided: “General - Application Gateway for Containers deployment”)

Header rewrite for Azure Application Gateway for Containers – Gateway API https://learn.microsoft.com/azure/application-gateway/for-containers/how-to-header-rewrite-gateway-api

Header rewrite for Azure Application Gateway for Containers – Ingress API https://learn.microsoft.com/azure/application-gateway/for-containers/how-to-header-rewrite-ingress-api

Troubleshoot Application Gateway header and URL routing configuration issues (v2/waf v2 header rewrite capability + limitations pointer) https://docs.microsoft.com/azure/application-gateway/rewrite-http-headers-url (And the “Troubleshoot…” page referenced in the provided content)

Application Gateway for Containers – troubleshooting guide (link referenced in the provided general doc) https://learn.microsoft.com/azure/application-gateway/for-containers/troubleshooting-guide

FAQ: Application Gateway for Containers (listed in provided general doc resources) https://learn.microsoft.com/azure/application-gateway/for-containers/faq
Michael Vivet 40 Reputation points

2026-07-14T16:18:36.0666667+00:00
Thanks for the response. A few clarifications:

Deployment: ALB managed deployment only, not BYO.

HTTPRoute filter: Already shared in my original ticket — both remove and set variants of ResponseHeaderModifier, applied to the HTTPS listener route. Route status confirmed Accepted/Programmed in both cases.

Yes — the Server header appears even on the 301 redirect from the HTTP→HTTPS route, which has no backend involved at all (RequestRedirect filter only). This is actually the clearest evidence the header is edge-injected, not backend- or filter-chain-related.

Backend is ASP.NET Core, and it does not set its own Server header (disabled by default in Kestrel unless explicitly enabled). Only the AGC-injected header is present.

Can provide ALB controller logs if genuinely useful, but I don't believe they'll show anything beyond confirming the route was programmed correctly — which we've already verified via kubectl get httproute -o yaml.

To be clear on the core question: this isn't a config or troubleshooting issue on my end — ResponseHeaderModifier is confirmed working for other headers, and the route is correctly programmed. The specific behavior I need confirmed is whether Server is deliberately excluded from ResponseHeaderModifier's scope because it's stamped after the filter chain runs, at the AGC edge/frontend layer — same limitation as classic App Gateway V2. If that's the case, no route-level config on my side can fix it, and I'd like to know if there's a roadmap item for this, since it's blocking a pentest/compliance requirement.

1 answer

Your answer

Michael Vivet 40 Reputation points

2026-07-14T16:18:36.0666667+00:00

Thanks for the response. A few clarifications:

Deployment: ALB managed deployment only, not BYO.

HTTPRoute filter: Already shared in my original ticket — both remove and set variants of ResponseHeaderModifier, applied to the HTTPS listener route. Route status confirmed Accepted/Programmed in both cases.

Yes — the Server header appears even on the 301 redirect from the HTTP→HTTPS route, which has no backend involved at all (RequestRedirect filter only). This is actually the clearest evidence the header is edge-injected, not backend- or filter-chain-related.

Backend is ASP.NET Core, and it does not set its own Server header (disabled by default in Kestrel unless explicitly enabled). Only the AGC-injected header is present.

Can provide ALB controller logs if genuinely useful, but I don't believe they'll show anything beyond confirming the route was programmed correctly — which we've already verified via kubectl get httproute -o yaml.

To be clear on the core question: this isn't a config or troubleshooting issue on my end — ResponseHeaderModifier is confirmed working for other headers, and the route is correctly programmed. The specific behavior I need confirmed is whether Server is deliberately excluded from ResponseHeaderModifier's scope because it's stamped after the filter chain runs, at the AGC edge/frontend layer — same limitation as classic App Gateway V2. If that's the case, no route-level config on my side can fix it, and I'd like to know if there's a roadmap item for this, since it's blocking a pentest/compliance requirement.

Answer 1

Christos Panagiotidis 3,301

Hi, the Microsoft-Azure-Application-LB/AGC Server header is added by the managed Application Gateway for Containers data plane, so a backend response-header rewrite may not be able to remove or replace it if AGC adds it after your rule runs. Confirm the current AGC rewrite/header-modification support matrix for your API version, but do not rely on an undocumented ordering trick. If removing that header is a hard security or compliance requirement, put a component that supports response-header removal in front of or behind AGC, such as an application proxy, APIM, or a supported edge service, and validate the final response externally. I would also open a product support request with the ALB controller and Gateway API versions so Microsoft can confirm whether header suppression is supported or planned.

Michael Vivet 40 Reputation points

2026-07-15T07:50:29.97+00:00

I don't think it's supported, but I don't understand why since this will be reported in every pen-test and is a security flaw. Unfortunately, I can't create a support request, not sure why, but that's a different issue. Mostly, I just wanted an explanation and possibly timeline for a fix, though I am unsure if Microsoft will even fix it, because the same issue exists in their older Load Balancer V2.