X-Application-Context HTTP response header exposes internal server port

[gmarziou]

Using spring-boot 1.1.4.

Spring-boot-actuator's EndpointWebMvcAutoConfiguration.ApplicationContextFilterConfiguration registers a Filter that adds a response header X-Application-Context that contains the application id but it does not remove it and so the browser gets it.

By default, the application id is something like this "application:int:8080" which is a concatenation of the "application" (?), profile and server port.

In the scenario where the application is behind a reverse proxy, I find it a bit unsafe to expose the internal port number even though it should be not accessible from the external world.

Is there a way to disable this behavior without breaking actuator?

[philwebb]

There isn't currently a simple way to disable that header, but we can certainly add an option. In the meantime it appears that the header is actually exposing the ApplicationContext ID (take a look at EndpointWebMvcAutoConfiguration). The ID is set by ContextIdApplicationContextInitializer so the easiest fix is to replace context ID before requests are served.

Something like:

    public static void main(String[] args) throws Exception {
        SpringApplication.run(SampleTomcatApplication.class, args).setId("myapp");
    }

Should do the trick.

[gmarziou]

Thanks Phil for your answer, unfortunately the setId() comes too late because the init is done by the run().

[dsyer]

Apps in cloudfoundry don't have the port in the application context id, so it must be possible to change this behaviour if you need to. That works by just registering a listener that sets the context id.

Just out of interest: what exactly is the security issue (i.e. what could a bad guy do with the port information that he couldn't do without it)?

[gmarziou]

Being a good guy, I don't know ;) but I think the less information leaks is the best anyway.
Maybe CloudFoundry could say why they did it.

[bep]

I worked for customers being paranoid about leaking anything about the environment (that its running on Tomcat, internal ports etc.).

But this is a perfect task to let the reverse proxy handle - by having it removing those headers.

[dsyer]

It isn't cloudfoundry that changes the header, it's the VcapApplicationListener in Spring Boot. I was just using that as an example to demonstrate that you can customize it in the app if you want to.

[dsyer]

Looking at the source code for ContextIdApplicationContextInitializer I can see that you only need to set spring.application.index to non-null to change the port to an arbitrary opaque value of your choice.

[gmarziou]

Setting spring.application.name and spring.application.index in application.yml is a good solution.
Thanks

[pires]

Also, management.add-application-context-header: false disables this completely.