Skip to content
← Back to blog

Actuator /env: what changes when show-values is enabled

Correction: Spring Boot 3+ hides values by default. Start with the exact version and effective show-values configuration.

September 11, 2026 · 2 min read · 13 reads

  • #spring-boot
  • #java
  • #actuator
  • #spring-security

Correction, September 16, 2026. The previous version claimed that names such as DB_PASS exposed values by default. That was incorrect for Spring Boot 3+. The Java example has also been removed because its compilation had not been validated.

The correct starting point

Spring Boot 3.2.6 sanitizes values from /env and /configprops by default. A variable name alone does not establish a leak. See the versioned Actuator reference.

The current reference distinguishes three show-values settings: never hides values; always permits showing them; when-authorized shows them to authorized users. Custom sanitizing functions may still hide values. HTTP role configuration also matters.

What I would check before changing it

My starting point is the diagnostic need, not a new regex. If I only need to establish whether a property exists or where it comes from, access to all its values may be unnecessary.

  1. Record the exact Spring Boot version and consult its reference.
  2. Inspect effective configuration for each environment, including overrides.
  3. Separate endpoint exposure, access authorization and value visibility.
  4. Test with fictitious values, without real credentials, using different permission levels.
  5. Record expected and observed results before expanding access.

This is a proposed procedure, not an experiment performed for this article. It does not establish how your application is configured.

The limit of this recommendation

Hidden values do not make every Actuator exposure a good decision. First I would establish who needs the endpoint, from where, and for which diagnostic task. Then I would test that specific case.

The original mistake was describing behavior without fixing a version and citing documentation that did not support the claim. The useful correction is to verify the framework contract before proposing an additional defense.

Looking for this approach on your team?

Explore my technical case studies or discuss a senior role, architecture and technical leadership.

Comments (0)

What do you think of this?

Drop your comment in 10 seconds.

We only use your login to show your name and avatar. No spam.

No comments yet. Be the first — your take matters most when we're few.

Related Articles