Introduction

Disabling Spring Boot Actuator endpoints is usually a configuration problem, not a security-filter problem. The most important distinction is between an endpoint being disabled and an endpoint merely being inaccessible. If you truly want an actuator endpoint turned off, the cleanest solution is to set actuator properties before the application context starts, even when you choose to do that from Java instead of application.yml.

Disable Versus Secure

An endpoint can be in one of several states:

• enabled and exposed
• enabled but not exposed on the web
• enabled but protected by security
• disabled entirely

These are not equivalent. If your goal is to remove the endpoint bean or prevent actuator from wiring it up, that is different from adding Spring Security rules that return 403.

Property-Based Control Is the Canonical Mechanism

Spring Boot actuator endpoint enablement is driven by configuration properties. Even when people ask for "Java config," the practical implementation is often setting those properties programmatically.

For example, to disable env and beans while still exposing health and info:

1import java.util.HashMap;
2import java.util.Map;
3import org.springframework.boot.SpringApplication;
4import org.springframework.boot.autoconfigure.SpringBootApplication;
5
6@SpringBootApplication
7public class DemoApplication {
8    public static void main(String[] args) {
9        SpringApplication app = new SpringApplication(DemoApplication.class);
10
11        Map<String, Object> props = new HashMap<>();
12        props.put("management.endpoint.env.enabled", false);
13        props.put("management.endpoint.beans.enabled", false);
14        props.put("management.endpoints.web.exposure.include", "health,info");
15
16        app.setDefaultProperties(props);
17        app.run(args);
18    }
19}

This is Java-based configuration, but it still uses the official actuator configuration model.

Disabling All Endpoints Except a Few

Sometimes the safest approach is to disable broad exposure first and then explicitly allow only what you need.

1Map<String, Object> props = new HashMap<>();
2props.put("management.endpoints.enabled-by-default", false);
3props.put("management.endpoint.health.enabled", true);
4props.put("management.endpoint.info.enabled", true);
5props.put("management.endpoints.web.exposure.include", "health,info");

This pattern is easier to audit because the default posture is restrictive.

Exposure Is a Separate Layer

Even an enabled endpoint is not automatically exposed over HTTP. Web exposure is controlled separately.

props.put("management.endpoints.web.exposure.exclude", "env,beans,heapdump");

That setting prevents those endpoints from being exposed on the web, but it does not necessarily disable them internally. If you need them completely off, use the endpoint-specific enabled properties too.

Do Not Use Security Rules as a Substitute for Disabling

A common mistake is writing security configuration that blocks /actuator/** and then assuming the endpoints are disabled. They are not. They still exist; they are just protected.

That may be acceptable from an access-control perspective, but it is a different operational choice. If you want fewer beans, fewer exposed management surfaces, or clearer application behavior, disable the endpoint directly.

Environment-Specific Java Configuration

If you still want the settings to vary by environment, Java config can read profiles or environment variables before populating default properties.

1String profile = System.getenv().getOrDefault("APP_PROFILE", "dev");
2if ("prod".equals(profile)) {
3    props.put("management.endpoints.enabled-by-default", false);
4    props.put("management.endpoint.health.enabled", true);
5}

This is useful when configuration is generated dynamically, though plain externalized configuration is often simpler.

Prefer Simplicity When Possible

If there is no strong reason to do this in Java, using application.yml is usually cleaner and easier to maintain. The important point is not whether the configuration lives in Java or YAML. It is that endpoint enablement should be expressed with actuator properties rather than improvised filtering logic.

Common Pitfalls

• Confusing disabled endpoints with secured endpoints.
• Excluding an endpoint from web exposure and assuming it is fully disabled.
• Trying to control actuator beans with late lifecycle hooks after the context has already started.
• Writing custom security rules when actuator properties would solve the problem directly.
• Forgetting that management.endpoints.enabled-by-default=false changes the starting point for all endpoints.

Summary

• Disabling actuator endpoints is primarily a configuration concern.
• Java config can disable endpoints by setting actuator properties before startup.
• 'enabled and web exposure are related but different controls.'
• Security rules do not actually disable an endpoint.
• If you want a restrictive setup, disable endpoints by default and enable only the few you need.