spring-boot-starter-actuator is safe to run in production, but only if you treat its endpoints as sensitive by default — an exposed /actuator/env or /actuator/heapdump will hand an attacker your credentials in plaintext. The starter itself is a legitimate, valuable dependency for health checks, metrics, and operational visibility. The danger is almost never the library; it is the deployment that leaves its endpoints reachable without authentication.
What the starter pulls in
Adding the coordinate is a one-liner:
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Behind that starter sits spring-boot-actuator-autoconfigure, the module that auto-configures the actual endpoints, plus spring-boot-actuator for the core machinery. When people search Maven for spring-boot-actuator-autoconfigure, they are usually looking at the autoconfiguration layer that decides which endpoints get wired up based on what is on the classpath. You rarely declare spring-boot-actuator-autoconfigure directly — the starter brings it in transitively.
The starter gives you endpoints under /actuator: health, info, metrics, env, configprops, beans, mappings, threaddump, heapdump, and more depending on your Spring Boot version.
Why exposure is the real vulnerability
The high-value endpoints leak the kind of data that makes the rest of an attack trivial:
/actuator/envreturns the resolved SpringEnvironment: property values from config files, environment variables, and external sources. Database passwords, API keys, OAuth client secrets, and JWT signing keys routinely surface here./actuator/heapdumpproduces a full JVM heap dump. Anything in memory — decrypted secrets, session tokens, credentials — is in that file. Researchers have pulled plaintext cloud keys straight out of a heap dump from a single unauthenticated endpoint./actuator/configpropsand/actuator/beansmap out your entire configuration and object graph, a reconnaissance goldmine.
A well-known real-world case involved an exposed heap dump on a vehicle telematics service that yielded plaintext AWS credentials, which in turn unlocked terabytes of location data. Shodan sweeps continue to find thousands of internet-facing actuator deployments leaking this data. The Wiz writeup on actuator misconfigurations walks through several patterns worth understanding.
The default posture changed, and it matters which version you run
The behavior of the starter has shifted meaningfully across major versions, so the version you run dictates your default risk:
- In Spring Boot 1.x, most endpoints were exposed over HTTP by default. That era produced a lot of the leaks still catalogued today.
- From Spring Boot 2.0 onward, only
healthandinfoare exposed over the web by default. Everything else must be opted in throughmanagement.endpoints.web.exposure.include.
That default is good, but teams routinely undo it. The single most dangerous line you can put in an application.properties is:
# Do NOT do this in production
management.endpoints.web.exposure.include=*
That one wildcard re-exposes env, heapdump, and everything else. If you inherited a config with that line, that is your finding.
A safe configuration baseline
Start from least exposure and add back only what you need:
# Expose the minimum over HTTP
management.endpoints.web.exposure.include=health,info
# Move the whole actuator surface to a separate, firewalled port
management.server.port=8081
# Never leak full config values in health details to anonymous callers
management.endpoint.health.show-details=when-authorized
Then put authentication in front of the management endpoints with Spring Security so that even internally reachable endpoints require a role:
@Bean
SecurityFilterChain actuatorSecurity(HttpSecurity http) throws Exception {
http.securityMatcher(EndpointRequest.toAnyEndpoint())
.authorizeHttpRequests(auth -> auth
.requestMatchers(EndpointRequest.to("health", "info")).permitAll()
.anyRequest().hasRole("ACTUATOR_ADMIN"))
.httpBasic(withDefaults());
return http.build();
}
The combination that actually protects you: keep heapdump and env off the web exposure list, bind the management port to an interface that is not internet-facing, and require authentication on whatever remains. Any one of those alone is fragile; together they are defense in depth.
Do not rely on the dependency scanner alone here
This is a case where a clean software composition analysis report does not mean you are safe. SCA tells you whether the spring-boot-actuator version has a known CVE. It cannot tell you that a deployment shipped exposure.include=* behind a public load balancer — that is a configuration and runtime problem. Pair dependency scanning with a runtime check that probes /actuator/env and /actuator/heapdump from an unauthenticated position, and add that probe to your dynamic testing suite so a regression in the ingress config gets caught before an attacker finds it.
If you run a fleet of Spring Boot services, centralize the actuator security config in a shared auto-configuration or parent module. Relying on every team to remember the safe defaults is how one service ends up with the wildcard.
Verifying your own exposure
From outside your network, the check is blunt and effective:
# Should return 401/403 or 404, never a 200 with data
curl -s -o /dev/null -w "%{http_code}\n" https://your-app.example.com/actuator/env
curl -s -o /dev/null -w "%{http_code}\n" https://your-app.example.com/actuator/heapdump
A 200 on either of those from an unauthenticated request is a live incident, not a hardening backlog item. Rotate any credentials that could have been in memory, because you cannot know whether the endpoint was scraped before you found it.
FAQ
Is spring-boot-starter-actuator itself a vulnerability?
No. The starter is a supported, useful dependency. The risk comes from exposing sensitive endpoints like env and heapdump without authentication, which is a configuration mistake rather than a flaw in the library.
What is spring-boot-actuator-autoconfigure?
It is the module, pulled in transitively by the starter, that auto-configures actuator endpoints based on what is on your classpath. You generally do not declare spring-boot-actuator-autoconfigure directly in Maven; the starter manages it for you.
Which endpoints are exposed by default?
Since Spring Boot 2.0, only health and info are exposed over HTTP by default. Everything else, including env and heapdump, must be explicitly added to management.endpoints.web.exposure.include.
How do I stop leaking secrets through /actuator/env?
Keep env off the web exposure list, run the management endpoints on a separate non-public port, require authentication via Spring Security, and set management.endpoint.health.show-details=when-authorized. Then verify with an external curl that the endpoint returns 401/403/404 to anonymous callers.