Spring Boot Actuator in Production: The Endpoints I Left Open by Accident and How I Closed Them

I was reviewing the configuration of a Spring Boot 3.x backend I've been building — the same one I talked about in Jakarta EE vs Spring Boot — when I did something I should have done on day one: a simple curl against /actuator.

The response hit me like a bucket of cold water.

{
  "_links": {
    "self":        { "href": "http://localhost:8080/actuator" },
    "beans":       { "href": "http://localhost:8080/actuator/beans" },
    "health":      { "href": "http://localhost:8080/actuator/health" },
    "info":        { "href": "http://localhost:8080/actuator/info" },
    "env":         { "href": "http://localhost:8080/actuator/env" },
    "loggers":     { "href": "http://localhost:8080/actuator/loggers" },
    "metrics":     { "href": "http://localhost:8080/actuator/metrics" },
    "mappings":    { "href": "http://localhost:8080/actuator/mappings" },
    "threaddump":  { "href": "http://localhost:8080/actuator/threaddump" },
    "heapdump":    { "href": "http://localhost:8080/actuator/heapdump" }
  }
}

Ten endpoints. No authentication. /actuator/env exposing environment variables. /actuator/heapdump serving a full JVM heap dump to anyone who asked for it.

A pure "wait, this is just... open?" moment.

My conclusion, after researching and locking all of this down, is blunt: Spring Boot Actuator's defaults are reasonable for local development, but they're a trap in production, and the official documentation presents them with a tone that softens the real risk. If you don't configure Actuator with intention, you're betting that nobody finds it.

What Gets Exposed by Default

Spring Boot 3.x only exposes two endpoints via HTTP by default: health and info. But that's only half the story.

The problem is:

1. /actuator (the index) is enabled and public — it enumerates everything that exists.
2. If you add spring-boot-starter-actuator without additional configuration, the index reveals available endpoints even if not all of them are exposed via HTTP.
3. In environments with management.endpoints.web.exposure.include=* — which is exactly what appears in a thousand "how to monitor your Spring Boot app" tutorials — you blow the whole board open in one shot.

I ran a simple enumeration script against the backend on a staging environment configured as a production replica:

#!/bin/bash
# Actuator audit script — reproducible on any Spring Boot 3.x
BASE_URL="http://localhost:8080"

echo "=== Enumerating Actuator endpoints ==="
curl -s "$BASE_URL/actuator" | python3 -m json.tool

echo ""
echo "=== Testing /actuator/env (may expose secrets) ==="
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE_URL/actuator/env")
echo "HTTP Status: $STATUS"

echo ""
echo "=== Testing /actuator/heapdump (full heap dump) ==="
STATUS=$(curl -s -o /dev/null -w "%{http_code}" "$BASE_URL/actuator/heapdump")
echo "HTTP Status: $STATUS — If this is 200, you have a serious problem."

What I found in the environment with sloppy configuration (the infamous exposure.include=* copied from a Prometheus tutorial):

/actuator/env was the one that worried me most. It was returning something like this:

{
  "propertySources": [
    {
      "name": "systemEnvironment",
      "properties": {
        "DATABASE_URL": {
          "value": "jdbc:postgresql://****:5432/mydb",
          "origin": "System Environment Property"
        },
        "JWT_SECRET": {
          "value": "******",
          "origin": "System Environment Property"
        }
      }
    }
  ]
}

Spring masks values with ****** for properties it detects as sensitive — but the detection is name-based. If the variable is called MY_SIGNING_KEY instead of JWT_SECRET, the value shows up in plain text. It's not a guarantee, it's a heuristic.

The Lockdown Process: application.properties + Spring Security

After mapping the attack surface, I built the hardening in two layers. The first layer is pure configuration; the second is Spring Security.

Layer 1 — application.properties

# ============================================================
# Actuator — Production hardening
# ============================================================

# Only expose the endpoints we actually need operationally
management.endpoints.web.exposure.include=health,info,metrics

# The /actuator index enumerates available endpoints — close it
management.endpoints.web.exposure.exclude=beans,env,heapdump,threaddump,loggers,mappings,sessions

# Health: details only for authenticated requests
management.endpoint.health.show-details=when-authorized
management.endpoint.health.show-components=when-authorized

# Info: only expose what we explicitly configure
management.info.env.enabled=false
management.info.java.enabled=false
management.info.os.enabled=false

# Move Actuator to an internal port (not exposed on the load balancer)
# Optional but recommended if your infrastructure allows it
management.server.port=8081

# Disable endpoints we don't use even if they're not exposed via HTTP
management.endpoint.heapdump.enabled=false
management.endpoint.threaddump.enabled=false
management.endpoint.env.enabled=false
management.endpoint.beans.enabled=false

The separate port option (management.server.port=8081) is the cleanest approach if your infrastructure allows it. On Railway, for example, the publicly exposed port is the PORT env var — if Actuator runs on 8081 and you only expose PORT externally, the management endpoints are unreachable from the internet directly.

I covered more about JVM configuration and Railway in Spring Boot in production: what the documentation omits.

Layer 2 — Spring Security

The properties configuration is necessary but not sufficient. If Security is misconfigured, or if someone touches that config in the future without context, everything can reopen. The second layer is the seatbelt:

@Configuration
@EnableWebSecurity
public class ActuatorSecurityConfig {

    @Bean
    public SecurityFilterChain actuatorFilterChain(HttpSecurity http) throws Exception {
        http
            // Apply this config only to Actuator paths
            .securityMatcher("/actuator/**")
            .authorizeHttpRequests(auth -> auth
                // Health and info are public — for load balancer health checks
                .requestMatchers("/actuator/health/**").permitAll()
                .requestMatchers("/actuator/info").permitAll()
                // Metrics only for users with MONITORING role
                .requestMatchers("/actuator/metrics/**").hasRole("MONITORING")
                // Any other Actuator endpoint requires ADMIN
                .anyRequest().hasRole("ADMIN")
            )
            // Actuator doesn't need CSRF — it's an internal API
            .csrf(csrf -> csrf
                .ignoringRequestMatchers("/actuator/**")
            )
            // No sessions for Actuator — stateless
            .sessionManagement(session -> session
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS)
            )
            .httpBasic(Customizer.withDefaults());

        return http.build();
    }
}

This approach uses the multiple SecurityFilterChain pattern that Spring Boot 3.x recommends. The Actuator chain has its own logic and doesn't interfere with the rest of the app's security.

The Gotchas Nobody Mentions in Tutorials

After locking everything down and running the audit again, I hit three situations that caught me off guard and are worth documenting.

1. Detailed /actuator/health breaks load balancer health checks

When you configure show-details=when-authorized, the /actuator/health endpoint returns 200 OK with a minimal body for unauthenticated requests — which is correct. But some corporate health checkers expect to see "status": "UP" in the body and parse the JSON. Verify that whatever health checker you're using works with the reduced body:

{ "status": "UP" }

Railway uses the HTTP status code (200 = healthy), not the body — so there's no drama there. But if you're coming from a setup with an AWS ALB or a Kubernetes probe that validates the body, test it before deploying.

2. management.endpoint.X.enabled=false vs exposure.exclude — they're not the same thing

• exposure.exclude removes the endpoint from the HTTP list but leaves it enabled internally (JMX, etc.)
• enabled=false disables it completely across all transports

For endpoints like heapdump and env, use both. The reason: if someone in the future adds a monitoring dependency that enables JMX, an endpoint that's only excluded from HTTP can reappear.

3. The /actuator/loggers POST is a write endpoint

/actuator/loggers/{name} accepts POST to change log levels at runtime. If that endpoint stays open, any attacker can crank logging up to TRACE and potentially generate enormous logs (disk exhaustion), or dial security-relevant levels down to OFF. Closing it isn't optional.

Attack Surface Comparison: Before and After

I ran the same audit script before and after hardening. The result:

# Before hardening (with exposure.include=*)
Endpoints accessible without auth: 10
Endpoints with sensitive information: 3 (env, beans, heapdump)
Endpoints with write capability: 2 (loggers, shutdown*)

# After hardening
Endpoints accessible without auth: 2 (basic health, info)
Endpoints with sensitive information accessible without auth: 0
Endpoints with write capability accessible without auth: 0

The shutdown endpoint deserves a special mention: it's disabled by default in Spring Boot 3.x, but if you ever enabled it for testing and forgot to revert it, it's a POST /actuator/shutdown that kills the JVM. I check for it explicitly in the audit script.

This kind of attack surface is relevant if you're thinking about end-to-end security, including encryption of data in transit — something I explored in more depth in the Themis vs Web Crypto API post.

FAQ — Spring Boot Actuator Security in Production

Which Actuator endpoints does Spring Boot expose via HTTP by default?

In Spring Boot 3.x, only health and info are exposed via HTTP by default. However, if you use management.endpoints.web.exposure.include=* (common in Prometheus or Grafana setups copied from tutorials), all available endpoints get exposed at once. The /actuator index is always visible and enumerates what's there.

What sensitive information can /actuator/env expose?

/actuator/env exposes all of Spring's configuration sources: system environment variables, application.properties properties, JVM system properties, and more. Spring masks values whose names contain words like password, secret, or key, but the detection is name-convention-based — it's not foolproof. Variables with non-standard names can show up in plain text.

Is management.endpoints.web.exposure.exclude enough to protect endpoints?

No. exclude only controls HTTP exposure. The endpoints remain enabled for other transports (JMX) and remain discoverable if you know the direct path. Complete protection requires combining exclude, enabled=false for the most critical endpoints, and Spring Security for the ones you leave open.

How do I protect /actuator/health without breaking load balancer health checks?

Configure management.endpoint.health.show-details=when-authorized. Unauthenticated requests get {"status":"UP"} or {"status":"DOWN"} with HTTP 200/503 — enough for most HTTP-status-based health checkers. Verify that yours doesn't parse the body before deploying.

What's the best practice for Actuator in a microservices architecture?

Move Actuator to an internal port (management.server.port=8081) and don't expose that port on the load balancer or public ingress. Monitoring tools (Prometheus, Grafana) access it from the internal network; external users never have direct access. Combined with Spring Security on that port, the attack surface gets very small.

Is /actuator/heapdump as dangerous as it sounds?

Yes. A heap dump contains the complete state of JVM memory at the moment of capture: objects in memory, strings, internal data structures. In an app that handles JWT tokens, database connections, or any user session data, a heap dump captured by an attacker is essentially a data breach. Disable it in production unless you need it for active debugging under controlled access.

The Official Docs Soften the Real Risk

The official Spring Boot Actuator documentation does say clearly that "for production, we recommend ensuring that only the health and info endpoints are exposed." But the tone is a recommendation, not a strong warning. And the viral "integrate Prometheus with Spring Boot" tutorials jump straight to exposure.include=* without mentioning that it opens the heapdump to the world.

My point after building this checklist: Actuator is a powerful observability tool, but it ships configured for development convenience, not production resilience. The cost of not auditing it is high; the cost of locking it down properly is low — an afternoon of work, two configuration files.

If you've been reading my posts on pnpm vs npm in my monorepo or functional programming in TypeScript, you already know my approach is to validate in concrete scenarios before making recommendations. Same thing applies here: don't trust the default. Run the audit script, see what it returns, then decide what to close.

The final checklist I use now for any Spring Boot backend before going to production:

# Actuator pre-production checklist — Spring Boot 3.x
# 1. Check which endpoints are exposed
curl -s http://localhost:8080/actuator | python3 -m json.tool

# 2. Confirm /actuator/env returns 401 or 404
curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/actuator/env

# 3. Confirm /actuator/heapdump returns 401 or 404
curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/actuator/heapdump

# 4. Confirm /actuator/beans returns 401 or 404
curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/actuator/beans

# 5. Verify basic health still responds for the load balancer
curl -s http://localhost:8080/actuator/health

# Expected result in production:
# env → 401 or 404 ✓
# heapdump → 401 or 404 ✓
# beans → 401 or 404 ✓
# health → 200 with {"status":"UP"} ✓

If any of the first three returns 200 without authentication, you stop the deploy and fix it. No excuses.

Sources:

• Spring Boot Actuator documentation: https://docs.spring.io/spring-boot/docs/current/reference/html/actuator.html

This article was originally published on juanchi.dev