Disabling Server Header

[cemo]

Please provide an option to disable Server Header for Jetty.

HttpConfiguration httpConfig = new HttpConfiguration();
httpConfig.setSendServerVersion( false );

[snicoll]

Would #4461 help?

[philwebb]

Does the server header currently get written? Looking at the Jetty source it appears that sendXPoweredBy defaults to false.

[cemo]

@philwebb I was referring Server header in response.

...
Expires:0
Pragma:no-cache
Server:Jetty(9.2.z-SNAPSHOT)
X-Application-Application:8080

[cemo]

@snicoll This is helping to overwrite this value as far as I understand. But this does not help to disable completely.

[philwebb]

We should probably address this at the same time as #4461. Depending on what Tomcat/Undertow do we might also want to change the default.

[philwebb]

Unfortunately it doesn't look like it's possible to completely disable the header on Tomcat. See AbstractHttp11Processor for the relevant code.

I was originally thinking about supporting server.server-header= (i.e. an empty string) to disable the header but I'm not keen to introduce something that works differently across the servlet containers.

Is there any specific reason that you want to completely remove the header?

[cemo]

My biggest concern is security. This is creating unnecessary overhead in network traffic.

I understand your point in terms of consistency and it is pretty much valid but most of the times we can not find a common interest in all containers for a feature. For example Spring Boot is configuring access log of Tomcat but not Jetty's by default.

At best we can include a property for disabling this header for all containers but throw exception to refuse start application with a description and related issue in Tomcat issue tracker.

[philwebb]

The extra property probably makes most sense, at least we can then fail hard when we can't support it. We could also ask Tomcat to add an option to disable the header.

The existing solution will at least let you alleviate security concerns by doing something like this:

server.server-header=unspecified

[rwinch]

@markt-asf Do you have any insight as to how to disable the Server header completely for Tomcat? If not, is this something that we think could be fixed? As mentioned before, this would help to secure Tomcat and prevent Information Leakage. Also see http://www.acunetix.com/blog/articles/configure-web-server-disclose-identity/

[markt-asf]

You can't disable the Server header completely.

The security benefits of disabling the server header are marginal at best and fall mostly under the heading of security by obscurity - which is no security at all. Anyone worried about security would be better off spending their time keeping their Tomcat instance up to date with the latest release rather than trying to disguise the fact it is a Tomcat instance.

An enhancement request to disable the header is very unlikely to get any positive attention from me. I'd likely argue against it as pointless but unless the proposed patch was going to have a significant performance impact (looking at the source code it shouldn't) then I'm unlikely to veto it.

[rwinch]

@markt-asf Thank you for the response.

The security benefits of disabling the server header are marginal at best and fall mostly under the heading of security by obscurity - which is no security at all.

In my opinion there is a big difference on relying on obscurity and preventing information leakage. If your security depends on obscurity (i.e. that is the only security measure you take), then I think we can agree this is bad.

However, as I'm sure you are aware, security is best in depth. To me this means preventing information leakage (removing the header) does provide value.

Users could set the Tomcat header to something non nonsensical, but this gives information away too. Most servers provide a way to disable the header completely, so this reveals that the user is likely using an application server that does not support it.

I don't think I am alone in this view since there are many knowledgeable security experts that recommend removing the Server header as well.

An enhancement request to disable the header is very unlikely to get any positive attention from me. I'd likely argue against it as pointless but unless the proposed patch was going to have a significant performance impact (looking at the source code it shouldn't) then I'm unlikely to veto it.

I went ahead and created https://bz.apache.org/bugzilla/show_bug.cgi?id=58750

[rwinch]

NOTE: Anyone on this chain interested in Tomcat supporting removal of the Server header, please vote on https://bz.apache.org/bugzilla/show_bug.cgi?id=58750

[zibbly]

I very much support being able to disable the return of the server in the response header. It would be terrific to see this in 1.3.2 if at all possible.

Adding the ability to remove the server header completely is the issue that I should have raised instead of #4461, but knowing that Tomcat doesn't support that I opted for the ability to set the header to something other than the default.

The server.server-header property, implemented via #4461, may still serve some use in attempts to hide the server being used. In a non-security context for debug/testing and perhaps even production purposes the server.server-header property might even be used with values that help determine the deployment server from which responses have come.

It's encouraging that via #4730 and https://bz.apache.org/bugzilla/show_bug.cgi?id=58750 there might be some traction to implementing in Tomcat the ability to either remove the server from the response header or not have it there in the first place (I think that's the default in Undertow). I completely agree with the comments made by @rwinch on this issue here and in https://bz.apache.org/bugzilla/show_bug.cgi?id=58750. And I think it's worth re-reading http://www.troyhunt.com/2012/02/shhh-dont-let-your-response-headers.html.

Before raising #4461 I'd consulted the Tomcat documentation (https://tomcat.apache.org/tomcat-8.0-doc/config/http.html) and for the server attribute it says...

Overrides the Server header for the http response. If set, the value for this attribute overrides the Tomcat default and any Server header set by a web application. If not set, any value specified by the application is used. If the application does not specify a value then Apache-Coyote/1.1 is used. Unless you are paranoid, you won't need this feature.

I was disappointed to read the remark saying "Unless you are paranoid, you won't need this feature". I don't think anybody is paranoid for trying to harden the security of their application. The attribute could also be set for the server identification purpose I described above - in which case there's certainly no paranoia involved.

[lpandzic]

If anyone is using jetty 9 and boot use the EmbeddedServletContainerCustomizer:

@Bean
public EmbeddedServletContainerCustomizer customizer() {
    return container -> {
        if (container instanceof JettyEmbeddedServletContainerFactory) {
            ((JettyEmbeddedServletContainerFactory) container).addServerCustomizers(server -> {
                        for (Connector connector : server.getConnectors()) {
                            if (connector instanceof ServerConnector) {
                                HttpConnectionFactory connectionFactory = connector.getConnectionFactory(HttpConnectionFactory.class);
                                connectionFactory.getHttpConfiguration().setSendServerVersion(false);
                            }
                        }
                    }
            );
        }
    };
}

[pires]

I support this issue as well because this header exposes information on the stack, i.e. JVM present that I'd like not to be received by the users.

Thanks to all the workaround tips.

[orubel]

definitely a good idea. Excessive header information that is unnecessary adds to overhead of a response. Should eliminate all excessive headers when possible.

[arakelian]

If you can't disable it, just overwrite it. Tomcat won't add a Server header if there is one already.

public class SecurityConfig extends WebSecurityConfigurerAdapter {
  protected void configure(HttpSecurity http) throws Exception {
    http
      .headers()
        .addHeaderWriter(new StaticHeadersWriter("Server","None of your business"))
      ....
  }
  ...
}

[bclozel]

This behavior has changed in Tomcat 9.0.x and 8.5.x - see this Tomcat issue.

@snicoll, @philwebb - something to be reconsidered in a future Boot version then?

[philwebb]

I think we should wait until we're on 8.5 (or 9) then we can behave in the same way for all servers. My vote would be to not send the header at all for any of them by default.

[vpavic]

Since #6164 was added to 1.4.0.RC1 could this one be tackled in the same milestone as well?

[wilkinsona]

@vpavic I can't see why not

[wilkinsona]

I spoke to soon. There are several breaking changes in 8.5.x.

[zibbly]

Just wondering whether this is still possible for the 1.4.0.RC1 milestone (that would be great) or does the 2.0.0 milestone need to go back on?

[wilkinsona]

Now that we've managed to upgrade to Tomcat 8.5, we can do this in 1.4