In the past I have dealt with security issues related to Default Service Banners/Verbose Headers/Information Leakage via HttpResponse Headers. These issues are quite common, and usually look something like this for an Asp.Net - IIS Server.
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
These types of issues are very common, and usually quite trivial to deal with, typically a web.config update or an URLRewrite rule to remove the verbose headers.
However, one issue I stumbled upon lately, is when the Server encounters an error, these headers are not removed. For example a 404 (not found) error will still have these headers appended on. In fact most error responses are not able to properly remove the information leakage headers. I did some searching and found out this issue is not very well documented, in fact it has never come up in one of our Pen-Tests specifically.
I am curious if any other developers have dealt with this issue, specifically information leakage in HttpResponse Headers when the response code is an Error. If so, how did you fix it. I am using Microsoft, Asp.Net, IIS technologies, but still curious if other technologies/servers have this issue.
Thanks to Cody (Security Champion) response.
reviving an old thread here, but we have had many applications to mitigate this problem for. we've actually done it at the load balancer level, so that all responses, error or otherwise, are treated the same
we're doing that with an iRule for F5 - iRules Home
https://clouddocs.f5.com/api/irules/
the irule has an array of blacklisted header names, and just removes those on every response
if you're trying to accomplish the same thing within AWS or some other managed load balancing mechanism, unfortunately i'm not sure how you would go about doing that