skip to content

What are the security and exposure considerations when publishing /actuator/info, and how would you govern them?

level: principalimportance: should knowfreq 30%

answer

  1. git full mode leaks remote URL + committer email + dirty flag
  2. exposure.include (Boot 3: health only default)
  3. Actuator has no built-in auth — use Spring Security / management.server.port
  4. keep git.mode=simple, contributors minimal
  5. no secrets in info.* or custom contributors — no auto-masking

basics

~20 s

The info endpoint can leak build/git details, environment metadata, and (in git full mode) remote URLs and committer emails. Control exposure with management.endpoints.web.exposure.include, protect Actuator with authentication, keep git.mode=simple, and never place secrets in info.* or custom contributors.

solid answer

~40 s

/actuator/info is informational but not harmless: git full mode exposes the remote URL, tags, dirty flag, and committer name/email; build/env blocks reveal version, framework, team, and internal naming that aids reconnaissance. Governance is layered. (1) Exposure: in Boot 3.x only health is web-exposed by default; explicitly manage management.endpoints.web.exposure.include per environment. (2) Access control: put Actuator behind Spring Security — often a dedicated management port (management.server.port) and a filter chain requiring an operator role — so info isn't anonymous in production. (3) Content minimization: keep management.info.git.mode=simple, enable only the contributors you need (env/java/os off unless justified), and forbid secrets in info.* and custom contributors via review. (4) Consistency: standardize these settings in a shared config/base image so every service is uniform, and treat the exposed surface as part of threat modeling.

code

java · 22 lines
java
// Lock down Actuator: separate port + authenticated info, minimal content
// application-prod.yml
// management:
//   server:
//     port: 9090                       # internal-only management port
//   endpoints:
//     web:
//       exposure:
//         include: health,info          # explicit allow-list, never '*'
//   info:
//     git:
//       mode: simple                    # avoid leaking full git.properties

@Bean
SecurityFilterChain actuator(HttpSecurity http) throws Exception {
    http.securityMatcher("/actuator/**")
        .authorizeHttpRequests(a -> a
            .requestMatchers("/actuator/health/**").permitAll()
            .anyRequest().hasRole("ACTUATOR"))   // info requires operator role
        .httpBasic(withDefaults());
    return http.build();
}

go deeper

for a junior

Know info can leak version/commit info and shouldn't contain secrets.

for a middle

Control exposure via exposure.include and keep git.mode=simple.

for a senior

Layer Spring Security, a management port, and content minimization; know secrets aren't auto-masked.

for a principal

Define org-wide governance: standardized config, per-environment profiles, threat-modeling the Actuator surface.

## Why info is a real (if modest) attack surface `/actuator/info` looks benign, but it aggregates deploy metadata that helps an attacker fingerprint the system: - **git full mode** (`management.info.git.mode=full`) dumps the entire `git.properties`: remote repository URL, all tags, the `dirty` flag, build host, and **committer name/email** — real PII and infrastructure hints. - **build block**: exact application version → maps to known CVEs for that release. - **env / custom contributors**: internal team names, region identifiers, feature flags — reconnaissance value, and a risk if a developer carelessly adds a secret. ## Layer 1 — exposure (what's reachable over HTTP) Two independent gates: - **Enabled**: `management.endpoint.info.enabled` (default true). - **Web-exposed**: `management.endpoints.web.exposure.include`. In **Boot 3.x** the default is `health` only. Adding `info` is a deliberate choice. Use `exclude` to override includes; `include=*` (everything) is dangerous in production. ## Layer 2 — authentication & network isolation Actuator has no auth of its own; it relies on Spring Security. Options: - Require authentication/authorization for `/actuator/**` via a `SecurityFilterChain` (e.g. an `ACTUATOR`/operator role). - Use a **separate management port** (`management.server.port`) bound to an internal network, so operational endpoints aren't on the public listener at all. - Front with an ingress/firewall that blocks `/actuator/**` externally. Anonymous `info` may be fine in a locked-down internal cluster but is risky on a public endpoint. ## Layer 3 — content minimization - Keep `management.info.git.mode=simple` (branch, short commit, time) — avoid `full` unless you fully control who can read it. - Enable only necessary contributors: `env`, `java`, `os`, `process` are off by default — leave them off in production unless there's a reason. - **Never** put credentials, tokens, connection strings, or PII into `info.*` properties or a custom `InfoContributor`. Enforce via code review and, ideally, a lint/policy check. ## Layer 4 — consistency & governance - Bake standard `management.*` settings into a **shared parent config / base image / config server** so every service exposes the same, reviewed surface. - Include the Actuator surface in **threat modeling**; treat any change to exposure as a security-relevant change. - Differentiate per environment: richer info in dev, minimal + authenticated in prod (Spring profiles). ## Gotchas - **Sanitization applies to /actuator/env and configprops, not to info details you add** — Actuator won't automatically mask a secret you place in a custom contributor; that's on you. - **CORS / caching** — info responses may be cached by proxies; don't rely on it staying private if the endpoint is public. - **Health vs info** — people conflate them; info is arbitrary metadata, health is liveness/readiness with its own `show-details` controls. ## When this matters In any internet-facing or multi-tenant deployment. For a purely internal service on a private management port, the risk is lower, but the same defaults-and-review discipline keeps you safe by construction.

  • A pentester reports committer emails and the internal git remote URL are visible at /actuator/info. What single setting most likely caused it, and how do you remediate?
    management.info.git.mode=full exposes the entire git.properties. Set it to simple, and additionally authenticate/restrict the Actuator surface so info isn't anonymous in production.
  • Does Actuator automatically mask secrets that a developer adds to a custom InfoContributor?
    No. Sanitization applies to endpoints like /actuator/env and configprops; arbitrary details you add via withDetail are serialized as-is. Preventing secret leakage is on the author and code review.

saying these in an interview costs you the question

  • Treating /actuator/info as harmless and exposing it publicly without auth
  • Using management.endpoints.web.exposure.include=* in production
  • Assuming Actuator masks secrets placed in custom info details
  • Leaving git.mode=full on a public endpoint
  • Believing Actuator authenticates endpoints on its own without Spring Security

context

resolving links…