whiteweb.security / guides / Spring Boot Actuator exposed
/actuator Critical — secrets leak ~6 min read

My Spring Boot Actuator endpoints are publicly exposed. What should I do?

Spring Boot Actuator endpoints are brilliant for ops and dangerous in the open. Exposed publicly, /actuator/env reveals your configuration and secrets, and /actuator/heapdump hands over a full memory snapshot of your running app — passwords, tokens and session data included. Here’s how to close them and rotate.

First: don’t panic — restrict the endpoints, then rotate what they revealed.

A heapdump or env dump is a one-request secret leak; assume anything reachable was read. Lock the actuator endpoints down now, then rotate every credential they could have exposed.

// the 60-second version

  • Restrict /actuator to internal access (or disable the risky endpoints) now.
  • Treat env, configprops and especially heapdump data as leaked.
  • Rotate every secret in your configuration and memory.
  • Review access logs for who hit the endpoints.

01Understand what’s at risk

Actuator exposes operational endpoints; a few are gold for an attacker if reachable:

  • /actuator/env & /configprops — your configuration, often including DB URLs, credentials and API keys (masking is imperfect and easily misconfigured).
  • /actuator/heapdump — a complete dump of JVM memory. Anything your app held — passwords, tokens, session contents, decrypted secrets — can be extracted from it.
  • /actuator/mappings, /beans, /threaddump — a detailed map of your app’s internals to plan further attacks.
  • Write-enabled endpoints — in some setups, runtime config changes (/loggers, /env POST) or worse.

heapdump is the headline risk: it’s a binary download an attacker analyses offline to pull out live secrets that aren’t even printed in env. If it was reachable, assume every secret the app used is compromised.

02Stop the bleeding — restrict the endpoints

Limit Actuator to a minimal, safe set and keep it off the public path. In application.properties:

expose only health, on an internal portapplication.properties
management.endpoints.web.exposure.include=health
management.server.port=8081
management.server.address=127.0.0.1

At minimum, never expose env, heapdump, configprops or threaddump publicly — and block /actuator at your reverse proxy / gateway.

03Rotate everything that was reachable

Because env and heapdump expose live secrets, rotate broadly:

  • Database passwords, API keys, cloud tokens and any credential present in your configuration.
  • Signing/JWT secrets and encryption keys — a heapdump can reveal these even when env masks them.
  • Session secrets — and consider invalidating active sessions.

Rotate at the source and redeploy with the new values pulled from a secrets manager, not plaintext properties.

04Secure Actuator properly

  • Put Actuator behind authentication (Spring Security) and authorization, even internally.
  • Bind it to a separate management port reachable only from your internal network.
  • Disable heapdump unless you specifically need it, and never expose it.

05Read the logs — who hit /actuator?

Check your access logs (app or reverse proxy) for requests to actuator paths, especially the sensitive ones:

find actuator probesbash
grep -E "/actuator/(env|heapdump|configprops|beans)" /var/log/nginx/access.log
  • A 200 on /actuator/heapdump from an unknown IP means a memory dump was downloaded — rotate everything and treat it as a breach.
  • Enumeration of /actuator is a common automated probe; note the IPs and exposure window.

06Make sure it can’t happen again

  • Expose only health/info publicly; everything else behind auth on an internal port.
  • Keep secrets in a manager, not in plaintext properties.
  • Block /actuator at the gateway by default.
  • Upgrade Spring Boot and review the exposure config on every deploy; monitor for actuator probes.

Was this guide useful?

These playbooks are free to read and share. If a heads-up ever saved you a bad week, you can say thanks — or jump into the other guides.