skip to content

Securing Actuator Endpoints

4 roadmaps5 questions

Securing Actuator means matching endpoint requests in the filter chain, restricting by role, sanitizing secrets in env and configprops, and often moving it to another port. Interviewers ask this because unsecured actuators are a recurring real-world breach.

part ofSpring Frameworkoverview, primer and where to startread it →
on this pageshow

explore

questions

5

Why do Spring Boot Actuator endpoints need to be secured, and what is exposed by default?

level: juniorimportance: must knowfreq 70%

answer

  1. only /health exposed by default over HTTP
  2. exposure != authentication
  3. /env, /configprops, /heapdump leak secrets
  4. /loggers, /shutdown are write actions
  5. avoid exposure.include=*

basics

~20 s

Actuator endpoints like /env, /configprops, /heapdump, /threaddump and /loggers reveal internal state, config values and secrets, and some let you change runtime settings. Leaving them open lets attackers read secrets or tamper. Restrict them to admins.

solid answer

~30 s

Actuator exposes operational endpoints under /actuator. Some are read-only but sensitive: /env and /configprops show configuration (potentially DB passwords, API keys), /heapdump and /threaddump can leak in-memory data, /mappings and /beans reveal internals. Others are write/action endpoints: /loggers changes log levels, /shutdown stops the app. By default only /health is exposed over HTTP; you opt others in via management.endpoints.web.exposure.include. But once exposed they're unauthenticated unless you add Spring Security. The standard fix is a SecurityFilterChain that requires an admin role for EndpointRequest.toAnyEndpoint(), plus value sanitization on /env and /configprops. Never expose the full set publicly.

code

yaml · 10 lines
yaml
management:
  endpoints:
    web:
      exposure:
        include: health,info,metrics   # opt-in explicitly; never '*' in prod
  endpoint:
    health:
      show-details: when-authorized    # hide details from anonymous callers
    shutdown:
      enabled: false                   # keep the kill switch off

go deeper

for a junior

Should know actuator endpoints can leak secrets and that only /health is exposed by default.

for a middle

Should distinguish exposure from authorization and name the dangerous endpoints.

for a senior

Should describe the layered fix: minimal exposure + security filter chain + value sanitization.

for a principal

Should frame default-deny posture and treat exposure/security/network as independent controls.

**What Actuator is.** Spring Boot Actuator (`spring-boot-starter-actuator`) adds production-ready HTTP endpoints under a base path (default `/actuator`) for monitoring and management: `health`, `info`, `metrics`, `env`, `configprops`, `beans`, `mappings`, `loggers`, `threaddump`, `heapdump`, `shutdown`, and more. **Why they are dangerous.** - **Data-leak endpoints (read):** `/actuator/env` dumps the entire Spring `Environment` — every property source including system env vars and application config, which often contains `spring.datasource.password`, cloud credentials, JWT secrets. `/actuator/configprops` dumps all `@ConfigurationProperties` beans with their bound values. `/actuator/heapdump` downloads a full JVM heap dump (every object in memory — tokens, PII). `/actuator/threaddump`, `/actuator/beans`, `/actuator/mappings` reveal code structure useful for further attacks. - **Action endpoints (write):** `/actuator/loggers/{name}` (POST) changes log levels at runtime; `/actuator/shutdown` (POST, disabled by default) stops the application — a trivial DoS if enabled and open. **Default posture.** Since Spring Boot 2.x, over **HTTP** only `health` is exposed by default (`info` too in some setups). Over JMX defaults differ. You explicitly opt endpoints in with `management.endpoints.web.exposure.include=health,info,metrics` (or `*` for all — dangerous). **Exposure is not authentication:** an exposed endpoint is reachable by anyone unless Spring Security guards it. **The fix, in layers:** 1. **Expose only what you need.** Keep `exposure.include` minimal; avoid `*` in production. 2. **Authenticate + authorize.** Add `spring-boot-starter-security` and a `SecurityFilterChain` requiring a role (e.g. `ROLE_ACTUATOR_ADMIN`) for `EndpointRequest.toAnyEndpoint()`. 3. **Sanitize values.** `/env` and `/configprops` mask secret-looking keys by default and, since Boot 3, hide **all** values unless `management.endpoint.env.show-values` / `configprops.show-values` is set to `ALWAYS` or `WHEN_AUTHORIZED`. 4. **Network isolation.** Optionally run management on a separate port (`management.server.port`) bound to an internal interface. **Gotcha:** Real breaches have happened where teams set `exposure.include=*` for convenience and shipped it, leaving `/env` and `/heapdump` world-readable. Exposure config and security config are independent — you need both correct.

  • Does adding an endpoint to exposure.include make it secure?
    No. Exposure only controls whether an endpoint is reachable over the web transport. Access control is a separate concern handled by Spring Security; without a filter chain, an exposed endpoint is open to anyone.
  • Which two endpoints are the most notorious for leaking secrets?
    /actuator/env and /actuator/configprops, because they render bound configuration values (DB passwords, API keys). /heapdump is also severe since it dumps all in-memory objects.

saying these in an interview costs you the question

  • Thinking all endpoints are exposed by default (only health is over HTTP)
  • Believing exposure.include also enforces authentication
  • Assuming actuator is safe because it's 'just monitoring'
  • Enabling exposure.include=* in production

context

resolving links…

open as a page

How do you configure Spring Security to restrict Actuator endpoints, and what does EndpointRequest.toAnyEndpoint() do?

level: middleimportance: must knowfreq 68%

basics

~10 s

Define a SecurityFilterChain bean and use the EndpointRequest matcher instead of hardcoding /actuator paths. EndpointRequest.toAnyEndpoint() matches every actuator endpoint; require a role like hasRole('ACTUATOR_ADMIN'). You can exclude health/info so they stay public.

open as a page

How does Spring Boot prevent /env and /configprops from leaking secrets, and how do you control value masking?

level: seniorimportance: should knowfreq 55%

basics

~20 s

Even for authorized users, /env and /configprops mask sensitive values. By default keys like password, secret, key, token and credentials are shown as '******', and since Boot 3 all values are hidden unless you set show-values to ALWAYS or WHEN_AUTHORIZED. You can add custom SanitizingFunction beans.

open as a page

What are the security benefits and pitfalls of running Actuator on a separate management port?

level: seniorimportance: should knowfreq 42%

basics

~20 s

Setting management.server.port to a different port than the app moves /actuator off the public port. Bind it to an internal address (management.server.address=127.0.0.1 or a private interface) so only ops/monitoring on the internal network can reach it, adding network-level isolation on top of Spring Security.

open as a page

Design a production-grade defense-in-depth strategy for locking down Actuator across exposure, authorization, data masking, and network.

level: principalimportance: should knowfreq 30%

basics

~20 s

Combine independent layers: expose only needed endpoints, guard them with a SecurityFilterChain requiring an admin role via EndpointRequest.toAnyEndpoint(), keep /env and /configprops values masked (show-values NEVER or WHEN_AUTHORIZED), disable dangerous ones like /shutdown, and isolate the management port to an internal network.

open as a page