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
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
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
management.endpoints.web.exposure.include=* exposes every registered endpoint, including env, beans, configprops, heapdump and threaddump.
- [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]
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.
- [4]
The common recipe the author sees sets management.endpoint.env.enabled=false, management.endpoint.shutdown.enabled=false and management.endpoint.heapdump.enabled=false while leaving management.endpoints.web.exposure.include=*.
- [5]
The hidden cost of that recipe is that it starts from total exposure and subtracts: every new endpoint Spring Boot adds in a future version, and every dependency that registers its own Actuator endpoint, stays exposed by default until someone finds out and adds it to the blacklist.
- [6]
/env returns the full PropertySource tree, which in real configurations includes database credentials, tokens for external services and application secrets if management.endpoint.env.keys-to-sanitize was not set or the version's equivalent sanitization mechanism was not used.
- [7]
The author argues /heapdump is arguably worse than /env: a full memory dump can contain strings with active session tokens, and if sessions live in process memory a leaked heapdump exposes them as much as a token stolen through XSS.
ReportedSupportedSource: dev.to post by jtorchia2 sources— create a free account to open themView cited source - [8]
The author's comparison: a blocklist is like a firewall that blocks known ports and protects against threats you already know about, while an allowlist only permits the ports you need and also covers threats that do not exist yet.
- [9]
The author's thesis is that Actuator with default configuration is overlooked attack surface, that turning off endpoints that sound dangerous by gut feeling is worse than having no strategy at all, and that the fix is an explicit allowlist with everything else closed by default.
ReportedSupportedSource: dev.to post by jtorchia2 sources— create a free account to open themView cited source - [10]
Actuator was built for operational visibility such as health checks, metrics and build info, but several endpoints return information that should never leave the internal network; the default configuration only distinguishes web-exposed from not, with criteria designed for development rather than production.
- [11]
The author says readers arrive in one of two situations: adding the starter for the first time and wanting to know what turns on, or looking at a pentest or audit report that flagged an endpoint as exposed.
- [12]
The same argument was published in Spanish on dev.to under the headline "Actuator endpoints en Spring Boot: allowlist, no deshabilitar lo obvio", with the same examples and the same code snippets.
- [13]
Adding the wildcard exposure line takes an application from one HTTP-exposed endpoint (/health) to every endpoint in the registry.
- [14]
In the English-language version, the code block comments are still in Spanish, including "# Lo que copian de un tutorial sin pensarlo dos veces" and "# Receta comun: deshabilitar lo que 'suena' peligroso".
- [15]
Of the five endpoints named as swept in by the wildcard, the common blocklist recipe disables two (env, heapdump) and leaves beans, configprops and threaddump reachable; its third entry, shutdown, is not among those five.
- [16]
A curl to /actuator/env on a Spring Boot backend with default configuration can return environment variables, system properties and, in some versions and setups, datasource values; no credentials and no exploit are needed, only that nobody touched Actuator's security config after adding it to the pom.xml.
ReportedContestedSource: dev.to post by jtorchia3 sources— create a free account to open themView cited source - [17]
Both supplied versions of the post are cut off before the allowlist configuration snippet: the Spanish text ends mid-sentence at "En vez de partir de" and the English text ends at "add what I can justify" followed by a truncated comment line.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toActuator endpoints en Spring Boot: allowlist, no deshabilitar lo obvio
2 articles · August 23, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
Entities
- Spring Boot ActuatorFollow
- Spring BootFollow
- Spring SecurityFollow
- dev.toFollow
- jtorchiaFollow