Skip to content

Build1 publisherNot yet confirmed elsewhere3 min readPublished

Spring Boot Actuator: the wildcard is the bug, not the endpoint that sounds scary

A dev.to post, published twice by the same author, argues that switching off env and heapdump while leaving exposure.include set to the wildcard is worse than no policy. The subtraction backs it up.

The Engineer · Build desk

How we use AISend a correction

What happened

  • A curl to /actuator/env on a Spring Boot app with default config can return environment variables, system properties and, in some versions and setups, datasource values.
  • Setting that property to the wildcard publishes every registered endpoint, with env, beans, configprops, heapdump and threaddump among them.
  • The widely copied fix keeps the wildcard and switches off env, shutdown and heapdump one at a time.
  • Spring's warning about the wildcard sits in a different documentation section from the instructions that introduce the property.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • contradiction The opening leak and the post's own reading of the docs cannot both describe a fresh install: the env dump needs someone to have widened exposure first, which makes this a copy-paste failure...
  • constraint A blocklist ties exposed surface to the dependency graph and the upgrade cadence, so anything a library or a new release registers is reachable until a human notices and writes another line.
  • exposure Whoever can fetch a heapdump holds whatever the process was holding, so the remediation is session invalidation across users rather than rotating one credential.
  • decision Teams already running the wildcard now pick between enumerating what they can justify exposing and keeping a blacklist that is only ever as current as the last person who read the release notes.

Actuator has two knobs and they do not do the same job. Whether an endpoint is registered is set per endpoint; whether HTTP can reach it is set by `management.endpoints.web.exposure.include`, which since Spring Boot 2 resolves to `/health` and nothing else until someone changes it [2]. The criteria behind that default were drawn for development rather than production, which is the author's starting complaint [10]. The recipe under attack sets the exposure knob to the wildcard and then spends three lines arguing with the other one [4]. The ordering is what makes it fragile: the wildcard is evaluated against whatever is in the registry, so it stands as an instruction to publish endpoints nobody has read about yet [1][5]. The author's own comparison is the accurate one, a firewall that permits the ports you need rather than blocking the ones you have heard of [8].

Then do the subtraction. The post names five endpoints the asterisk sweeps in: `env`, `beans`, `configprops`, `heapdump`, `threaddump` [1]. The blocklist closes two of them, `env` and `heapdump`, and spends its third line on `shutdown`, which was not in that list at all [4]. That leaves `beans`, `configprops` and `threaddump` reachable [15]. A file that reads as hardening still serves three of the five endpoints its own author flagged, and one property line is what moved the app from a single exposed endpoint to the whole registry [13].

The two headline endpoints also fail differently. `/env` returns the PropertySource tree, and there is a filter made for it: `keys-to-sanitize` redacts by key name, so in the best case a leak degrades into a leak of names [6]. `/heapdump` has no key names to filter, because it is process memory serialised, and the post's argument is that live session tokens come out with it, putting a fetched dump in the same bracket as a token stolen through XSS [7].

On sourcing: this is one post by one author, published twice on dev.to, once in Spanish and once in English [12][16]. The English edition still carries the Spanish comments inside its code blocks [14], which is a fair sign the two are one text rather than two reports, so read it as an opinion with worked examples and not as corroboration. Both copies also stop before the allowlist snippet arrives [17]. The prescriptive half, meaning the endpoints this author would actually justify exposing, is not on the page. The direction of the default is, and that part survives without the snippet [9]. The reader likeliest to need it is the one holding an audit finding that named an endpoint [11], and that reader already has the properties file the subtraction applies to.

What to watch

  • Whether Spring's documentation moves the wildcard warning next to the exposure.include example, which would remove the copy-paste trap the post blames.
  • A published incident or CVE traced to an Actuator endpoint registered by a third-party dependency rather than by application configuration.
  • The allowlist snippet itself: both copies of the post cut off before it, so the endpoints the author would permit remain unstated.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence40
Adoption
Insufficient
Hype gap+28
Incentives35
Confidence42
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    management.endpoints.web.exposure.include=* exposes every registered endpoint, including env, beans, configprops, heapdump and threaddump.

  2. [2]

    The official Spring Boot Actuator documentation states that since Spring Boot 2, only /health is exposed over HTTP by default; the other endpoints exist but are not web-exposed until enabled with management.endpoints.web.exposure.include.

    ReportedSupportedSource: Spring Boot Actuator documentation, as cited by the post2 sources— create a free account to open themView cited source
  3. [3]

    The documentation does warn about the asterisk, but in a section separate from the one showing how to enable endpoints, and copy-paste habits do not respect section boundaries.

Sources

1 independent publisher whose own reporting we read for this story.

  1. dev.to

    2 articles · August 23, 2026

    Actuator endpoints en Spring Boot: allowlist, no deshabilitar lo obvio

Share your take

Let Clarity write the post for you.

Signed-in readers get a short post drafted on this story in the register they choose — narrative, analytical, or a direct position — editable to the last word before it goes anywhere. The share buttons at the top of this story work without an account.

Topics and entities

Follow any of these and your For You feed starts watching them — no settings page required.

Topics

  • Secure defaults and allowlistingFollow
  • Secrets and credential leakageFollow
  • Spring Boot Actuator endpoint exposureFollow
  • Java backend hardeningFollow
Loading related stories