Spring Boot Actuator and Management Endpoint Security Guide: Locking Down heapdump, env and Management Ports

An exposed Spring Boot Actuator endpoint can hand an attacker a heap dump full of live secrets, the application's whole configuration, or a way to change its behaviour at runtime, all without exploiting a single bug. Actuator is the production-readiness module that gives Spring Boot applications health checks, metrics and diagnostics, and most of what it offers is an administrative API by another name. This guide goes deeper than the Actuator section of our Java and Spring guide: it explains how endpoint access, exposure and security interact in current Spring Boot, who should be allowed to call which endpoint, how monitoring tools and Kubernetes probes should authenticate, what to log, and a hardening baseline with rollout steps. It is written for application security engineers, platform teams and Spring developers.

Key takeaways

• Three settings decide exposure, not one. An endpoint is reachable only when access permits it, it is exposed over HTTP or JMX, and the security chain lets the caller through. Teams usually change one and forget the other two.
• heapdump, env and configprops are credential stores. A heap dump contains whatever is in memory, including decrypted secrets and tokens, so treat it like a vault export and keep it off any reachable port.
• A custom SecurityFilterChain switches off Boot's protection. Once you define your own chain, Spring Boot backs off entirely, so you must add an explicit chain for EndpointRequest.toAnyEndpoint() or Actuator becomes as open as your rules allow.
• Write operations are the real admin rights. loggers, sessions, shutdown and Spring Cloud's POST /actuator/env and refresh change a running application. Cap everything at read-only unless a named operator needs more.
• Monitoring callers are non-human identities. Prometheus scrapers, Spring Boot Admin and probe agents need their own scoped credentials or network path, not a shared admin password baked into every service.

How identity and access work in Spring Boot Actuator

Actuator does not have its own user store. It relies on three independent layers, and the current Spring Boot reference documentation describes each one separately. An endpoint is "available" only when access is permitted and it is exposed; Spring Security then decides who may call it.

Two details catch experienced teams. First, read access is defined per endpoint type: for @Endpoint and @WebEndpoint it means read operations, and for servlet endpoints it means GET and HEAD, so a cap of read-only still allows a GET /actuator/heapdump if heapdump has been made accessible. Second, for JMX the documentation states that all users are always treated as authorised for sanitised values, so show-values: when-authorized gives no protection over JMX. Any remote JMX port or JMX-over-HTTP bridge must be secured at the network and JVM level.

Admin roles and privileged access

Classify endpoints by what they reveal and what they can change, then map each class to a role. The table reflects the endpoint descriptions in the Spring Boot reference; the risk column is our assessment.

• Use a dedicated role: the Spring Boot sample secures EndpointRequest.toAnyEndpoint() with hasRole("ENDPOINT_ADMIN"). Keep that role separate from application administrators so a compromised business admin account does not inherit heap dumps.
• Split read and write: combine max-permitted: read-only in production with per-endpoint grants, and only lift the cap in a change window for a named operator.
• Restrict unsanitised values by role: if operators genuinely need values, set show-values: when-authorized with roles set. Without roles, the documentation says any authenticated user is authorised, which on a single sign-on application means every employee.
• Keep CSRF on: Spring Security's CSRF protection is on by default and blocks POST, PUT and DELETE Actuator calls from browsers. Disable it only on a management chain used solely by non-browser clients.

Our Spring Security Configuration Guide covers filter chain ordering and matcher pitfalls in depth. See the Java and Spring Security Guide for the wider Spring attack surface.

Integrations, API tokens and service accounts

Most Actuator traffic in production comes from machines: metrics scrapers, Kubernetes kubelets, Spring Boot Admin servers, APM agents and deployment tooling. Each is a non-human identity that needs a credential or a network path, and each is a way in if that credential is shared or over-scoped.

• Store the credentials properly: the management user's password or client certificate key belongs in a secrets manager or the platform's secret store, not in source control. See the Secrets Management Guide.
• Prefer network identity where it is strong: binding the management server to an internal address with management.server.address and a separate management.server.port, plus a network policy that admits only the monitoring namespace, avoids distributing passwords at all. Inside a mesh, mTLS between scraper and service is stronger still. See the mTLS Guide.
• Remember what Actuator reveals about other identities: env and configprops list every datasource user, cloud SDK setting and API client configured in the application. Even sanitised, that is an inventory of the service's non-human identities. See the Service Account Security Guide.

Logging and detection

Spring Boot's audit framework publishes authentication success, authentication failure and access denied events once Spring Security is present, but only if you supply an AuditEventRepository bean. The in-memory implementation is intended for development, so production services should forward events to their log pipeline. Combine those application events with edge and network logs.

In ATT&CK terms, scanning and abuse of exposed Actuator endpoints sits under T1190 Exploit Public-Facing Application for the gateway code injection class, and under T1552.001 Credentials In Files and T1005 Data from Local System when the goal is harvesting configuration and memory. Treat a confirmed heap dump or unsanitised env download as a credential compromise: rotate every secret the process held, not just the obvious one. Our Cloud Credential Compromise Playbook covers the rotation sequence.

Metrics that show the controls hold

• Externally reachable Actuator endpoints: count from attack surface scans of every public hostname, target zero beyond health.
• Services with exposure set to *: found by configuration scanning across repositories and running pods, target zero in production.
• Services with a management-specific security chain: percentage of Spring Boot services where a test proves /actuator/env returns 401 or 403 without the management role.
• Write-capable endpoints in production: number of services where max-permitted is not read-only, each with a recorded owner and reason.
• Shared management credentials: number of services using the same management secret, target one per environment or none where network identity is used.

Hardening baseline

A production baseline that matches the documented properties. Adjust endpoint lists to what your operators actually use.

Changing management.endpoints.web.base-path to an unusual value reduces scanner noise but is not a control. OWASP ASVS 5.0 requirement V13.4.5 asks that monitoring endpoints are not exposed unless explicitly intended, and V13.4.6 that backend version details are not exposed, which is a useful pass or fail test for this baseline.

Rolling out the baseline

1. Inventory first: scan repositories for spring-boot-starter-actuator and management. properties, and scan public hostnames for /actuator and common alternate base paths. Record which services have a custom SecurityFilterChain, because those no longer get Boot's default protection.
2. Close the network path: move management to a separate port bound to an internal address, update Kubernetes probes and scrape configs, and block /actuator/** at the public ingress as a second layer.
3. Apply access settings in staging: set access.default=none and max-permitted=read-only, enable only the endpoints your monitoring uses, and run the probe and scrape checks. Inaccessible endpoints are removed from the context, so failures show up immediately as 404s.
4. Add the management security chain: a dedicated SecurityFilterChain with securityMatcher(EndpointRequest.toAnyEndpoint()) and a dedicated role, ordered before the application chain. Add an integration test that asserts env and heapdump return 401, 403 or 404 for an anonymous and an ordinary user.
5. Pilot and promote: roll to one service per team, watch probe failures and dashboards for a week, then make the baseline a shared starter or platform default so new services inherit it.
6. Rollback: keep the previous property set in the deployment manifest history; reverting the management properties restores behaviour without code changes. Never roll back by setting exposure to "*".

Decision guidance

• Separate port versus same port with security: a separate internal port is the stronger default for data centres and Kubernetes. The documentation notes that some platforms, such as Cloud Foundry, route only one port by default, where a same-port design with a strict management chain and edge blocking is the practical choice.
• Small teams: expose only health and prometheus, keep everything else inaccessible, and diagnose through logs and APM.
• Large estates: publish a company starter that sets the baseline, provide a break-glass diagnostic path through privileged access tooling, and enforce the baseline with policy as code in the build.

Common misconfigurations

• Exposure set to "*" to fix a monitoring integration: one line in a shared profile exposes every endpoint on every service that loads it. Exposure lists should be explicit and reviewed.
• A custom security chain that forgets Actuator: the moment a team adds its own SecurityFilterChain for the API, Boot's default protection backs off. A permitAll() on /** for a public API then also opens /actuator/**.
• Trusting "internal" without checking the route: ingress rules, API gateways and service meshes often forward every path. Mass scanning finds these leaks quickly: the 230 Million AWS Cloud Environments Campaign harvested keys from exposed .env files across more than 110,000 domains, and an unprotected env or heapdump endpoint is the same class of exposure.
• Turning on show-values: always during debugging: it shows unsanitised values to everyone who can reach the endpoint, and it tends to survive into production config.
• Leaving development profiles active: profiles that widen exposure, enable H2 consoles or debug logging are a frequent source of production exposure. Fail start-up if a development profile is active in production (ASVS V13.4.2).
• Unpatched Spring Cloud components behind Actuator: CVE-2022-22947 in Spring Cloud Gateway, listed in the CISA Known Exploited Vulnerabilities catalogue since May 2022, allowed code injection through the Gateway Actuator endpoint when it was enabled, exposed and unsecured. Exposure turned a management feature into remote code execution.

Framework mapping

See the OWASP API Top 10 API8 Security Misconfiguration Guide for the wider misconfiguration class.

Practitioner checklist

• Inventory every service that depends on spring-boot-starter-actuator and scan all public hostnames for management paths.
• Set management.endpoints.access.default=none and max-permitted=read-only in production, then opt in endpoints by name.
• Replace any exposure.include="*" with an explicit list and exclude heapdump, env, configprops, threaddump and logfile.
• Move management to a separate internal port and address, and block /actuator/** at the public edge.
• Add a dedicated SecurityFilterChain for EndpointRequest.toAnyEndpoint() with its own role, plus an automated test proving anonymous access is refused.
• Keep show-values at never and health.show-details at never or when-authorized with roles.
• Give scrapers, probes and admin consoles their own scoped identities, stored in a secrets manager, or rely on network identity and mTLS.
• Disable or secure Spring Cloud Gateway and Spring Cloud Commons write endpoints and keep those components patched against KEV-listed CVEs.
• Forward Actuator audit events to the SIEM and alert on management path hits at the edge and on runtime log level changes.
• Treat any confirmed heap dump or unsanitised env download as a full credential compromise and rotate every secret the process held.

Standards and references

• Spring: Spring Boot Reference, Actuator Endpoints
• Spring: Spring Boot Reference, Monitoring and Management Over HTTP
• Spring: Spring Boot Reference, Auditing
• Spring: Spring Cloud Commons, Spring Cloud Context Application Context Services
• Spring: CVE-2022-22947 Code Injection in Spring Cloud Gateway
• OWASP: Application Security Verification Standard 5.0
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Java and Spring Security Guide · Spring Security Configuration Guide · Secrets Management Guide · Kubernetes Security Guide · Attack Surface Management Guide