Recently, we have been particularly disturbed by various security vulnerabilities, and we receive dozens of emails a week from security teams scanning for vulnerabilities. One of these vulnerabilities is easy to overlook, but has a very wide impact and is extremely harmful. You shouldn’t be surprised when I say its name, it’s the
Spring Boot Actuator.
Before writing this article, I did a little survey with my friends asking them about their knowledge of the
Spring Boot Actuator and the results were amazingly consistent. Everyone knows that Spring Boot provides automatic configuration of the
spring-boot-starter-actuator, but very few people actually use its related features. As you continue to read the article below, you can also think about the following questions.
- check whether you have introduced the
spring-boot-starter-actuatordependency in your development project?
- do you actually use the
spring-boot-starter-actuatorfunctionality in your project?
- Do you know the security risks of
spring-boot-starter-actuatorand the correct way to configure it?
What is a Spring Boot Actuator?
It’s been a while since I’ve looked through the spring documentation, so to explain this fairly new term, Actutor [ˈæktjuˌeɪtər], I went through its documentation and found the official definition.
Definition of Actuator
An actuator is a manufacturing term that refers to a mechanical device for moving or controlling something. Actuators can generate a large amount of motion from a small change.
Step 1 Importing dependencies
tips: spring-boot-starter-actuator has some configuration differences in different versions of Spring Boot, this article is using version 2.4.4.
Step 2 Understanding endpoint
The endpoint is the most important object we need to care about when using the
Spring Boot Actuator, so here are some endpoints you might be interested in.
|beans||View all objects in the Spring container|
|configprops||View the list of objects modified by @ConfigurationProperties|
|env||View the environment configuration information for the application.yaml configuration|
|health||Health Check Endpoints|
|mappings||Service contract @RequestMapping related endpoints|
For example, for
health, you only need to access the following endpoint to get the status of the application.
Step 3 Understanding the enable and exposure states of endpoints
Spring Boot Actuator provides two states of configuration for all endpoints
- enabled state. By default, all endpoints are enabled except for
shutdown. This is understandable, because while the other endpoints basically view behavior, shutdown affects the running state of the application.
- Exposed state. endpoint enabled is set to true, it needs to be exposed once before it can be accessed. by default only health and info are exposed.
When enabled is not enabled, the code of the associated endpoint is not loaded by the Spring context at all, so it doesn’t matter if exposure is configured when enabled is false.
A few typical configuration examples are:
Enable and expose all endpoints.
Enable and expose only the specified endpoint.
Disable all endpoints.
Or, get rid of the
Understanding the security risks of the Spring Boot Actuator
As you can see from the introduction above, there are endpoints provided by the
Spring Boot Actuator that expose important information about the application, so let’s take a look at a typical
application.yaml example using
env as an example.
The above configuration couldn’t be more classic. Let’s look at the return value after accessing
You can see that for the built-in sensitive configuration information
Spring Boot Actuator is desensitized, but for some custom sensitive configurations like kirito.ak and kirito.sk are exposed.
Some readers may immediately question this: our machines are deployed on intranets, and we generally expose services to the public through reverse proxies, so such endpoints are not accessible to external users. I can only say that it is too naive, for example, the following situations are the real case that lead to security vulnerabilities:
- The reverse proxy misconfigures the root node and exposes the endpoint of the actuator together with the web service.
- The online configuration is fine, but the public SLB is opened when the test environment is deployed, resulting in the actuator’s endpoint being exposed.
- A machine in the same environment was compromised, resulting in the application configuration information leaked.
For the endpoint provided by the
Spring Boot Actuator, there are several steps you can take to minimize the risk of security attacks.
- Expose the endpoint with minimal granularity; only enable and expose the actual endpoint used, not the configuration:
- Configure a separate access port for the endpoint, so that it is separate from the web service’s port, to avoid exposing the web service and accidentally exposing the actuator’s endpoint as well. Example:
- Add a
spring-boot-starter-securitydependency to configure access control for the actuator’s endpoint.
- Carefully evaluate the need to bring in
spring-boot-stater-actuator. In my personal experience, I haven’t come across any requirements that necessarily require the introduction of
spring-boot-stater-actuatorto solve, so if you don’t understand the security risks described above, I suggest you remove the dependency first.