As a developer I am really happy to have an easy way to determine which version of a software I’m running. But I do not like it if my software tells everyone its name and version, as this gives important fingerprinting information to possible attackers.

If you use WildFly versions 8 through 10 or JBoss EAP version 7 the default configuration includes some HTTP headers that are too verbose in my opinion. JBoss EAP 6 is not affected by the way. The headers you get look like this

Server: JBoss-EAP/7
X-Powered-By: Undertow/1

Getting rid of these headers is really easy. So I think the tiny effort to remove these headers should be put into any project even if the probability of getting attacked and the possible impact are really small.

To fix the problem let’s have a look at the default configuration in the standalone.xml:

<subsystem xmlns="urn:jboss:domain:undertow:3.1">
    <buffer-cache name="default"/>
    <server name="default-server">
        <http-listener name="default" socket-binding="http" redirect-socket="https"/>
        <host name="default-host" alias="localhost">
            <location name="/" handler="welcome-content"/>
            <filter-ref name="server-header"/>
            <filter-ref name="x-powered-by-header"/>
        </host>
    </server>
    <servlet-container name="default">
        <jsp-config/>
        <websockets/>
    </servlet-container>
    <handlers>
        <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
    </handlers>
    <filters>
        <response-header name="server-header" header-name="Server" header-value="JBoss-EAP/7"/>
        <response-header name="x-powered-by-header" header-name="X-Powered-By" header-value="Undertow/1"/>
    </filters>
</subsystem>

To remove the verbose headers just remove the lines in bold font. And as you’re already working on this part of the configuration you may as well remove the just as verbose welcome page by removing the lines in italics as well – just in case you ever have it exposed by accident.

Summary

After this procedure fingerprinting error messages for example will still be possible – but it will be less obvious what exact platform you are using.

Relying on security by obscurity is not a good idea, though neither is handing a possible attacker good reconnaissance for free. I usually recommend to withheld verbose information from attackers while at the same time not to rely on the attacker to not know – i.e. making an application as secure as possible at the same time.