Securing actuator endpoints in Spring Boot - Step-by-Step Execution

Concept Flow - Securing actuator endpoints

Start Spring Boot App

↓

Actuator Endpoints Enabled

↓

Incoming Request to Actuator

↓

Check Security Config

↓

Authenticate

↓

Authorize Role

↓

Allow or Deny Access

↓

Respond to Request

The app starts with actuator endpoints enabled. When a request comes, security checks if the user is authenticated and authorized before allowing access.

Execution Sample

Spring Boot

management.endpoints.web.exposure.include=health,info
management.endpoint.health.roles=ACTUATOR
management.endpoint.info.roles=ACTUATOR
spring.security.user.name=admin
spring.security.user.password=secret
spring.security.user.roles=ACTUATOR

# Security config to protect endpoints

This config exposes health and info endpoints and secures them with a user having ACTUATOR role.

Execution Table

Step	Request Endpoint	User Authenticated?	User Role	Access Granted?	Response
1	/actuator/health	No	N/A	No	401 Unauthorized
2	/actuator/health	Yes	USER	No	403 Forbidden
3	/actuator/health	Yes	ACTUATOR	Yes	200 OK - Health Info
4	/actuator/info	Yes	ACTUATOR	Yes	200 OK - App Info
5	/actuator/env	Yes	ACTUATOR	No	404 Not Found - Not Exposed
6	/actuator/health	No	N/A	No	401 Unauthorized

💡 Requests without authentication or proper role are denied; only ACTUATOR role can access exposed endpoints.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	Final
User Authenticated	false	false	true	true	true	true	false
User Role	N/A	N/A	USER	ACTUATOR	ACTUATOR	ACTUATOR	N/A
Access Granted	false	false	false	true	true	false	false

Key Moments - 3 Insights

Why does a user with role USER get denied access even if authenticated?

Because the security config requires the ACTUATOR role to access actuator endpoints, as shown in step 2 of the execution_table where access is denied despite authentication.

Why is the /actuator/env endpoint denied even for ACTUATOR role?

Because /actuator/env is not included in the exposed endpoints list (only health and info are exposed), so access is denied as shown in step 5.

What happens if a request is unauthenticated?

The request is denied with 401 Unauthorized immediately, as shown in steps 1 and 6.

Visual Quiz - 3 Questions

Look at the execution_table, what is the response at step 3 when the user has ACTUATOR role?

A 200 OK - Health Info

B 403 Forbidden

C 401 Unauthorized

D 404 Not Found

💡 Hint

Check the 'Response' column at step 3 in the execution_table.

At which step does the request get denied because the endpoint is not exposed?

A Step 2

B Step 4

C Step 5

D Step 6

💡 Hint

Look for the step where the response says '404 Not Found - Not Exposed' in the execution_table.

If the user role was changed from ACTUATOR to USER at step 4, what would be the access result?

A Access Granted

B Access Denied with 403 Forbidden

C Access Denied with 401 Unauthorized

D Access Granted only for /actuator/info

💡 Hint

Refer to step 2 where USER role is denied access despite authentication.

Concept Snapshot

Securing actuator endpoints in Spring Boot:
- Enable endpoints in application.properties (e.g., health, info)
- Use Spring Security to require authentication
- Assign ACTUATOR role to users allowed access
- Requests without proper role get 403 Forbidden
- Unauthenticated requests get 401 Unauthorized
- Only exposed endpoints are accessible

Full Transcript

This visual execution trace shows how Spring Boot actuator endpoints are secured. The app starts with actuator endpoints enabled. When a request arrives, the security configuration checks if the user is authenticated and has the ACTUATOR role. If not authenticated, the request is denied with 401 Unauthorized. If authenticated but without the ACTUATOR role, access is denied with 403 Forbidden. Only endpoints listed in the exposure property are accessible. The execution table traces requests to various endpoints with different user roles and shows the resulting access decisions and responses. The variable tracker shows how authentication status, user role, and access granted status change step by step. Key moments clarify common confusions about roles and endpoint exposure. The quiz tests understanding of these execution steps. The snapshot summarizes the main points for quick reference.

Practice

1. What is the main purpose of securing Spring Boot actuator endpoints?

easy

A. To improve application performance by disabling endpoints

B. To automatically update actuator endpoints without manual configuration

C. To enable actuator endpoints for all users without restrictions

D. To protect sensitive application information from unauthorized access

Solution

1. Step 1: Understand actuator endpoints role

   Actuator endpoints provide information about the app's health, metrics, and configuration.

2. Step 2: Recognize security importance

   Since these endpoints expose sensitive data, securing them prevents unauthorized users from accessing this info.

3. Final Answer:

   To protect sensitive application information from unauthorized access -> Option D

4. Quick Check:

   Actuator security = protect info [OK]

Hint: Actuator endpoints show app info; protect them from strangers [OK]

Common Mistakes:

• Thinking actuator endpoints improve performance
• Assuming all endpoints should be open
• Believing security auto-applies without config

2. Which property correctly exposes only the health and info actuator endpoints in application.properties?

easy

A. management.endpoints.web.expose=health,info

B. management.endpoints.web.exposure.include=health,info

C. management.endpoints.exposure.include=health,info

D. management.web.endpoints.include=health,info

Solution

1. Step 1: Identify correct property name

   The correct property to expose endpoints is management.endpoints.web.exposure.include.

2. Step 2: Verify property value format

   Comma-separated list of endpoints like health,info is correct.

3. Final Answer:

   management.endpoints.web.exposure.include=health,info -> Option B

4. Quick Check:

   Correct property = management.endpoints.web.exposure.include [OK]

Hint: Use 'management.endpoints.web.exposure.include' to list endpoints [OK]

Common Mistakes:

• Using 'expose' instead of 'exposure.include'
• Missing 'web' in the property path
• Incorrect property structure or spelling

3. Given this Spring Security config snippet, what is the effect on actuator endpoints?

http
  .authorizeHttpRequests(auth -> auth
    .requestMatchers("/actuator/**").hasRole("ADMIN")
    .anyRequest().authenticated()
  )

medium

A. Only users with ADMIN role can access any actuator endpoint

B. All users can access actuator endpoints without login

C. Actuator endpoints are disabled

D. Only unauthenticated users can access actuator endpoints

Solution

1. Step 1: Analyze requestMatchers rule

   The matcher "/actuator/**" requires users to have role ADMIN to access.

2. Step 2: Understand anyRequest rule

   All other requests require authentication but no specific role.

3. Final Answer:

   Only users with ADMIN role can access any actuator endpoint -> Option A

4. Quick Check:

   Actuator access = ADMIN role required [OK]

Hint: Check role in requestMatchers for actuator URLs [OK]

Common Mistakes:

• Assuming actuator is open to all
• Confusing authentication with authorization
• Ignoring the role requirement

4. What is wrong with this security configuration for actuator endpoints?

@Bean
public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
  http
    .authorizeHttpRequests(auth -> auth
      .requestMatchers("/actuator/**").authenticated()
      .anyRequest().permitAll()
    );
  return http.build();
}

medium

A. The requestMatchers pattern is incorrect syntax

B. The method should return void, not SecurityFilterChain

C. Actuator endpoints require login but other URLs are open, risking security

D. The configuration disables all security

Solution

1. Step 1: Review authorization rules order

   Actuator endpoints require authentication, but all other requests are permitted without login.

2. Step 2: Identify security risk

   This means non-actuator URLs are open, which might expose sensitive parts unintentionally.

3. Final Answer:

   Actuator endpoints require login but other URLs are open, risking security -> Option C

4. Quick Check:

   PermitAll on anyRequest risks open access [OK]

Hint: Check if anyRequest().permitAll() opens unwanted URLs [OK]

Common Mistakes:

• Thinking method return type is wrong
• Assuming requestMatchers syntax is invalid
• Believing security is fully disabled

5. You want to expose only the health endpoint publicly and secure all other actuator endpoints to ADMIN role. Which configuration achieves this correctly?

hard

A. Expose health only and configure security to permit all on /actuator/health and ADMIN role on /actuator/** except health

B. Expose all endpoints and secure only /actuator/health to ADMIN role

C. Expose health and info endpoints and allow anonymous access to all actuator URLs

D. Expose no endpoints and disable security for actuator URLs

Solution

1. Step 1: Set exposure property

   Use management.endpoints.web.exposure.include=health to expose only health publicly.

2. Step 2: Configure security rules

   Permit all access to /actuator/health and require ADMIN role for other actuator endpoints using requestMatchers.

3. Final Answer:

   Expose health only and configure security to permit all on /actuator/health and ADMIN role on /actuator/** except health -> Option A

4. Quick Check:

   Expose health public + secure others ADMIN [OK]

Hint: Expose health only, secure others with ADMIN role [OK]

Common Mistakes:

• Exposing too many endpoints publicly
• Not securing non-health actuator endpoints
• Allowing anonymous access to sensitive endpoints