Yes. Spring Boot secures Actuator endpoints other than health when Spring Security is on the classpath and no other SecurityFilterChain bean exists. Once you define your own chain, the auto configuration backs off and your rules decide who can reach Actuator. Add explicit rules for it.
What Boot does by default
The Spring Boot Actuator documentation says only the health endpoint is exposed over HTTP by default. It also says that if Spring Security is present and you have not defined any other SecurityFilterChain bean, all actuators other than health are secured by auto configuration.
The Spring Boot security documentation states the flip side: adding a bean of type SecurityFilterChain switches off the default web security configuration, including Actuator security. Actuator then follows whatever you wrote.
Why this catches teams out
A developer adds a custom chain to permit a public login page or configure a JSON API. It compiles, the app works, and nobody notices that the safety net for Actuator is gone. If exposure was also widened to include more endpoints, those paths may now fall under a broad permit rule or the catch all of your chain.
| Situation | Result |
|---|---|
| No custom chain, default exposure | Health only over HTTP |
| No custom chain, wider exposure | Non health endpoints secured by Boot |
| Custom chain, default exposure | Health only is reachable, but your rules govern it |
| Custom chain, wider exposure | Reachability depends entirely on your rules |
How to cover Actuator in your own chain
Spring Boot provides request matcher helpers for Actuator endpoints, so you do not have to hardcode paths. The Actuator docs describe them as convenient for custom rules, such as allowing only users with a certain role.
- Decide which endpoints you truly need exposed, using the include property.
- In your chain, add a rule for the Actuator matcher that requires a role.
- Leave health open only if your load balancer needs it, and consider a separate management port.
- Make sure the catch all rule at the end requires authentication.
- Write a test that calls an Actuator path without credentials and expects a rejection.
For the exposure side of the story, see Spring Boot Actuator: which endpoints are exposed.
Review prompt
Whenever a pull request adds or edits a SecurityFilterChain bean, ask: what happened to the Actuator rules? A scanner can tell you about vulnerable libraries, but this kind of gap is configuration, so it belongs in review and tests.
Safeguard scans dependencies, produces SBOMs and uses reachability analysis to show which findings your code can actually reach. You can run a free scan at gold.safeguard.sh/scan.
Quick check
Does a custom chain also remove the default user?
No. The Boot docs say adding a SecurityFilterChain does not disable the UserDetailsService configuration. A UserDetailsService, AuthenticationProvider or AuthenticationManager bean does.
Is the health endpoint always safe to leave open?
It depends on what details it shows. See our post on the health show details property.
Sources
Last reviewed: 19 October 2026.
