Spring-boot: X-Application-Context HTTP response header exposes internal server port

Created on 29 Jul 2014  路  9Comments  路  Source: spring-projects/spring-boot

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?

enhancement

Most helpful comment

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

All 9 comments

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.

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

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)?

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.

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.

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.

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.

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

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

Was this page helpful?
0 / 5 - 0 ratings